결과물:
|
![]() |
분석 클래스가 '책임 및 작동을 하는 시스템의 사항'의 초기 개념적 모델을 표시합니다. |
기타 관계: |
다음 파트 분석 모델
|
---|---|
역할: | 설계자 |
선택 가능성/발생 시기: | 선택사항. 구현화 및 구성 단계. |
템플리트 및 보고서: |
|
예: | |
UML 표시: | <<boundary>>, <<entity>> 또는 <<control>>로 스테레오타입화된 클래스. |
자세한 정보: | |
활동 정보: | 활동 결과: |
분석 클래스를 사용하여 시스템의 작은 "집단의 책임"을 캡처할 수 있습니다. 시스템의 프로토타입화된 클래스를 표시하며 시스템이 처리해야 하는 주된 추상 개념의 '첫 번째 패스'입니다. 시스템의 "상위 레벨"의 개념적 개요가 요구되는 경우 분석 클래스가 자체로 고유하게 유지보수될 수 있습니다. 분석 클래스는 시스템 설계(시스템의 서브클래스와 설계 클래스)의 주된 추상 개념도 향상시킵니다.
등록 정보 이름 |
간략한 설명 |
UML 표시 |
---|---|---|
이름 | 클래스 이름 | 속성 |
설명 | 시스템에 있는 클래스의 역할에 대한 간략한 설명 | 속성 |
책임 | 클래스의 책임 목록 | 속성 |
속성 | 클래스 속성 | 속성 |
유스 케이스가 분석됨에 따라 분석 클래스가 구현화 단계에서 주로 식별됩니다. 일부 분석 클래스가 구성 단계까지 분석되지 않는 유스 케이스에 대해 늦게 구성 단계에서 식별될 수도 있습니다.
설계자는 분석 클래스의 무결성에 대한 책임이 있으며 다음을 확인합니다.
분석 클래스는 함께 사용되어 시스템의 초기 개념적 모델을 표시합니다. 이 개념적 모델이 빠르게 전개하며 다른 표시 및 함축이 탐색되는 시기에 유동적으로 남습니다. 공적 문서화가 이 프로세스를 방해하므로 형식적 의미에서 해당 '모델'을 유지보수하는데 소요하는 에너지의 양에 주의하십시오. 대부분 소모적인 모델을 마무리하는데 많은 시간을 낭비할 수 있습니다. 분석 클래스가 설계에서 변경되지 않은 상태로 남는 것은 거의 드뭅니다. 많은 분석 클래스가 종종 서브시스템이 캡슐화하는 객체의 전체 공동 연구를 표시합니다.
일반적으로, 아래의 예와 같은 단순한 노트 카드로 충분합니다(잘 알려진 CRC 카드 기술을 기반으로 합니다. 이 기술의 세부사항은 WIR90]을 참조하십시오). 카드의 정면에서 클래스의 이름과 설명을 캡처하십시오. 과정 등록 시스템의 과정에 대한 예는 아래 나열되어 있습니다.
클래스 이름 | 과정 | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
설명 | 과정은 공통 주제, 요구사항 및 요강이 있는 과정 섹션의 세트에 대한 정보를 유지보수할 책임이 있습니다. | |||||||||
책임 | 과정에 대한 정보를 유지보수. | |||||||||
속성 |
|
카드의 뒷면에 클래스의 다음 다이어그램을 그리십시오.
과정의 클래스 다이어그램
유스 케이스 분석 워크샵 중에 발견된 각 클래스에 하나의 분석 클래스 카드가 있습니다.
Rational Unified Process
|