타스크: 디자인 메커니즘 식별
이 타스크는 분석 메커니즘을 디자인 메커니즘으로 정제하는 방법을 설명합니다.
목적
  • 구현 환경에 의해 부과되는 제한조건을 기반으로 분석 메커니즘을 디자인 메커니즘으로 정제합니다.
관계
단계
분석 메커니즘의 클라이언트 분류

분석 메커니즘은 분석 클래스가 사용하는 개념적 서비스 세트를 제공합니다. 이는 궁극적으로 관심을 가져야 하지만 분석 노력의 범위를 벗어나는 상당히 복잡한 동작에 대해 편리한 방법을 제공합니다. 기본 목적은 서비스 제공업체 자체의 세부사항에 대해 신경쓸 필요 없이 시스템의 디자인되어야 하는 서비스에 대한 요구사항을 캡처할 수 있게 하는 것입니다.

이제 분석 메커니즘에서 수집되는 정보 정제를 시작해야 합니다. 이를 수행하기 위한 단계는 다음과 같습니다.

각 분석 메커니즘의 클라이언트를 식별하십시오. 주어진 분석 메커니즘의 모든 클라이언트를 스캔하여 해당 메커니즘에 대해 필요로 하는 특성을 찾으십시오. 예를 들어 많은 분석 클래스가 지속성 메커니즘을 사용할 수 있지만, 이에 대한 요구사항은 크게 다를 수 있습니다. 천 개의 지속적 인스턴스를 가질 클래스는 4백만 개의 지속적 인스턴스를 가질 클래스와 크게 다른 지속성 요구사항을 갖습니다. 비슷하게 해당 인스턴스가 인스턴스 데이터에 밀리초 이하의 응답을 제공해야 하는 클래스는 해당 인스턴스 데이터가 특별한 조회와 일괄처리 보고 응용프로그램을 통해서만 액세스되는 클래스와 다른 지속성 접근 방식이 필요합니다.

각 분석 메커니즘에 대한 특성 프로파일을 식별하십시오. 다양한 정도의 성능, 발자취, 보안, 경제적 비용 등을 제공하는 광범위하게 변화하는 특성 프로파일이 있을 수 있습니다. 각 분석 메커니즘은 다릅니다. 각각에 대해 다른 특성이 적용됩니다. 많은 메커니즘의 경우에 있어서, 관리될 인스턴스 수 예상 및 예상 바이트 수로 표시되는 예상 크기가 필요합니다. 임의의 시스템을 통하는 많은 양의 데이터 이동은 반드시 처리되어야 하는 거대한 성능 문제를 야기합니다.

특성 프로파일의 사용에 따라서 클라이언트를 그룹화하십시오. 비슷한 특성 프로파일을 갖는 분석 메커니즘에 대한 필요를 공유할 것으로 보이는 클라이언트의 그룹을 형성하십시오. 그런 각 필요를 기반으로 디자인 메커니즘을 식별하십시오. 이러한 그룹화가 디자인 메커니즘에서 초기 조각을 제공합니다. 예제 분석 메커니즘인 "프로세스 간 통신"이 디자인 메커니즘 "ORB(Object Request Broker)"에 맵핑할 수 있습니다. 특성 프로파일이 다르면 동일한 분석 메커니즘에서 나타나는 디자인 메커니즘이 달라지게 됩니다. 분석에서의 단순 지속성 메커니즘은 디자인에서 인메모리 지속성, 파일 기반, 데이터베이스 기반, 분산 등의 많은 지속성 메커니즘을 발생시킵니다. 디자인 메커니즘은 서로 다른 특성 프로파일을 기반으로 하는 분석 메커니즘의 정제입니다.

구현 메커니즘 인벤토리

