목적
  • 유사한 시스템 또는 유사한 문제점 도메인에서 얻은 경험을 기반으로 시스템의 후보 구조를 정의하기 위함입니다.
  • 시스템의 모델링 규정, 중요한 메커니즘 및 구조 패턴을 정의하기 위함입니다.
역할:  소프트웨어 아키텍트 
빈도: 선택사항으로 초기화에 발생합니다. 첫 번째 구현화 반복에서 발생해야 합니다. 소프트웨어 구조에 중요한 변경사항이나 추가가 조사되어야 하는 경우 차후 반복에서 다시 발생할 수 있습니다.

단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

구조적 분석이 후보 구조 정의 및 시스템에서 사용할 구조적 기술의 제한에 초첨을 맞춥니다. 유사한 시스템 또는 문제점 도메인에서 얻은 수집된 경험을 바탕으로 구조를 제한하고 초점을 맞춰 구조적 재발견에서 노력이 낭비되지 않도록 합니다. 이미 잘 정의된 구조가 있는 시스템에서 구조적 분석은 생략될 수도 있습니다. 구조적 분석은 전에 없는 새 시스템을 개발하는 경우 가장 유용합니다.

구조 개요 개발 페이지 맨 위

목적  상위 레벨 구조 선택사항을 조사하고 평가하여 시스템 계획을 용이하게 하기 위함입니다.  
후원자, 개발 팀 및 기타 스테이크홀더에게 고안된 시스템의 상위 레벨 구조에 대한 초기 이해를 전달하기 위함입니다.

구조적 개요는 프로젝트의 라이프사이클 초기에(초기화 단계에) 작성됩니다. 실제 및 논리 구조에 관한 결정과 시스템의 비기능적 요구사항뿐 아니라 비전을 구현하는데 대한 초기 결정 및 작업 가설을 반영합니다. 이는 종종 프로젝트 후원자와의 공동 작업으로 소프트웨어 아키텍트가 작성하며 비형식적, 선명한 그림 스토리보드 또는 아이콘 그래프의 양식을 취합니다. 개념적으로 제안된 솔루션의 본질적 특성을 설명하여 지배적인 아이디어를 전달하고 주된 빌드 블록을 포함합니다. 구조적 개요의 형식 레벨은 프로젝트 종속적입니다. 예를 들어, 대형의 높은 형식의 프로젝트에서 소프트웨어 구조 문서의 적절한 섹션의 구조 개요를 캡처하여 공식적으로 검토될 수 있도록 하는 것이 필요할 수도 있습니다.

이 지점에서 구조 개요는 임시의 첫 번째 패스입니다. 실행 가능 구조적 프로토타입이 설계, 구현 및 전개 관련 사항을 포함하여 구조의 유효성을 확인할 때가지 구조 개요 다이어그램에 책임을 두지 마십시오.

참조 구조, 기타 구조 패턴 또는 기타 구조 자산을 기반으로 하는 구조를 고려하십시오.

의사소통 도구로 사용하도록 구조 개요 다이어그램을 정제하고 유지보수하려는지 여부를 고려하십시오.

여러 시스템의 하드웨어 및 소프트웨어의 기존 환경에서 개발되고 전개되도록 되어 있습니다. 이러한 경우, 소프트웨어 아키텍트가 현재 환경에 대한 정보를 수집합니다.

예를 들어, e-business 시스템 개발에서 다음 정보가 관련됩니다.

  • 기존 네트워크 논리 및 실제 설계
  • 기존 데이터베이스 및 데이터베이스 설계
  • 기존 웹 환경(서버, 방화벽 등)
  • 기존 서버 환경(구성, 소프트웨어 버전, 계획된 업그레이드)
  • 기존 표준(네트워크, 이름 지정, 프로토콜 등)

이러한 정보는 원문 그대로 또는 전개 모델로 캡처될 수 있습니다.

사용 가능 자산 조사 페이지 맨 위

목적  프로젝트와 관련될 수 있는 자산을 식별하기 위함입니다.
자산과 프로젝트 요구사항 간 차이점과 일치점을 분석하기 위함입니다.
자산에서 시스템의 영역을 기반으로 할지 여부를 판별하기 위함입니다.
프로젝트에서 잠재적으로 재사용 가능한 자산을 찾고 나열하기 위함입니다.
필수 지원이 잠재적으로 사용 가능한지를 확인하는 예비 평가를 수행하기 위함입니다.

