분석 메커니즘은 분석 클래스가 사용하는 개념적 서비스 세트를 제공합니다. 이는 궁극적으로 관심을 가져야 하지만 분석 노력의 범위를 벗어나는
상당히 복잡한 동작에 대해 편리한 방법을 제공합니다. 기본 목적은 서비스 제공업체 자체의 세부사항에 대해 신경쓸 필요 없이 시스템의 디자인되어야 하는 서비스에 대한 요구사항을 캡처할 수 있게 하는 것입니다.
이제 분석 메커니즘에서 수집되는 정보 정제를 시작해야 합니다. 이를 수행하기 위한 단계는 다음과 같습니다.
각 분석 메커니즘의 클라이언트를 식별하십시오. 주어진 분석 메커니즘의 모든 클라이언트를 스캔하여 해당 메커니즘에 대해 필요로 하는 특성을 찾으십시오. 예를 들어 많은 분석 클래스가 지속성 메커니즘을 사용할 수 있지만, 이에 대한 요구사항은 크게 다를 수 있습니다. 천 개의 지속적 인스턴스를
가질 클래스는 4백만 개의 지속적 인스턴스를 가질 클래스와 크게 다른 지속성 요구사항을 갖습니다. 비슷하게 해당 인스턴스가 인스턴스 데이터에 밀리초 이하의 응답을 제공해야 하는 클래스는 해당 인스턴스 데이터가
특별한 조회와 일괄처리 보고 응용프로그램을 통해서만 액세스되는 클래스와 다른 지속성 접근 방식이 필요합니다.
각 분석 메커니즘에 대한 특성 프로파일을 식별하십시오. 다양한 정도의 성능, 발자취, 보안, 경제적 비용 등을 제공하는 광범위하게 변화하는 특성 프로파일이 있을 수 있습니다. 각 분석
메커니즘은 다릅니다. 각각에 대해 다른 특성이 적용됩니다. 많은 메커니즘의 경우에 있어서, 관리될 인스턴스 수 예상 및 예상 바이트 수로 표시되는 예상 크기가 필요합니다. 임의의 시스템을 통하는 많은 양의 데이터
이동은 반드시 처리되어야 하는 거대한 성능 문제를 야기합니다.
특성 프로파일의 사용에 따라서 클라이언트를 그룹화하십시오. 비슷한 특성 프로파일을 갖는 분석 메커니즘에 대한 필요를 공유할 것으로 보이는 클라이언트의 그룹을 형성하십시오. 그런 각 필요를 기반으로
디자인 메커니즘을 식별하십시오. 이러한 그룹화가 디자인 메커니즘에서 초기 조각을 제공합니다. 예제 분석 메커니즘인 "프로세스 간 통신"이 디자인 메커니즘 "ORB(Object Request Broker)"에 맵핑할
수 있습니다. 특성 프로파일이 다르면 동일한 분석 메커니즘에서 나타나는 디자인 메커니즘이 달라지게 됩니다. 분석에서의 단순 지속성 메커니즘은 디자인에서 인메모리 지속성, 파일 기반, 데이터베이스 기반, 분산 등의
많은 지속성 메커니즘을 발생시킵니다. 디자인 메커니즘은 서로 다른 특성 프로파일을 기반으로 하는 분석 메커니즘의 정제입니다.
|