타스크: 구현 모델 구조화
이 타스크는 구현 서브시스템 및 해당 컨텐츠에 대해 지정된 책임을 기반으로 구현 요소 구조 작성 방법을 설명합니다.
관계
역할기본: 추가: 지원:
입력필수: 선택사항: 외부:
  • 없음
출력
단계
구현 모델 구조화
목적 구현 모델 구조 작성. 

'디자인 공간'에서 '구현 공간'으로 이동은 구현 모델의 디자인 모델 구조를 미러링하여 시작합니다.

디자인 패키지에는 해당하는 구현 서브시스템이 포함되고 여기에는 해당 디자인 요소를 구현하는 하나 이상의 디렉토리 및 파일(아티팩트: 구현 요소)이 포함됩니다. 디자인 모델에서 구현 모델로의 맵핑은 각 구현 서브시스템이 아키텍처의 특정 계층에 할당되기 때문에 변경됩니다.

구현 모델 구조를 나타내는 다이어그램을 작성하십시오(가이드라인: 구현 다이어그램 참조).

구현 서브시스템 조정
목적 모델 구조가 팀 조직 또는 구현 언어 제한조건을 반영하도록 수용. 

서브시스템 조직이 변경이 구현 환경과 연관된 소규모의 전략적인 문제를 처리하여 변경되는지 결정하십시오. 다음은 이와 같은 전략적 문제의 예제입니다. 구현 서브시스템 조직을 변경하는 경우 디자인 모델도 변경하거나 디자인 모델이 구현 모델과 달라지도록 허용해야 합니다.

  • 개발 팀 조직. 서브시스템 구조는 몇몇 구현자 또는 구현자 팀에서 너무 겹치이나 혼선이 많지 않은 상태로 병렬로 작업할 수 있도록 허용해야 합니다. 각 구현 서브시스템에 구현자 한 명 또는 한 팀의 책임만 있는 것이 좋습니다. 즉, 서브시스템을 두 개로 분리(대규모인 경우)하고 두 명의 구현자 또는 구현자 두 팀이 분리된 각각을 구현하도록 지정할 수 있습니다(특히, 두 구현자(또는 팀)에 다른 빌드/릴리스 주기가 있는 경우). 
  • 유형 선언. 유형이 해당 서브시스템에서 선언되어 구현에서 서브시스템이 다른 서브시스템에서 중간 산출물을 가져오도록 실현합니다. 일반적으로 C++, Java 및 Ada와 같은 유형화된 프로그래밍 언어를 사용하는 경우가 적용됩니다. 이런 상황 및 일반적으로 유형 선언을 독립 서브시스템으로 추출하는 것이 좋습니다.

예제

서브시스템 D의 유형 선언을 새 서브시스템 유형으로 추출하여 서브시스템 D의 공용(가시적) 중간 산출물 변경에 의존하지 않는 서브시스템 A를 작성합니다.

유형 선언 서브시스템 추출 그림

유형 선언은 서브시스템 D에서 추출됩니다.

.

  • 기존 레거시 코드 및 컴포넌트 시스템. 레거시 코드, 재사용가능 컴포넌트 라이브러리 또는 기존 제품을 통합해야 합니다. 이 내용이 디자인에 모델링되어 있지 않은 경우 구현 서브시스템을 추가해야 합니다.
  • 종속성 조정. 서브시스템 A와 서브시스템 B가 서로 종속성을 가져온다고 가정해 보십시오. 그러나 B를 서브시스템 A의 변경에 덜 의존하게 만듭니다. B가 가져온 A의 중간 산출물을 추출하여 낮은 계층의 서브시스템 A1의 새 구현에 추가합니다.

샘플 아티팩트 그룹 작성 이전 다이어그램

중간 산출물은 서브시스템 A에서 추출되어 새 서브시스템 A1에 추가됩니다.

구현 서브시스템이 더이상 디자인 모델에서 패키지/서브시스템으로 1대1로 맵핑되지 않고 디자인 모델의 해당 변경을 수행하거나(디자인 모델을 구현 모델과 비슷하게 맞춘 경우) 구현 모델과 디자인 모델의 맵핑 트래킹을 유지할 수 있습니다(추적성 또는 실현(realization) 종속성을 통해). 맵핑이 수행되는 경우 및 방법은  중간 산출물: 프로젝트 가이드라인에 캡처되어야 하는 프로세스 결정입니다.

