활동: 컴포넌트 디자인
이 활동은 시스템 디자인을 정제합니다.
설명작업분류 체계(WBS)팀 할당중간 산출물 사용법
관계
상위 활동
설명

이 활동의 목적은 다음과 같습니다.

  • 디자인 요소가 필요한 동작을 실현하는 방법의 '세부사항'을 파악하여 디자인 요소의 정의 정제
  • 식별된 새 디자인 요소를 기반으로 유스 케이스 실현(realization) 정제 및 갱신(예: 유스 케이스 실현(realization)이 계속 갱신되도록 함)
  • 디자인 검토
특성
이벤트로 구동됨
다중 발생
진행 중임
선택사항
계획됨
반복 가능함
인력 구성

일반적으로, 한 사람 또는 소규모 팀이 디자인 요소 세트(보통 다른 디자인 요소를 포함하는 하나 이상의 패키지 또는 서브시스템)에 대한 책임을 맡습니다. 이 사람/팀은 패키지 또는 서브시스템에 포함된 요소에 대한 디자인 세부사항을 구체화하고 모든 오퍼레이션 정의 및 다른 디자인 요소에 대한 관계의 정의를 완료하는 책임을 맡습니다. 타스크: 캡슐 디자인은 캡슐 및 (수동 데이터) 클래스 측면에서 시스템의 기능성을 반복적으로 분해하는 데 초점을 맞춥니다. 타스크: 클래스 디자인은 수동 클래스 디자인 요소의 디자인을 정제하는 데 중점을 두는 반면 타스크: 서브시스템 디자인은 서브시스템 자체에 맵핑된 동작을 포함된 디자인 요소(포함된 캡슐 및 클래스 또는 서브시스템)로 할당하는 데 초점을 맞춥니다. 일반적으로 정보의 수동 저장으로 이어지는 작업 및 "일반" 클래스 대부분에 대해 캡슐이 사용되는 반면 서브시스템은 주로 대규모의 모델 조직 구조로서 사용됩니다.

캡슐 디자인을 책임지는 개인 또는 팀은 일반적으로 동시성 문제에 대한 전문 지식을 가져야 할 뿐 아니라 구현 요소에 대한 지식을 가지고 있어야 합니다. 수동 클래스 디자인을 책임지는 인원은 클래스에서 사용될 알고리즘 또는 기술 뿐만 아니라 구현 언어에 대한 지식도 가지고 있어야 합니다. 서브시스템을 책임지는 개인 또는 팀은 보다 다방면에 지식을 가지고 있어야 하며 디자인 요소 사이에 기능성을 적절히 파티션하는 것에 관련된 결정을 내릴 수 있고 다양한 디자인 대안에 관련된 절충을 이해할 수 있어야 합니다.

각 디자인 요소가 정제되는 동안, 늘어나는 디자인 요소 책임을 반영하도록 유스 케이스 실현(realization)이 정제되어야 합니다. 일반적으로, 한 사람 또는 소규모 팀이 하나 이상의 관련된 유스 케이스 실현(realization)에 대한 책임을 맡습니다. 디자인 요소가 추가되고 정제됨에 따라, 유스 케이스 실현(realization)이 오래되거나 디자인 모델 개선으로 유스 케이스 실현(realization)의 간소화가 가능하게 되므로 유스 케이스 실현(realization)을 다시 고려하고 발전시켜야 합니다. 유스 케이스 실현(realization)을 책임지는 개인 또는 팀은 유스 케이스에 필요한 동작과 디자인 요소 사이에 이 동작을 할당하는 여러 절충 방식에 대해 광범위하게 이해하고 있어야 합니다. 또한 유스 케이스를 수행하는 요소를 선택하는 책임을 지므로 디자인 요소 자체의 외부(공용) 동작에 대해 잘 이해하고 있어야 합니다.

사용법
사용법 안내

일반적으로 이 작업은 팀 간의 변경사항 공유에 필요한 그룹 간 비공식 상호 작용을 통해 개인 또는 소규모 팀 단위로 수행됩니다. 디자인 요소가 정의됨에 따라 일반적으로 요소 간 책임이 이동되므로 그에 따라 여러 디자인 요소 및 유스 케이스 실현(realization)을 동시에 변경해야 합니다. 책임은 상호적인 것이므로 디자인 팀 구성원이 개별적으로 작업한다는 것은 거의 불가능합니다. 디자인 노력을 시스템의 필수 동작(유스 케이스 실현에 명시)에 집중시키기 위한 상호작용의 일반 패턴은 다음과 같습니다.

  • 디자인 요소를 책임자 또는 해당 팀에서 정제합니다.
  • 소규모 그룹(2 - 5명)이 비공식적으로 모여 기존 유스 케이스 실현 세트에 대한 새 디자인 요소의 영향을 분석합니다.
  • 유스 케이스 실현 및 참여 디자인 요소 모두에 대한 변경사항을 식별합니다.
  • 반복에 대한 모든 필수 동작이 디자인될 때까지 주기가 반복됩니다.

프로세스는 그 자체가 반복적이므로 "반복에 대한 모든 필수 동작"에 대한 기준은 라이프사이클에서의 위치에 따라 결정됩니다.

  • 정제(Elaboration) 단계에서 구조적으로 중요한 동작에 초점을 맞추고 모든 다른 '세부사항'은 무시합니다.
  • 구현/구축(Construction) 단계에서는 디자인의 완전성 및 일관성이 변경되며 단계 끝에서는 모든 디자인 문제가 해결됩니다.

구현 및 테스트 활동을 시작하기 전에는 반복에 대한 디자인을 완료하지 않아도 됩니다. 디자인 발전 과정에서의 부분적인 구현 및 테스트를 통해 디자인 정제 및 유효성 검증을 효과적으로 수행할 수 있습니다.