자산이 고려 중인 환경의 요구사항과 시스템 범위 및 필수 일반 기능을 이해해야 합니다. 조직의 자산 기반과 산업 문헌을 검사하여 자산 또는 유사한 프로젝트를 식별하십시오. 고려해야 할 여러 자산 유형이 있습니다(예: 산업 모델, 프레임워크, 클래스 및 경험. 이에 한정되지는 않음). 사용 가능한 자산이 현재 프로젝트의 중요한 도전 과제를 해결하는데 공헌하는지 여부와 프로젝트 제한조건과 호환되는지 여부를 평가해야 합니다.

임의의 요구사항을 협상할 수 있는지(자산을 이용 가능하도록) 여부를 고려하여 자산 및 고객 요구사항 간 적합 정도를 분석하고자 합니다.

잔산이 수정 가능한지 또는 요구사항을 충족하도록 확장 가능한지 여부와 자산을 채택하는 대신 비용, 위험 및 기능면에서의 트레이드오프를 평가하도록 하십시오.

마지막으로 원칙상, 하나 이상의 자산을 사용할지와 이 결정의 합리성을 문서화할지 여부를 결정하고자 합니다.

서브시스템의 상위 레벨 조직 정의 페이지 맨 위

목적 설계 모델의 초기 구조를 작성하기 위함입니다.

시작 중 구조적 통합 수행에 초점이 맞추어진 경우 이 단계는 해당 활동에서 제외됩니다.

일반적으로 설계 모델은 계층(대형 시스템에 적당한 일반 구조 패턴)으로 체계화됩니다. 계층의 수는 고정되어 있지 않고 상황에 따라 달라집니다.

구조 분석 중에 다음 두 상위 레벨 계층에 초점을 맞춥니다. 즉, 어플리케이션비즈니스 특정 계층입니다. 이는 서브시스템의 상위 레벨 조직이 의미하는 사항입니다. 기타 하위 레벨 계층은 활동: 기존 설계 요소 통합에서 고려합니다. 특정 구조 패턴을 사용하는 경우, 서브시스템이 해당 패턴의 구조 템플리트에 대해 정의됩니다.

계층 나누기에 대한 자세한 사항은 가이드라인: 계층 나누기를 참조하십시오.

중요한 추상 개념 식별 페이지 맨 위

목적 시스템이 처리해야 하는 중요한 추상 개념(요구사항 활동 중에 식별된 개념 표시)를 식별하여 분석을 준비하기 위함입니다.

구조적 통합 수행에 초점이 맞추어진 경우, 이 단계는 결과물: POC의 구성 자산 선택시 소프트웨어 아키텍트를 가이드하고 영업대표 사용 시나리오를 지원하는데 필요한 범위까지 수행됩니다.

요구사항 활동은 일반적으로 시스템이 처리할 수 있어야 하는 중요한 개념을 밝혀냅니다. 이러한 개념은 자체를 중요한 설계 추상 개념으로 표시합니다. 작업이 이미 수행되었으므로 활동: 유스 케이스 분석 중에 식별 작업을 반복할 필요가 없습니다.

시스템의 일반 지식(예: 용어집 및 특히 도메인 모델 또는 이 있는 경우 해당 모델)을 기반으로 이러한 중요한 추상 개념을 표시하도록 예비 엔티티 분석 클래스를 식별하여 기존 지식을 이용할 수 있습니다.

중요한 추상 개념 정의시, 엔티티 클래스 간 존재하는 임의의 관계도 정의하십시오. 하나 또는 여러 클래스 다이어그램에 중요한 추상 개념을 표시하고 각각에 짧은 설명을 작성하십시오.  도메인 및 시스템의 진기함에 따라 시스템을 모델화하는데 필수인 많은 중요한 추상 개념을 캡처하는 분석 패턴이 이미 있을 수도 있습니다. 이러한 패턴의 사용(도메인에서 이미 성공적으로 사용되었어야 하는)이 표시되어야 하는 중요한 개념을 지적으로 식별하는 부담을 상당히 용이하게 합니다. [FOW97a]가 비즈니스 시스템을 모델화하는데 바로 유용한 일부 분석 패턴을 표시하지만 기타 컨텍스트에서 적용 가능할 수도 있습니다. 기타 예는 OMG(Object Management Group)로 연관 타스크 강제 실행 및 해당 도메인 기술 위원회의 작업을 통해 여러 도메인의 인터페이스와 프로토콜을 정의하도록 시도할 수도 있습니다. 불가피하게 이 작업으로 인해 도메인의 중요한 추상 개념을 식별하게 됩니다.

