유스 케이스의 구현을 설명하고 결과물: 설계 모델의 추상 개념으로 사용되는 객체 모델. 분석 모델에는 유스 케이스 분석의 결과, 결과물: 분석 클래스가 포함됩니다.
기타 관계:  포함
역할:  소프트웨어 아키텍트 
선택 가능성/발생 시기:  선택사항. 구현화 및 구성 단계.
템플리트 및 보고서: 
     
예: 
     
UML 표시:  <<analysis model>>로 스테레오타입화된 모델. 
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

분석 모델에는 분석 클래스 및 임의의 관련 결과물이 포함됩니다. 분석 모델은 설계 모델로 전개하는 경우에 있거나 일부 또는 모든 제품에 걸쳐 계속 시스템의 개념적 개요 역할을 하며 머무를 수도 있으므로 임시 결과물일 수도 있습니다.

등록 정보 페이지 맨 위

등록 정보 이름 

간략한 설명 

UML 표시 

소개  모델에 대한 간단한 소개 역할을 하는 텍스트 설명.  "간단한 텍스트" 유형의 태그값. 
분석 패키지  계층 구조를 나타내는 모델의 패키지.  "표시" 연관을 통하거나 "소유" 집합을 통해 순환적으로 소유. 
클래스  패키지가 소유한 모델의 클래스.   "소유" 집합을 통해 순환적으로 소유. 
관계  패키지가 소유한 모델의 관계.  -" - 
유스 케이스 구현  패키지가 소유한 모델의 유스 케이스 구현.  -" - 
다이어그램  패키지에 포함된 모델의 다이어그램.  -" - 

시기 페이지 맨 위

분석 모델은 구현화 단계에서 작성되며 모델의 구조가 갱신됨에 따라 구성 단계에서 갱신됩니다.

책임 페이지 맨 위

소프트웨어 아키텍트는 분석 모델의 무결성에 대한 책임이 있으며 다음을 확인합니다.

  • 현재 상태로 유지보수되어 설계의 요약된 개요를 반영합니다.

사용자 정의 페이지 맨 위

일반적으로, "분석 클래스"가 설계 모델의 요소로 다음과 같이 직접 전개됩니다. 일부는 설계 클래스로 나머지는 설계 서브시스템으로 전개됩니다. 분석의 목표는 시스템의 모델링 요소에 필수 작동의 예비 맵핑을 식별하기 위함입니다. 설계의 목표는 이 예비(다소 이상화된) 맵핑을 구현될 수 있는 모델 요소의 세트로 변형하기 위함입니다. 결과적으로, 해당 클래스가 분석에서 설계로 이동하므로 세부사항 및 정확도에 있어 정제됩니다. 결과적으로, "분석 클래스"는 종종 매우 유동적이며 변경 가능하고 설계 활동에서 견고해지기 전에 상당히 전개됩니다.

별도의 분석 모델이 필요한지 여부를 판별할 때 고려해야 할 점은 다음과 같습니다.

  • 별도의 분석 모델은 시스템이 별도의 설계 구조가 있는 여러 대상 환경에 대해 설계되어야 하는 경우 유용합니다. 분석 모델은 설계 모델의 일반화 또는 추상 개념입니다. 시스템 기능의 개요를 제공하도록 대부분의 설계 세부사항이 생략됩니다.
  • 설계가 복잡하므로 단순화되고 추상화된 "설계"가 새 팀 구성원에게 설계를 소개해야 합니다. 다시 한 번, 제대로 정의된 구조가 동일한 용도로 사용될 수 있습니다.
  • 분석 및 설계 모델이 일관되게 남도록 확인하는데 필요한 추가 작업은 시스템이 작동하는 방법의 가장 중요한 세부사항만을 표시하는 시스템의 보기가 있는 장점에 대해 균형을 맞추어야 합니다. 분석 모델과 설계 모델 간 높은 충실도를 유지하는데는 상당한 비용이 들 수 있습니다. 덜 야심적인 접근법은 분석 모델을 가장 중요한 도메인 클래스와 설계의 중요한 추상 개념만으로 유지보수하는 것일 수 있습니다. 분석 모델의 복잡도가 증가함에 따라 이를 유지보수하는 비용도 증가합니다.
  • 분석 모델이 더 이상 유지보수되지 않으면 비용도 급격히 줄어듭니다. 일정 지점에서 유지보수되지 않는 경우, 시스템의 현재 설계를 더 이상 정확히 반영하지 않으므로 더 이상 유용하지 않습니다. 더 이상 분석 모델을 유지보수하지 않기로 결정하는 것이 적합(해당 목적에 유용할 수도 있음)할 수도 있지만 결정은 신중해야 합니다.

시스템이 수십년간 사용되거나 여러 시스템 변형이 있는 일부 회사에서 별도의 분석 모델이 유용한 것으로 증명되었습니다.



Rational Unified Process   2003.06.15