목적
  • 인터페이스, 설계 클래스 및 설계 서브시스템을 찾도록 분석 클래스의 상호 작용을 분석하기 위함입니다.
  • 가능한 경우 재사용을 통합하여 구조를 정제하기 위함입니다.
  • 일반적으로 발생하는 설계 문제점의 공통 솔루션을 식별하기 위함입니다.
  • 소프트웨어 구조 문서의 논리 보기 섹션에서 구조적으로 중요한 설계 모델 요소를 포함하기 위함입니다.
역할:  소프트웨어 아키텍트 
빈도: 반복당 한 번 
단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

재사용 기회 식별 페이지 맨 위

목적 기존 서브시스템 및/또는 컴포넌트가 해당 인터페이스를 기반으로 재사용될 수 있는 위치를 식별하기 위함입니다.  

유사한 인터페이스를 제공하는 기존 서브시스템 또는 컴포넌트를 찾으십시오. 기존 서브시스템 또는 컴포넌트가 제공하는 인터페이스에 식별된 인터페이스를 비교하십시오. 일반적으로 정확한 일치가 없지만 대략적인 일치는 찾을 수 있습니다. 우선 유사한 작동 및 리턴값을 찾은 다음 매개변수를 고려하십시오.

새로 식별된 인터페이스를 수정하여 적합성을 향상시키십시오. 기존 인터페이스와의 적합성을 향상시키는 후보 인터페이스에 작은 변경을 할 기회가 있을 수 있습니다. 단순한 변경사항은 후보 인터페이스에 매개변수 재배열 또는 추가를 포함한 다음 인터페이스를 별도의 인터페이스에 있는 "새" 작동을 포함하는 여러 인터페이스(기존 컴포넌트의 인터페이스와 일치하는 하나 이상)로 나누어 분석합니다.

후보 인터페이스를 정확한 일치가 있는 기존 인터페이스로 바꾸십시오. 기존 인터페이스와 정확한 일치가 있는 경우, 단순화 및 분석 후에 후보 인터페이스를 제거하고 단순히 기존 인터페이스를 사용하십시오.

후보 서브시스템을 기존 컴포넌트에 맵핑하십시오. 기존 컴포넌트와 후보 서브시스템 세트를 살펴보십시오. 서브시스템을 분석하여 기존 컴포넌트를 사용하여 가능한 경우마다 시스템의 필수 작동을 만족시키십시오. 기존 컴포넌트가 후보 서브시스템을 구현할 수 있는 경우, 구현 모델의 컴포넌트와 설계 서브시스템 간 추적성을 작성하십시오.

서브시스템을 재사용 가능 컴포넌트에 맵핑시, 서브시스템과 연관된 설계 메커니즘을 고려하십시오. 성능 또는 보안 요구사항은 조작 서명 간 완전한 일치에도 불구하고 컴포넌트를 재사용 가능하지 않게 할 수도 있습니다.

컴포넌트 및 데이터베이스 역엔지니어링 페이지 맨 위

목적 기타 프로젝트, 내부 소스 또는 이전 반복에서 잠재적으로 사용 가능한 모델을 통합하기 위함입니다.  

기존 코드 및 데이터베이스 정의는 현재 프로젝트/반복에서 사용 가능한 이전 프로젝트 또는 반복에서 작업이 완료되도록 '재사용'될 수 있습니다. 필터로 잠재적인 재사용 기회를 사용하도록 역엔지니어링된 현재 반복에 재사용 가능한 컴포넌트에만 중점을 둘 수 있습니다.

역엔지니어링 컴포넌트

유사한 시스템을 빌드하는 조직에서는 흔히 새 시스템에 필요한 많은 구조적 메커니즘을 제공하는 공통 컴포넌트 세트가 있습니다. 구조적 메커니즘을 제공하는 시장에서 사용 가능한 컴포넌트도 있을 수 있습니다. 기존 컴포넌트는 소프트웨어 구조에서 적합성과 호환성을 판별하도록 검사되어야 합니다.

기존 컴포넌트(이전 반복에서 개발되었으나 아직 설계 모델에 포함되지 않은 컴포넌트 또는 구입된 컴포넌트)는 역엔지니어링되어야 하며 설계 모델로 통합되어야 합니다. 설계 모델에서 이러한 컴포넌트는 일반적으로 하나 이상의 인터페이스가 있는 서브시스템으로 표시됩니다.

역엔지니어링 데이터베이스

데이터베이스와 그 안의 데이터 상주는 재사용 가능한 자산의 가장 중요한 소스 중 하나로 표시됩니다. 기존 데이터베이스에 구현된 내재적 클래스 정의를 재사용하도록 어플리케이션이 사용하는 정보가 이미 기존 데이터베이스에 있는지 판별하십시오. 이 정보를 보유하는 데이터베이스 구조를 표시하도록 클래스 세트를 역엔지니어링하십시오. 동시에 데이터베이스에서 사용된 구조 및 어플리케이션 클래스 표시 간 맵핑을 구성하십시오.

