소프트웨어 구조 문서가 시스템의 다른 면을 설명하는데 여러 다른 구조 보기를 사용하여 시스템의 포괄적인 구조적 개요를 제공합니다.  
역할:  소프트웨어 아키텍트 
선택 가능성/발생 시기:  구현화 단계 중에 주로 개발됩니다.
템플리트 및 보고서: 
예: 
     
UML 표시:  관련된 구조 보기 세트(유스 케이스, 논리적, 프로세스, 개발, 구현, 데이터).
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

소프트웨어 구조 문서가 소프트웨어 시스템 구조의 포괄적인 개요를 제공합니다. 프로젝트에서 수행된 구조적으로 중요한 결정과 관련하여 소프트웨어 아키텍트 및 기타 프로젝트 팀 구성원 간 의사소통 매개체 역할을 합니다.

시기 페이지 맨 위

소프트웨어 구조의 표시 및 목표는 일반적으로 맨 처음 반복 전에 정의된 다음 프로젝트 전반에 걸쳐 유지보수되어야 하는 사항입니다. 이러한 구조적 표시 가이드라인이 소프트웨어 구조 문서의 초기 버전에 문서화됩니다.

소프트웨어 구조 문서는 주로 구현화 단계 중에 개발됩니다. 왜냐하면 이 단계의 목적 중 하나가 견고한 구조 기반을 설정하는 것이기 때문입니다.

문서 내 유스 케이스 보기가 기타 보기 전에 고려되기 쉽습니다. 왜냐하면 유스 케이스가 개발을 구동하며 반복 계획의 중요한 입력이기 때문입니다. 동시성 및 분배의 정도가 큰 시스템의 경우, 프로세스 및 전개 보기 또한 초기에 고려될 가능성이 큽니다. 왜냐하면 전체 시스템에 상당한 영향을 미칠 수 있기 때문입니다.

책임 페이지 맨 위

소프트웨어 아키텍트는 여러 구조 보기에서 가장 중요한 설계 결정을 캡처하는 소프트웨어 구조 문서를 작성할 책임이 있습니다.

소프트웨어 구조가 각 구조 보기(보기의 분해, 요소 그룹화 및 이러한 주요 그룹화 간 인터페이스)의 전체 구조를 설정합니다. 따라서 기타 역할과 반대로 소프트웨어 아키텍트의 보기는 깊이와 상반된 중 하나입니다.

소프트웨어 아키텍트는 또한 다음을 수행하여 개발 프로세스 동안 시스템의 구조적 무결성을 유지보수할 책임이 있습니다.

  • 소프트웨어 아키텍트 문서에 표시된 기본 인터페이스와 같이 구조적으로 중요한 요소에 대한 모든 변경사항을 승인
  • 소프트웨어 아키텍트에 영향을 미치는 문제점을 해결하도록 "변경 제어 위원회" 결정의 일부가 됨

사용자 정의 페이지 맨 위

소프트웨어 특성에 적합한 소프트웨어 구조 문서의 개요를 조정해야 합니다.

  • 일부 구조 보기는 다음과 같이 부적절할 수 있습니다.
    • 전개 보기는 단일 CPU 시스템에 필요하지 않습니다.
    • 시스템이 단일 제어 스레드만을 사용하는 경우 프로세스 보기가 필요치 않습니다.
    • 객체 지속성이 시스템의 중요한 일면이고 지속성 메커니즘이 지속적 및 비지속적 객체 간 맵핑을 필수로 하지 않는 경우 데이터 보기가 필요치 않습니다.
  • 소프트웨어의 일부 특정 부분이 고유 섹션을 필수로 할 수도 있습니다. 예를 들어, 데이터 관리 또는 사용성 문제점 관련 부분.
  • 특정 관점(예: 제거된 솔루션과 함께 특정 주요 선택사항의 합리성)을 설명하기 위해서나 두문자어 또는 약어를 정의하기 위해, 또는 일반 설계 원칙을 제공하기 위해 추가 부록이 필요할 수도 있습니다.
  • 여러 섹션의 순서는 시스템의 스테이크홀더 및 해당 스테이크홀더의 초점 또는 흥미에 따라 달라질 수 있습니다.

각 구조 보기의 이점 및 단점은 다음과 같습니다.

유스 케이스 보기

이 보기는 필수입니다.

논리 보기

이 보기는 필수입니다.

프로세스 보기

이 보기는 선택사항입니다. 시스템에 둘 이상의 제어 스레드가 있고 별도의 스레드가 상호 작용하거나 서로 의존적인 경우에만 이 보기를 사용하십시오.

전개 보기

이 보기는 선택사항입니다. 시스템이 둘 이상의 노드에 걸쳐 분배된 경우에만 이 보기를 사용하십시오. 이러한 경우에도 분배에 구조적 함축이 있는 경우 전개 보기만을 사용하십시오. 예를 들어, 단일 서버와 여러 클라이언트가 있는 경우 전개 보기는 서버와 클라이언트의 책임을 노드의 클래스로서만 설명하면 됩니다. 모두에 동일한 책임이 있는 경우 모든 클라이언트 노드를 표시할 필요가 없습니다.

구현 보기

이 보기는 선택사항입니다. 구현이 설계에 의해 엄격히 구동되지 않는 경우, 즉 설계 및 구현 모델에 대응하는 패키지 간의 다른 책임 분배가 있는 경우에만 이 보기를 사용하십시오. 설계 및 구현 모델의 패키징이 동일한 경우 이 보기는 생략될 수 있습니다.

데이터 보기

이 보기는 선택사항입니다. 지속성이 시스템이 중요한 특성이며 설계 모델에서 데이터 모델로의 전이가 지속성 메커니즘에 의해 자동으로 완료되지 않는 경우, 이 보기만을 사용하십시오.



Rational Unified Process   2003.06.15