이 시점에서 식별된 분석 클래스가 프로젝트 과정 중에 변경되고 전개될 가능성이 큽니다. 이 단계의 목적은 설계 전반에 걸쳐 생존할 클래스 세트를 식별하기 위함이 아니라 시스템이 처리해야 하는 중요한 개념을 식별하기 위함입니다. 이 초기 단계에서 엔티티 클래스를 자세하게 설명하는데 많은 시간을 소요하지 마십시오. 왜냐하면 유스 케이스가 사실상 필수로 하는 클래스 및 관계를 식별하는 위험이 있기 때문입니다. 유스 케이스를 살펴보면 더 많은 엔티티 클래스와 관계를 찾게 됨을 기억하십시오.

스테레오타입적 상호 작용 식별 페이지 맨 위

이 단계는 시작 중 워크플로우 세부사항: 구조적 통합 수행의 일부로 구조적 분석(이 활동)을 수행하는 경우에만 포함됩니다.

이 단계의 목적은 시스템의 중요한 종류의 활동 전형이 되거나 특성을 이루는 상호 작용(시스템의 중요한 추상 개념 간)을 식별하기 위함입니다. 이러한 상호 작용은 유스 케이스 구현으로 캡처됩니다.

전개 개요 개발 페이지 맨 위

목적

시스템 구현의 실행 가능성에 액세스하는 기초를 제공하기 위함입니다.
시스템의 지리적 분배 및 운영적 복잡성의 이해를 얻기 위함입니다.
초기 노력 및 비용 견적의 기초를 제공하기 위함입니다.

소프트웨어가 전개되는 방법의 상위 레벨 개요를 제공합니다. 예를 들어, 시스템이 원격으로 액세스되거나 여러 노드에 걸처 분배해야 하는 요구사항이 있는지 판별하십시오. 고려해야할 일부 정보 소스는 다음과 같습니다.

  • 사용자 프로파일(비전) 및 유스 케이스(유스 케이스 모델)에 정의된 사용자(위치)
  • 서비스 레벨 요구사항(추가 스펙)
  • 제한조건(레가시 시스템과의 인터페이스에 대한 요구사항과 같은 추가 스펙)

비단순 분배 시스템이 필요한 경우 전개 모델이 노드 간 관계를 캡처하는데 사용될 수 있습니다. 여기에는 노드에 임시적으로 지정된 컴포넌트와 데이터가 포함되어야 하며 사용자가 데이터에 액세스하는 컴포넌트에 액세스하는 방법을 표시해야 합니다. 노드 및 연결의 자세한 스펙은 실행 가능성의 추정 또는 평가가 중요한 경우를 제외하고는 연기됩니다. 적절한 자산이 사용 가능한 경우 기존 자산이 사용될 수 있습니다. 해당 모델이 프로젝트에서 작성된 첫 번째 전개 모델이고 상위 레벨에서 빨리 작성된 경우에도 실제 하드웨어와 소프트웨어 제품이 알려진 경우나 지금 해당 제품의 선택 결정을 하는 것이 중요한 경우 실제 하드웨어 및 소프트웨어 제품을 식별할 수도 있습니다.

비기능적 요구사항 및 제한조건을 충족시키는 동안 일반적 유스 케이스를 수행하는 사용자(필요한 경우, 특히 원격 위치의 사용자)를 전개 모델이 지원함의 유효성을 확인하십시오. 노드 및 연결이 다른 노드의 컴포넌트 간 상호 작용 및 컴포넌트 및 해당 저장 데이터 간 상호 작용을 지원하는데 적절한지 유효성을 확인하십시오.

분석 메커니즘 식별 페이지 맨 위

목적 설계자가 객체에 "생명"을 제공하기 위해 사용하는 분석 메커니즘 및 서비스를 정의하기 위함입니다.

