결과물:
|
![]() |
전개 모델이 런타임시 처리 노드의 구성, 노드 간 의사소통 링크 및 노드에 있는 컴포넌트 인스턴스 및 객체를 표시합니다. |
---|---|
역할: | 소프트웨어 아키텍트 |
선택 가능성/발생 시기: | 선택사항. |
템플리트 및 보고서: |
|
예: | |
UML 표시: | 모델. |
자세한 정보: |
활동 정보: | 활동 결과: |
전개 모델의 목적은 시스템의 처리 요소 간 연결 및 처리 요소의 구성을 캡처하는 것입니다. 전개 모델은 하나 이상의 노드(최소 하나의 프로세서, 메모리 및 기타 장치가 있는 처리 요소), 장치(추상 개념의 모델화된 레벨에 있는 처리 성능이 없는 스테레오타입화된 노드), 노드 간 및 노드와 장치 간 커넥터로 구성됩니다. 전개 모델은 프로세스를 해당 처리 요소에 맵핑하여 노드에 걸친 작동의 분배가 표시되도록 허용합니다.
다음 역할이 전개 모델을 사용합니다.
등록 정보 이름 |
간략한 설명 |
UML 표시 |
---|---|---|
소개 | 모델에 대한 간단한 소개 역할을 하는 텍스트 설명. | "간단한 텍스트" 유형의 태그값. |
노드 | 시스템의 처리 요소. 노드에는 다음 등록 정보가 있을 수 있습니다.
|
노드 |
장치 | 처리 성능이 없는 실제 장치로(추상 개념의 모델화된 레벨의) 프로세서 노드를
지원합니다. 장치에는 다음 등록 정보가 있을 수 있습니다.
|
스테레오타입화된 노드 |
커넥터 | 노드와 장치 사이 및 노드 간 연결. 커넥터에는 용량 또는 커넥터 대역폭에 관한 연관 정보가 있을 수 있습니다. |
예를 들어, 다른 종류의 커넥터를 모델화하는 스테레오타입화되었을 가능성이 높은 연관. |
다이어그램 | 패키지에 포함된 모델의 다이어그램. |
일반적으로 전개 모델은 아래 표시된 다이어그램과 같은 다이어그램으로 묘사됩니다.
초기화 단계에서 소프트웨어 아키텍트가 요구사항(특히 비기능적 요구사항)을 만족시키는 최소 하나의 실행 가능 구조를 식별하려는 경우, 전개 환경이 아직 없으면 구조적 통합의 일부로 모델이 개념적 레벨에서 작성됩니다. 프로젝트 관리자가 비용을 추정하는데 전개 모델도 사용합니다.
그러나 시스템이 이미 있는 환경으로 전개되는 경우 해당 환경이 문서화됩니다. 캡처될 주요 요소는 다음과 같습니다.
구현화 단계에서 전개 모델은 스펙 레벨로 정제되어 소프트웨어 아키텍트가 최종적으로 모델을 실제 레벨로 사용하기 전에 자신있는 성능을 예상하도록 합니다. 실제 레벨에서 사용될 실제 하드웨어와 모델 번호를 지정하고, 모델이 시스템 취득, 설치 및 유지보수의 계획이 됩니다.
전개 환경이 이미 있는 경우, 개발 중인 시스템의 새 성능을 지원할 수 있는지 여부를 판별하도록 검사됩니다. 전개 환경에 변경이 필요한 경우, 이 단계에서 식별됩니다.
전개 환경이 아직 없는 경우, 구조를 지원하는데 필요한 노드의 번호, 유형 및 구성과 노드 간 연결이 정의됩니다. 다음을 포함하는 구조의 주요 전개 관점이 조사되고 설명됩니다.
컴포넌트가 변경되는 경우 노드로의 컴포넌트 할당 또는 노드로의 장치 전개가 갱신됩니다.
전개 환경이 아직 없는 경우, 일반적으로 소프트웨어 개발 노력과 함께 실행되는 하드웨어 조달 및 설치 노력이 있습니다. 성능 위험을 완화하고(전개된 소프트웨어가 승인 가능한 성능, 응답 시간 또는 처리량 특성을 시연함) 기술 및 가격/성능 개선을 이용하도록 최종 하드웨어 구입에 대한 확약을 가능한 오래 지연하도록 권장합니다. 구성 중에 성능 사안이 생기면 이상적으로는 소프트웨어 아키텍트가 이러한 사안을 설명할 때 소프트웨어 자체의 구조뿐 아니라 전개 모델을 수정할 자유도 갖아야 합니다.
전개 환경이 설치될 시스템에 준비가 되어 있습니다. 소프트웨어가 하나 이상의 베타 테스트를 수행함에 따라 하나 이상의 테스트/시도 전개가 발생합니다. 소프트웨어는 결국 전개 환경으로 전이됩니다.
소프트웨어 아키텍트가 전개 모델에 대한 책임이 있습니다.
전개 모델은 단일 프로세서 시스템 또는 처리 분배가 없거나 거의 없는 단순 시스템에 대해 선택사항입니다.
복잡한 네트워크 또는 프로세서 구성의 시스템에는 필수입니다.
Rational Unified Process
|