결과물:
|
![]() |
유스 케이스의 구현을 설명하고 결과물: 설계 모델의 추상 개념으로 사용되는 객체 모델. 분석 모델에는 유스 케이스 분석의 결과, 결과물: 분석 클래스가 포함됩니다. | |
기타 관계: |
포함
| |
---|---|---|
역할: | 소프트웨어 아키텍트 | |
선택 가능성/발생 시기: | 선택사항. 구현화 및 구성 단계. | |
템플리트 및 보고서: |
|
|
예: | ||
UML 표시: | <<analysis model>>로 스테레오타입화된 모델. | |
자세한 정보: | ||
활동 정보: | 활동 결과: |
분석 모델에는 분석 클래스 및 임의의 관련 결과물이 포함됩니다. 분석 모델은 설계 모델로 전개하는 경우에 있거나 일부 또는 모든 제품에 걸쳐 계속 시스템의 개념적 개요 역할을 하며 머무를 수도 있으므로 임시 결과물일 수도 있습니다.
등록 정보 이름 |
간략한 설명 |
UML 표시 |
---|---|---|
소개 | 모델에 대한 간단한 소개 역할을 하는 텍스트 설명. | "간단한 텍스트" 유형의 태그값. |
분석 패키지 | 계층 구조를 나타내는 모델의 패키지. | "표시" 연관을 통하거나 "소유" 집합을 통해 순환적으로 소유. |
클래스 | 패키지가 소유한 모델의 클래스. | "소유" 집합을 통해 순환적으로 소유. |
관계 | 패키지가 소유한 모델의 관계. | -" - |
유스 케이스 구현 | 패키지가 소유한 모델의 유스 케이스 구현. | -" - |
다이어그램 | 패키지에 포함된 모델의 다이어그램. | -" - |
분석 모델은 구현화 단계에서 작성되며 모델의 구조가 갱신됨에 따라 구성 단계에서 갱신됩니다.
소프트웨어 아키텍트는 분석 모델의 무결성에 대한 책임이 있으며 다음을 확인합니다.
일반적으로, "분석 클래스"가 설계 모델의 요소로 다음과 같이 직접 전개됩니다. 일부는 설계 클래스로 나머지는 설계 서브시스템으로 전개됩니다. 분석의 목표는 시스템의 모델링 요소에 필수 작동의 예비 맵핑을 식별하기 위함입니다. 설계의 목표는 이 예비(다소 이상화된) 맵핑을 구현될 수 있는 모델 요소의 세트로 변형하기 위함입니다. 결과적으로, 해당 클래스가 분석에서 설계로 이동하므로 세부사항 및 정확도에 있어 정제됩니다. 결과적으로, "분석 클래스"는 종종 매우 유동적이며 변경 가능하고 설계 활동에서 견고해지기 전에 상당히 전개됩니다.
별도의 분석 모델이 필요한지 여부를 판별할 때 고려해야 할 점은 다음과 같습니다.
시스템이 수십년간 사용되거나 여러 시스템 변형이 있는 일부 회사에서 별도의 분석 모델이 유용한 것으로 증명되었습니다.
Rational Unified Process
|