설계 모델은 유스 케이스의 구현을 설명하는 객체 모델이며 구현 모델 및 해당 소스 코드의 추상 개념 역할을 합니다. 설계 모델이 구현 및 테스트의 활동에 주요한 입력으로 사용됩니다.  
기타 관계:  포함
역할:  소프트웨어 아키텍트 
선택 가능성/발생 시기:  필수. 구현화 및 구성 단계.
템플리트 및 보고서: 
     
예: 
     
UML 표시:  <<designModel>>로 스테레오타입화된 모델. 
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

설계 모델은 시스템 구현의 추상화입니다. 소프트웨어 시스템 설계의 문서화뿐 아니라 착상에도 사용합니다. 모든 설계 클래스, 서브시스템, 패키지, 공동 작업 및 관계를 포함하는 포괄적인 합성 결과물입니다.

등록 정보 페이지 맨 위

등록 정보 이름 

간략한 설명 

UML 표시 

소개  모델에 대한 간단한 소개 역할을 하는 텍스트 설명.  "간단한 텍스트" 유형의 태그값. 
설계 패키지

설계 서브시스템 

계층 구조를 나타내는 모델의 패키지 및 서브시스템.    "표시" 연관을 통하거나 "소유" 집합을 통해 순환적으로 소유. 
클래스  패키지가 소유한 모델의 클래스.   "소유" 집합을 통해 순환적으로 소유. 
인터페이스  패키지가 소유한 모델의 인터페이스.  "소유" 집합을 통해 순환적으로 소유. 
이벤트 및 신호  패키지가 소유한 모델의 이벤트 및 신호.  "소유" 집합을 통해 순환적으로 소유. 
관계  패키지가 소유한 모델의 관계.  - " - 
설계 유스 케이스 구현  패키지가 소유한 모델의 설계 유스 케이스 구현.  - " - 
다이어그램  패키지에 포함된 모델의 다이어그램.  - " -  

시기 페이지 맨 위

설계 모델이 주로 구조를 설정하지만 구현화 단계 중 분석의 매개로도 사용될 수 있습니다. 그런 다음, 구성 단계 중에 자세한 설계 판별로 정제됩니다.

책임 페이지 맨 위

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

  • 전체적으로 설계 모델은 정확하며 일관되고 읽기 가능합니다. 설계 모델이 유스 케이스 모델에 설명된 기능성과 오직 이 작동만을 구현하는 경우 해당 모델이 정확합니다.
  • 설계 모델의 구조가 논리, 프로세스 및 전개 보기를 포함하여 해당 목적을 수행합니다. 이러한 보기는 별도의 결과물에서 수집됩니다. 결과물: 소프트웨어 구조 문서를 참조하십시오.

소프트웨어 아키텍트가 패키지, 클래스, 관계, 설계 유스 케이스 구현 및 다이어그램 자체에 대한 책임이 없음을 참고하십시오. 대신에, 해당 설계자 및 유스 케이스 설계자의 책임입니다.

사용자 정의 페이지 맨 위

다음을 판별하십시오.

  • 포함할 등록 정보
  • UML(Unified Modeling Language)에 임의의 확장자가 필요한지 여부. 예를 들어, 보호에 추가 스테레오타입이 필요할 수도 있음.
  • 모델에 적용된 형식성 레벨
  • 개별 서브 결과물에 적용 가능한 조정
  • 모델이 분석 모델에 맵핑되는 방법(가이드라인: 설계 모델 참조)
  • 단일 모델 또는 여러 모델이 사용될지 여부
  • 모델이 추상 스펙, 자세한 스펙, 자세한 설계 또는 일부 조합일지 여부(가이드라인: 설계 모델 참조)
  • 모델이 구현 모델에 맵핑되는 방법(역엔지니어링, 코드 생성 또는 왕복 엔지니어링을 사용하는 판별에 의해 매우 영향을 받음). 가이드라인: 설계에서 코드로 맵핑을 참조하십시오.

프로젝트 설계 가이드라인의 조정 판별을 문서화 .



Rational Unified Process   2003.06.15