시작 중 구조적 통합을 수행하는데 초점이 맞춰진 경우, 이 단계는 이 활동에서 제외됩니다.

분석 메커니즘은 하향식(이전 지식) 또는 상향식(진행함에 따라 발견)으로 식별될 수 있습니다. 하향식 모드에서는 경험은 소프트웨어 아키텍트가 일정 문제점이 도메인에 존재하며 특정 종류의 솔루션을 필수로 한다는 것을 가이드합니다. 분석 중 메커니즘으로 표현될 수도 있는 일반 구조적 문제점의 예는 다음과 같습니다. 지속성, 트랜잭션 관리, 결함 관리, 메시징 및 인터페이스 엔진. 이러한 모든 문제점의 공통점은 각각이 시스템의 광대한 클래스의 일반 성능이며 각각이 기본 어플리케이션 기능을 지원하거나 상호 작용하는 기능을 제공한다는 것입니다. 분석 메커니즘은 구현 언어 또는 전개된 플랫폼에 상관없이 시스템의 기본 기능적 요구사항에 필수인 성능을 지원합니다. 분석 메커니즘은 또한 여러 다른 방법으로 설계되어 구현될 수도 있습니다. 일반적으로 각 분석 메커니즘에 대응하는 둘 이상의 설계 메커니즘과 각 설계 메커니즘을 구현하는 둘 이상의 방법이 있을 수도 있습니다.

상향식 접근법은 분석 메커니즘이 드디어 생긴 경우입니다. 해당 메커니즘은 소프트웨어 아키텍트가 처음에는 어렴풋할 가능성이 있지만 여러 문제점의 솔루션 세트에서 나오는 공통된 주제를 확인함에 따라 작성됩니다. 다른 스레드에 있는 요소가 해당 시계를 동기화하는 방법을 제공해야 하며 자원을 할당하는 공통 방법이 필요합니다. 분석 언어를 단순화하는 분석 메커니즘은 이러한 패턴에서 나옵니다.

분석 메커니즘의 식별은 공통된 내재적일 가능성이 있는(시스템이 의미하는 요구사항) 종속 문제점이 있는지 식별하고 해당 문제점에 이름을 지정하는 것을 의미합니다. 초기에는 이름이 존재하는 모든 것일 수 있습니다. 예를 들어, 소프트웨어 아키텍트가 시스템에 지속성 메커니즘이 필수일 것임을 인식합니다. 결국, 이 메커니즘은 클래스 집단([BOO98] 참조)의 공동 작업을 통해 구현되며, 일부는 어플리케이션 기능을 직접 전달하지 않으며 단지 해당 기능을 지원하기 위해 존재합니다. 이러한 지원 클래스는 흔히 계층화된 구조의 중간 또는 낮은 계층에 있어 모든 어플리케이션 레벨 클래스에 공통 지원 서비스를 제공합니다.

식별된 종속 문제점이 충분히 일반적인 경우, 해당 메커니즘에 있는 패턴이 기존 클래스를 바인드하고 패턴이 요구한대로 새 클래스를 구현함으로써 실증될 수 있습니다. 이러한 방식으로 작성된 분석 메커니즘은 추상적이며 설계 및 구현을 통해 보다 정제되어야 합니다.

자세한 정보는 개념: 메커니즘 분석을 참조하십시오.

결과 검토 페이지 맨 위

목적 구조 분석의 결과가 완료되고 일치하는지 확인하기 위함입니다.

구조 분석이 완료됨에 따라, 구조적 메커니즘과 완료되어 일치하는지 확인하기 위해 식별된 클래스, 패키지, 서브시스템을 검토하십시오. 구조적 분석의 결과가 예비적이고 비교적 비공식적이므로 검토도 비공식적이어야 합니다. 시나리오 또는 유스 케이스를 사용하여 비즈니스 관점에서 발생하는 특정 상호 작용까지 여러 레벨에서 작성된 구조적 선택의 유효성을 확인할 수 있습니다.

이 활동의 결과를 평가하는데 대한 자세한 정보는 체크포인트: 소프트웨어 구조 문서 - 구조적 분석 고려사항을 참조하십시오.



Rational Unified Process   2003.06.15