상향식으로 진행하고 사용자 마음대로 처분할 수 있는 구현 메커니즘(개념: 디자인 및 구현 메커니즘 참조)의 인벤토리를 작성하십시오.

  • 미들웨어 제품 또는 컴포넌트 프레임워크가 제공하는 메커니즘.
  • 운영 체제가 제공하는 메커니즘.
  • 컴포넌트가 제공하는 메커니즘.
  • 클래스 라이브러리가 제공하는 메커니즘.
  • 레거시 코드(타스크: 기존 디자인 요소 통합도 참조)
  • 특수 목적 패키지: GUI 빌더, Geographical Information System, DBMS 등

기존 구현 메커니즘을 사용할 수 있는지 및 새 구현 메커니즘을 구현해야 하는지를 판별하십시오.

디자인 메커니즘을 구현 메커니즘에 맵핑

디자인 메커니즘은 구현 메커니즘의 추상을 제공하여 분석 메커니즘과 구현 메커니즘 사이의 간격을 이어줍니다. 디자인 중에 추상 아키텍처 메커니즘을 사용하면 특정 메커니즘의 세부사항으로 당장의 문제점을 가리지 않으면서 아키텍처 메커니즘을 제공하는 방법을 고려할 수 있습니다. 또한 디자인에 부정적인 영향을 주지 않으면서 하나의 특정 구현 메커니즘을 다른 것으로 잠재적으로 대체할 수 있습니다.

특성의 범위를 판별하십시오. 디자인 메커니즘에 대해 식별된 특성으로 후보 구현 메커니즘에서 사용할 값의 합리적, 경제적 또는 실현 가능한 범위를 결정하십시오.

구매한 컴포넌트에 대한 취득 비용을 고려하십시오. 후보 구현 메커니즘에 대해 순수한 기술적 기준 외에 취득 또는 라이센스 부여 비용, 제품의 성숙도, 벤더와의 관계, 지원 등을 고려하십시오.

적합한 컴포넌트에 대한 검색을 수행하거나 컴포넌트를 빌드하십시오. 종종 일부 디자인 메커니즘의 경우 완전히 적합한 구현 메커니즘을 찾을 수 없는 경우도 있습니다. 이럴 경우에는 적합한 제품을 검색하거나 사내 개발을 해야 할 수 있습니다. 또한 일부 구현 메커니즘이 전혀 사용되지 않음을 알 수도 있습니다.

구현 메커니즘의 선택은 기술적 특성에 대한 일치뿐 아니라 비용 같은 비기술적 특성에도 영향을 받습니다. 일부 선택사항은 잠정적일 수 있습니다. 거의 모두에 약간의 위험성이 연관됩니다. 성능, 완전성 및 확장 가능성은 거의 항상 관심사항이며 평가, 탐색 프로토타입 생성, 또는 아키텍처 프로토타입에 포함시켜 유효성이 검증되어야 합니다.

아키텍처 메커니즘 문서화

이 타스크의 소프트웨어 설계자의 역할은 이러한 메커니즘을 빌드하거나 통합하고 메커니즘이 작업을 수행함을 검증하여 이들 메커니즘을 결정하고 유효성을 검증하며 시스템 디자인의 나머지에 이들을 일관성있게 부과하는 것입니다. 소프트웨어 설계자 역할은 프로세스 엔지니어와 협업하여 프로젝트 특정 디자인 가이드라인에 메커니즘 및 사용에 관한 세부사항을 문서화합니다.  타스크: 프로젝트 가이드라인 준비를 참조하십시오. 분석 메커니즘, 디자인 메커니즘 및 구현 메커니즘 사이의 관계(또는 맵핑) 및 이러한 선택사항에 대한 연관된 근본적 이유가 소프트웨어 아키텍처 문서에 문서화되어야 합니다. 메커니즘 자체는 해당 디자인 타스크의 일부로서 중간 산출물: 디자인 모델에서 자세히 설명하는 디자인 모델 요소(예: 디자인 패키지, 디자인 클래스 및 디자인 서브시스템)입니다.



특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보