목적
  • 구현 환경이 부여한 제한조건을 기반으로 분석 메커니즘을 설계 메커니즘으로 정제하기 위함입니다.
역할:  소프트웨어 아키텍트 
빈도: 반복당 한 번 
단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

분석 메커니즘의 클라이언트 분류 페이지 맨 위

분석 메커니즘은 분석 클래스가 사용하는 개념적 서비스 세트를 제공합니다. 궁긍적으로 염려해야 하지만 분석 노력의 범위를 넘는 상당히 복잡한 작동에 대해 편리한 약칭을 제공합니다. 주된 목적은 이러한 설계될 시스템의 서비스에 대한 요구사항을 서비스 제공업체 자체의 세부사항에 관여하지 않고 캡처할 수 있게 합니다.

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

각 분석 메커니즘의 클라이언트를 식별하십시오. 해당 메커니즘에 필수인 특성을 살펴보아 제공된 분석 메커니즘의 모든 클라이언트를 스캔하십시오. 예를 들어, 여러 분석 클래스가 지속성 메커니즘을 사용할 수 있으나 해당 메커니즘에서의 요구사항은 다음과 같이 매우 다양합니다. 천개의 지속적 인스턴스가 있는 클래스에는 4백만개의 지속적 인스턴스가 있는 클래스와는 확연히 다른 지속성 요구사항이 있습니다. 마찬가지로, 인스턴스가 인스턴스 데이터에 대해 서브 밀리세컨트 응답을 제공하는 클래스는 인스턴스 데이터가 ad-hoc 조회 및 어플리케이션을 보고하는 일괄처리를 통해서만 액세스되는 클래스와는 다른 지속성 접근법을 요구합니다.

각 분석 메커니즘에 특성 프로파일을 식별하십시오. 성능, 조사 범위, 보안, 경비 등의 다양한 정도를 제공하는 매우 다양한 특성 프로파일이 있습니다. 각 분석 메커니즘은 다릅니다. 다른 특성이 각각에 적용됩니다. 많은 메커니즘이 관리될 인스턴스 수의 추정치와 예상 바이트 수로 된 예상 크기를 요구합니다. 시스템을 통한 대량의 데이터 이동은 반드시 다루어야 하는 중대한 성능 문제점을 작성합니다.

특성 프로파일의 사용에 따라 클라이언트를 그룹화하십시오. 유사한 특성 프로파일이 있는 분석 메커니즘에 대한 필요를 공유하는 것과 같은 클라이언트 그룹을 형성하고 이러한 각 필요를 기반으로 설계 메커니즘을 식별하십시오. 이러한 그룹화는 설계 메커니즘의 초안을 제공합니다. 분석 메커니즘 예제, "상호 프로세스 의사소통"이 설계 메커니즘 "객체 요청 중개인"에 맵핑될 수 있습니다. 다른 특성 프로파일이 동일한 분석 메커니즘에서 나온 다른 설계 메커니즘을 초래합니다. 분석의 단순 지속성 메커니즘이 다음과 같은 설계의 여러 지속성 메커니즘을 발생시킵니다. 메모리 내 지속성, 파일 기반, 데이터베이스 기반, 분배 등. 설계 메커니즘은 분석 메커니즘의 정제로 다른 특성 파일을 기반으로 합니다.

구현 메커니즘 재고 목록 작성 페이지 맨 위

임의로 사용할 수 있는 다음과 같은 구현 메커니즘(개념: 메커니즘 설계 및 구현 참고)을 상향식으로 진행하여 재고 목록을 작성하십시오.

  • 미들웨어 제품 또는 컴포넌트 프레임워크가 제공하는 메커니즘.
  • 운영 체제가 제공하는 메커니즘.
  • 컴포넌트가 제공하는 메커니즘.
  • 클래스 라이브러리가 제공하는 메커니즘.
  • 레거시 코드(활동: 기존 설계 요소 통합도 참조)
  • 특수 용도 패키지: GUI 빌더, 지리 정보 시스템, DBMS 등.

기존 구현 메커니즘이 사용될 수 있는 위치와 새 구현 메커니즘이 빌드되어야 하는 위치를 판별하십시오.

설계 메커니즘을 구현 메커니즘에 맵핑 페이지 맨 위

설계 메커니즘이 구현 메커니즘의 추상 개념을 제공하여 분석 메커니즘과 구현 메커니즘 간 차이점을 잇는 다리 역할을 합니다. 설계 중 추상 구조 메커니즘을 사용하면 특정 메커니즘의 세부사항으로 당면한 문제점을 모호하게 하지 않고 구조 메커니즘을 제공하는 방법을 고려할 수 있습니다. 이로써, 한 특정 구현 메커니즘을 설계에 나쁜 영향을 미치지 않고 다른 메커니즘으로 잠재적으로 대체할 수 있습니다.

특성 범위를 판별하십시오. 설계 메커니즘의 식별된 특성을 사용하여 후보 구현 메커니즘에서 사용할 수 있는 합리적, 경제적 또는 가능한 범위의 값을 판별하십시오.

구입한 컴포넌트의 취득 비용을 고려하십시오. 후보 구현 메커니즘의 경우, 순수한 기술 기준과 더불어 구입 비용 또는 라이센스 부여, 제품의 완성도, 벤더와의 관계, 지원 등을 고려하십시오.

올바른 컴포넌트의 검색을 수행하거나 컴포넌트를 빌드하십시오. 일부 설계 메커니즘에 명백히 적당한 구현 메커니즘이 없음을 종종 발견하게 됩니다. 이는 올바른 제품에 대한 검색을 시작하고 조직 내 개발의 필요를 식별하게 합니다. 일부 구현 메커니즘은 전혀 사용되지 않음을 발견할 수도 있습니다.

구현 메커니즘의 선택은 기술 특성과 제대로 일치하는지뿐 아니라 비용과 같은 비기술적 특성과의 일치도 기반으로 합니다. 일부 선택은 일시적일 수도 있습니다. 거의 모두가 첨부된 위험이 있으며 성능, 견고성 및 범위성은 거의 항상 관심 사항이며 평가, 탐색적 프로토타입화 또는 구조 프로타입에 포함으로 유효성을 확인해야 합니다.

구조적 메커니즘 문서화 페이지 맨 위

이 활동에서 소프트웨어 아키텍트 역할은 해당 메커니즘을 빌드, 통합하여 유효성을 확인하고 판별하는 것이며 자신이 맡은 작업을 제대로 수행하고 있는지 확인한 다음 지속적으로 나머지 시스템 설계에 참여하는 것입니다. 소프트웨어 아키텍트 역할은 프로세스 엔지니어 역할과 공동 작업하여 프로젝트 특정 설계 가이드라인의 사용에 대한 메커니즘과 세부사항을 문서화합니다. 분석 메커니즘과 설계 메커니즘 그리고 구현 메커니즘의 관계(또는 맵핑) 및 이러한 선택사항의 연관 원리는 소프트웨어 구조 문서에 문서화되어야 합니다. 메커니즘 자체는 각 설계 활동의 일부로 활동: 설계 모델에 자세하게 설명된 설계 모델 요소(예: 설계 패키지, 설계 클래스 및 설계 서브시스템)입니다.



Rational Unified Process   2003.06.15