각 구현 서브시스템의 가져오기 정의
목적 서브시스템 종속성 정의. 

각 서브시스템에 대해 가져올 기타 서브시스템을 정의하십시오. 이 작업은 서브시스템 전체에 대해 수행할 수 있으며 한 계층의 모든 서브시스템에서 낮은 계층의 모든 서브시스템을 가져올 수 있습니다. 일반적으로 구현 모델의 종속성은 디자인 모델의 종속성을 미러링하지만 구현 모델 구조가 조정된 경우는 제외됩니다(구현 서브시스템 조정 참조).

컴포넌트 다이어그램에 서브시스템의 계층화된 구조 표시

실행 가능 프로그램(및 기타 도출된 오브젝트) 처리 방법 결정

실행 가능 프로그램(및 기타 도출된 오브젝트)은 빌드 프로세스를 구현 서브시스템(또는 서브시스템) 또는 파트에 적용한 결과이며, 따라서 논리적으로 구현 서브시스템에 속합니다. 그러나 형상 관리자와 같이 작업하는 소프트웨어 설계자는 구현 모델에 적용되는 형상 항목 구조를 결정해야 합니다. 

특히 배치에서의 선택 및 참조 용이성을 위해, 기본 권장사항은 배치 가능한 실행 가능 프로그램 세트를 포함하는 독립 형상 항목을 정의하는 것입니다(실행 가능 프로그램과 이를 배치하는 해당 노드는 배치 모델에 캡처됨). 그래서 단순한 경우에서는, 각 구현 서브시스템에 대해 배치 가능 실행 가능 프로그램의 형상 항목 및 프로그램 생성에 사용되는 소스를 포함하는 항목이 있습니다. 구현 서브시스템은 해당 형상 항목을 포함하는 컴포지트 형상 항목(예: 테스트 자산)으로 표시되도록 고려될 수 있습니다.

모델링 관점에서 빌드 프로세스에서 생성된 실행 가능 프로그램 콜렉션은 연관된 구현 서브시스템에 포함된(패키지 자체) 중간 산출물: 빌드(패키지)로 표시될 수 있습니다.  

테스트 자산 처리 방법 결정
목적 테스트 중간 산출물을 구현 모델에 추가. 

일반적으로 테스트 중간 산출물 및 테스트 서브시스템은 기타 개발 소프트웨어와는 다르게 Rational Unified Process에서 처리되지 않습니다. 그러나 테스트 중간 산출물 및 서브시스템은 일반적으로 배치 시스템의 파트가 아니며 고객에게 전달되지 않는 경우도 있습니다. 따라서 기본 권장사항은 테스트 자산을 테스트 대상(예: 유닛 테스트용 구현 요소, 통합 테스트용 구현 서브시스템, 시스템 테스트용 시스템)으로 지정하는 것이지만, 프로젝트 저장소가 디렉토리 세트 또는 계층 구조로 구성되는 경우 예를 들어 테스트 자산을 독립 테스트 디렉토리에 유지하십시오. 테스트 서브시스템 구별(유닛 테스트 레벨 이상의 테스트용)은 구별되는 형상 항목으로 처리하는 것과 같은 기타 구현 서브시스템과 동일한 방식으로 처리해야 합니다.

모델링에 대해 테스트 중간 산출물 콜렉션은 중간 산출물: 구현 서브시스템(패키지)으로 표시될 수 있습니다. 유닛 테스트에 대해, 이런 테스트 서브시스템은 일반적으로 연관된(테스트된) 구현 서브시스템에 포함됩니다. 형상 관리자의 조언을 받아 소프트웨어 설계자는 이 레벨의 테스트 중간 산출물이 테스트하는 구현 요소와 같이 구성되는지 또는 독립 형상 항목으로 구성되어야 하는지 결정해야 합니다. 통합 및 시스템 테스트에 대해 테스트 서브시스템은 테스트되는 구현 서브시스템의 피어가 됩니다.

구현 보기 갱신
목적 소프트웨어 아키텍처 문서 구현 보기 갱신. 

구현 보기는 소프트웨어 아키텍처 문서를 참조하십시오. 이 섹션에는 계층과 구현 서브시스템의 계층 할당 및 서브시스템의 가져오기 종속성을 표시하는 컴포넌트 다이어그램이 포함됩니다.

구현 모델 평가
특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보