활동:
|
목적
|
|
역할: 소프트웨어 아키텍트 | |
빈도: 새 구현 요소가 발견됨에 따라 적어도 반복당 한 번. | |
단계 | |
입력물: | 결과물: |
툴 강좌: | |
자세한 정보: |
워크플로우 세부사항: |
목적 | 구현 모델의 구조를 설정하기 위함입니다. |
'설계 공간'에서 '구현 공간'으로 이동은 구현 모델의 설계 모델 구조를 미러링하여 시작합니다.
설계 패키지에 대응 구현 서브시스템이 있으며 해당 설계 요소를 구현하는데 필요한 하나 이상의 디렉토리 및 파일(결과물: 구현 요소)을 포함합니다. 설계 모델에서 구현 모델로의 맵핑은 각 구현 서브시스템이 구조의 특정 계층에 할당시 변경될 수도 있습니다.
다이어그램을 작성하여 구현 모델 구조(가이드라인: 구현 다이어그램 참조)를 표시하십시오.
목적 | 팀 조직 또는 구현 언어 제한조건을 반영하도록 모델의 구조를 맞추기 위함입니다. |
구현 환경에 관련된 작은 전술상의 문제점을 설명하여 서브시스템의 조직이 변경되어야 하는지 여부를 판별하십시오. 아래는 이러한 전술적 문제점의 일부 예입니다. 구현 서브시스템의 조직을 변경할지 결정하려는 경우 설계 모델로 되돌아가 갱신해야 할지 여부 또는 설계 모델이 구현 모델과 다름을 허용할지 여부도 결정해야 하는 것을 참고하십시오.
예
서브시스템 D에서 새 서브시스템 유형으로 일부 유형 선언을 추출하여 서브시스템 A를 서브시스템 D의 public(가시적) 결과물의 변경에 대해 독립적이게 합니다.
유형 선언이 서브시스템 D에서 추출됨
결과물은 서브시스템 A에서 추출되어 새 서브시스템 A1에 놓입니다.
구현 서브시스템이 설계 모델의 패키지/서브시스템과 더 이상 일대일로 맵핑하지
않으므로 설계 모델에 대응 변경을 작성하거나(설계 모델을 구현 모델과
밀접하게 정렬한 상태로 유지하고자 결정한 경우) 구현 및 설계 모델 간 맵핑을
계속 추적할 수 있습니다(예: 추적성 또는 구현 종속성을 통해). 이러한 맵핑이
완료되었는지 여부 및 방법은 결과물:
프로젝트 특정 가이드라인에서 캡처되어야 하는 프로세스 결정입니다.
목적 | 서브시스템 간 종속성을 정의하기 위함입니다. |
각 서브시스템에 대해 가져오기하는 기타 서브시스템을 정의하십시오. 이는 서브시스템의 전체 세트에 대해 수행되어 한 계층에 있는 모든 서브시스템이 하위 계층의 모든 시스템으로 가져오기를 허용합니다. 일반적으로, 구현 모델의 종속성이 구현 모델의 구조가 조정된 경우를 제외하고는 설계 모델의 종속성을 반영합니다(구현 서브시스템 조정 참고).
컴포넌트 다이어그램에 서브시스템의 계층화된 서브시스템 구조를 표시하십시오.
실행 파일(및 기타 파생 객체)은 빌드 프로세스를 구현 서브시스템(또는 여러 서브시스템) 또는 해당 서브시스템의 파트로 적용한 결과이며, 따라서 논리적으로 구현 서브시스템에 속합니다. 그러나 소프트웨어 아키텍트가 형상 관리자와 작업하여 구현 모델에 적용될 형상 항목 구조를 판별해야 합니다.
선택과 참조, 특히 전개를 용이하게 하도록 기본 권장사항은 전개 가능한 실행 파일 세트를 포함하는 별도의 형상 항목을 정의하는 것입니다(어떤 실행 파일이 어떤 노드에서 전개될지는 전개 모델에 캡처됨). 따라서 단순한 경우에 각 구현 서브시스템에 대해 전개 가능 실행 파일의 구성 항목과 해당 파일을 작성하는데 사용하는 소스 등을 포함한 구성 항목이 있습니다. 구현 서브시스템은 이러한 구성 항목(및 테스트 자산과 같은 기타 항목)을 포함하는 합성 구성으로 표시되도록 고려될 수 있습니다.
모델링 관점에서 빌드 프로세스가 작성하는 실행 파일의 콜렉션이 연관 구현 시스템(자체가 패키지임)에 포함된 결과물: 빌드(패키지임)로서 표시될 수 있습니다.
목적 | 구현 모델에 테스트 결과물을 추가하기 위함입니다. |
일반적으로 테스트 결과물 및 테스트 서브시스템이 Rational Unified Process에서 기타 개발된 소프트웨어와 그다지 다르지 않게 취급됩니다. 그러나 테스트 결과물 및 서브시스템은 일반적으로 전개된 시스템의 일부를 형성하지 않으며 종종 고객에게 전달 가능하지 않습니다. 따라서 기본 권장사항은 테스트 자산을 테스트 대상과 정렬하는 것입니다(예: 장치 테스트용 구현 요소, 통합 테스트용 구현 서브시스템, 시스템 테스트용 시스템). 그러나 예를 들어 프로젝트 저장소가 디렉토리의 세트 또는 계층 구조로 조직된 경우 테스트 자산은 별도의 테스트 디렉토리에 보관합니다. 별도의 테스트 서브시스템(장치 테스트 레벨 위의 테스트용)이 기타 구현 서브시스템과 동일한 방식으로 별도 구성 항목으로서 취급되어야 합니다.
모델링의 경우, 테스트 결과물의 콜렉션이 결과물: 구현 서브시스템(패키지)으로서 표시될 수 있습니다. 장치 테스트의 경우, 이러한 테스트 서브시스템이 일반적으로 연관된(테스트된) 구현 서브시스템에 포함됩니다. 소프트웨어 아키텍트가 형상 관리자와 상의하여 이 레벨의 테스트 결과물이 테스트하는 구현 요소와 함께 구성되어야 하는지 또는 별도의 구성 항목으로 구성되어야 하는지 여부를 판별합니다. 통합 및 시스템 테스트의 경우, 테스트 서브시스템이 테스트 중인 구현 서브시스템의 피어일 수도 있습니다.
목적 | 소프트웨어 구조 문서의 구현 보기를 갱신하기 위함입니다. |
구현 보기는 소프트웨어 구조 문서의 "구현 보기" 섹션에 설명되어 있습니다. 이 섹션에는 서브시스템 간 가져오기 종속성뿐 아니라 구현 서브시스템의 계층에 할당 및 계층을 표시하는 컴포넌트 다이어그램이 포함됩니다.
체크포인트: 구현 모델을 참조하십시오.
Rational Unified Process
|