데이터베이스를 역엔지니어링하는것에 대한 자세한 정보는 가이드라인: 역엔지니어링 관계형 데이터베이스를 참조하십시오. 관계형 데이터베이스의 클래스와 테이블 간 맵핑에 대한 자세한 정보는 가이드라인: 데이터 모델을 참조하십시오.

설계 모델의 조직 갱신 페이지 맨 위

목적 설계 모델의 조직에 있는 새 모델 요소를 설명하기 위함입니다.
필요한 경우 설계 모델의 구조를 다시 균형 맞추기 위함입니다.  

새 요소가 설계 모델에 추가됨에 따라 설계 모델 요소를 종종 재패키징해야 합니다. 패키징이 다음과 같은 여러 목표를 달성합니다. 패키지 간 연결을 줄이고 설계 모델의 패키지 내 결합을 향상시킵니다. 궁극적인 목표는 별개의 패키지(및 서브시스템)가 별도의 개인 또는 팀에 의해 서로 관계없이 설계되고 개발되도록 허용하는 것입니다. 완전한 독립성은 달성하기가 불가능할 가능성이 크지만 느슨한 패키지 간 연결이 대형 또는 복잡한 시스템 개발의 용이성을 향상시킵니다.

'단층' 모델 구조(모든 패키지와 서브시스템이 시스템의 동일한 개념 레벨에 있는 경우)가 소형 시스템에 적합합니다. 대형 시스템은 '계층화'라는 추가 구조 지정 도구가 필요합니다(가이드라인: 계층화 참조). 계층화 규칙이 특정 패키지 유형 간 허용 관계에 대한 제한사항을 정의합니다. 이러한 규칙은 특정 종속성이 없어야 함을 승인합니다. 어플리케이션 기능이 특정 운영 체제 또는 윈도 기능 시스템 서비스에 직접 종속적이어서는 안됩니다. 하위 레벨 구현 서비스의 변경사항에서 어플리케이션 기능을 격리하는 논리 운영 체제 및 윈도 기능 서비스 포함 중간 계층이 있어야 합니다. 계층화가 다음과 같이 변경의 영향을 줄이는 방법을 제공합니다. 패키지와 서브시스템 간 종속성을 제한하는 규칙을 시행하고 패키지와 서브시스템 간 연결 정도를 줄여 시스템이 보다 견실하게 됩니다. 변경을 허용합니다.

새 모델 요소가 시스템에 추가됨에 따라 기존 패키지가 커져 단일 시스템이 관리할 수 없게 될 수도 있습니다. 패키지는 패키지 내에서 매우 결합적이지만 패키지 간에 느슨하게 연결된 여러 패키지로 나누어져야 합니다. 이를 수행하는 것은 어려울 수도 있습니다. 일부 요소는 두 패키지의 요소 모두에 의해 사용되므로 특정 한 패키지에 두기가 어려울 수도 있습니다. 다음과 같은 두 가지 가능한 솔루션이 있습니다. 요소를 각 패키지에 하나씩(요소에 여러 '특성'이 있거나 다소 해체된 책임 세트가 있는 경우 작동) 여러 객체로 나누거나 요소를 모든 상위 계층 요소가 해당 요소에 따라 동일하게 달라질 수 있는 낮은 계층의 패키지로 이동하십시오.

시스템의 복잡도가 커짐에 따라, 보다 많은 수의 계층이 유지보수 가능하고 이해 가능한 구조가 생기도록 필요하게 됩니다. 그러나 7-10보다 많은 계층은 초대형 시스템에서도 드문 경우입니다. 왜냐하면 계층의 수에 따라 복잡도가 증가하고 이해 가능성이 감소하기 때문입니다.

미들웨어 및 시스템 소프트웨어 계층을 포함한 계층화의 예는 아래에 표시됩니다.

Java/웹 어플리케이션의 레이아웃 다이어그램

Java/웹 기반 어플리케이션의 샘플 패키지 계층화. 주: 일반적으로 TCP/IP 패키지에 대한 종속성은 TCP/IP 서비스 사용이 Java VM, java.rmi 및 웹 브라우자에 캡슐화되므로 명시적으로 모델화되지 않습니다. 여기에 설명용으로만 묘사됩니다.

서브시스템 및 계층의 책임을 개인 또는 팀에 지정하십시오. 각 패키지 또는 서브시스템이 개인(범위가 작은 경우) 또는 팀(범위가 큰 경우)의 책임이 되어야 합니다.

논리 보기 갱신 페이지 맨 위

목적 결과물: 소프트웨어 구조 문서(논리 보기)가 최신 상태인지 확인하 기 위함입니다.  

설계 클래스, 패키지 및 서브시스템(모델 요소)이 구조적 관점에서 중요한 경우, 결과물: 소프트웨어 구조 문서의 논리 보기 섹션에 포함되어야 합니다. 이로써 구조적으로 중요한 새 모델 요소가 기타 프로젝트 팀 구성원과 통신하는지 확인합니다.

또한 소프트웨어 아키텍트 역할이 프로세스 엔지니어 역할과 공동 작업하여 새로 통합된 설계 요소를 사용하는 방법에 대해 설계자 및 구현자에게 세부사항 가이드를 제공합니다.



Rational Unified Process   2003.06.15