중간 산출물: 참조 아키텍처
실제로 중간 산출물은 사전 정의된 아키텍처 패턴 또는 패턴 세트로, 특정 비즈니스와 기술 컨텍스트에서 지원 아티팩트와 함께 사용할 수 있도록 부분적으로 또는 전체적으로 인스턴스화, 디자인 및 증명됩니다.
목적

참조 아키텍처 중간 산출물은 조직에서 재사용가능한 자산 기반의 일부입니다. 해당 목적은 아키텍처 개발의 시작점을 형성하기 위함입니다. 이미 작성된 아키텍처 패턴, 아키텍처 메커니즘프레임워크에서 사용이 증명된 알려진 특성이 있는 완전한 시스템까지 범위가 다양할 수 있습니다. 시스템에 걸친 도메인의 광범위한 클래스 또는 일반적으로 에 적용 가능하거나 보다 협소한 도메인 특정 중점이 있을 수 있습니다.

테스트된 참조 아키텍처의 사용은 해당 요구사항을 만족시키는 사용법을 통해 알려진 기존 참조 아키텍처를 선택하여 여러 비기능적 요구사항(특히, 품질 요구사항)을 설명하는 효율적인 방법입니다. 참조 아키텍처가 다른 레벨의 추상 개념 및 다른 시점에서 사용되거나 존재할 수도 있습니다. 이는 4+1보기에 해당합니다("전형적인 아키텍처 보기 세트 참조"). 이런 방법으로, 소프트웨어 설계자가 다양한 완료 정도에 가장 적합한 사항(단지 아키텍처 디자인 또는 디자인 및 구현)을 선택할 수 있습니다.  

종종, 참조 아키텍처는 시스템을 구성하는 데 사용되는 컴포넌트의 인스턴스를 포함하지 않도록 정의됩니다. 이런 경우 해당 아키텍처는 제품 라인 아키텍처가 되지만 쉽게 구별할 수가 없습니다. RUP에서 참조 아키텍처의 개념을 사용하여 참조가 재사용가능한 기존 컴포넌트(구현)를 포함하도록 합니다.

관계
역할책임이 있음: 수정자:
입력 대상필수:
  • 없음
선택사항: 외부:
  • 없음
산출 지점
설명
간략한 아웃라인

자산 조직

참조 아키텍처 자산을 소유하는 조직이 새 시스템의 선택 기준과 일치시켜 소프트웨어 설계자가 쉽게 검색하도록 자산을 구분하고 구성하는 방법을 판별해야 합니다. 참조 아키텍처의 작성 및 저장이 현재 RUP 범위 밖일지라도 도메인이 일부 시스템 관점 또는 시스템군의 지식과 개념을 정의하는 주제 영역인 도메인의 아이디어를 중심으로 아키텍처가 구성되는 것은 한 제안사항입니다. 여기서, 응용프로그램의 아래 레벨에서 '도메인' 용어의 사용을 허용합니다. 이 사용법은 일부 정의(예: [HOF99]에 표시)와 약간 다르지만 [LMFS96]에 표시된 정의와는 부합합니다.

"제품 라인 도메인: 제품 라인 전체에서 공통성의 식별, 기술적 처리 및 관리를 위해 커뮤니케이션, 분석 및 엔지니어링을 용이하게 하도록 정의된 기능의 제한된 그룹(현재 및/또는 장래). 그러한 도메인으로는 밀접하게 연관된 일반 사용자 시스템 그룹, 여러 시스템에서 공통으로 사용되는 기능 또는 광범위하게 적용 가능한 기본 서비스 그룹이 있을 수 있습니다."

이 정의에는 시스템을 구성하는데 사용하는 사항이 자체 권한으로 연구할 가치가 있는 도메인에 속한다는 개념을 포함합니다. [LMFS96]에서 발췌한 다음 그림이 이 원리를 설명합니다.

미국 육군 수평 및 수직 도메인

미국 육군의 수평 및 수직 도메인

이 그림이 주요 시스템군, 정보 시스템, 명령 및 제어와 무기 시스템을 각각 일부 완전히 포함하는 수직 도메인과 이러한 사항 및 시스템군 또한 가로지르는 수평 도메인과 함께 표시합니다. 따라서 실시간 스케줄링 개념이 명령 및 제어의 전술 도메인과 무기 시스템의 모든 수직 도메인에 적용 가능합니다. 따라서 이러한 모든 도메인에 대해 실시간 스케줄링 문제점을 해결하고 지식과 자산을 별개 도메인으로서 개발한 것처럼 취급하는 것은 이치에 맞을 가능성이 큽니다. 그런 다음 이 별개 도메인은 예를 들어 개인 정보 시스템이 아닌 전자전과 연관됩니다.

컨텐츠

참조 아키텍처는 중간 산출물: 소프트웨어 아키텍처 문서 및, 참조 아키텍처가 자산 기반에서 적절하게 분류되도록 프로젝트 참조 및 특성을 일반화하거나 프로젝트 특정 참조를 제거한 연관 모델과 동일한 양식을 갖습니다. 소프트웨어 아키텍처 문서(SDA)와 연관된 일반적인 모델은 유스 케이스 모델, 디자인 모델, 구현 모델 및 배치 모델입니다.

SAD 및 연관 모델에 대한 액세스가 소프트웨어 설계자의 여러 시작점을 제공합니다. 해당 설계자가 아키텍처의 개념적 또는 논리적 파트만을 사용하도록 선택할 수 있습니다(오퍼레이션의 재사용 정책이 허용하는 경우). 다른 한편으로는 소프트웨어 설계자가 자산 기반 완료 작업 서브시스템 및 실제 레벨의 배치 모델에서 선택할 수도 있습니다(완전한 하드웨어 및 네트워크 청사진).

아키텍처 자산을 사용 가능하게 하려면 기타 지원 중간 산출물이 필요합니다. 

  1. 유스 케이스 모델이 아키텍처의 동작을 설명하지만 소프트웨어 설계자도 해당 비기능적 품질에 대해 알아야 합니다. 이러한 두 개의 유스 케이스 모델 및 비기능적 요구사항은 소프트웨어 요구사항 스펙에서 이미 캡처되었을 수도 있습니다. 이로써, 소프트웨어 설계자가 참조 아키텍처의 현재 요구사항 충족 정도를 판별할 수 있습니다.

  2. 사용, 특히 아키텍처의 수정이 원래 개발과 동일한 안내를 필수로 합니다. 예를 들어, 소프트웨어 설계자가 참조 아키텍처의 형성에 적용된 규칙 및 인터페이스 수정의 어려움 정도를 알아야 합니다. 참조 아키텍처와 연관된 디자인 가이드라인에 액세스하면 해당 질문에 대한 대답에 도움을 얻을 수 있습니다.

  3. (선택사항)임의의 관련된 기존 테스트 계획을 검토하는 것 또한 유용할 수 있습니다. 이러한 테스트 계획은 이전에 유사한 아키텍처를 테스트하는데 사용한 테스트 및 평가 전략을 설계자에게 알려줍니다. 이로써, 아키텍처의 잠재적인 약점에 대한 통찰력을 제공할 가능성이 큽니다.

  4. (선택사항)임의의 관련된 기존 테스트 자동화 아키텍처 및 테스트 인터페이스 스펙을 검토하는 것이 유용할 수 있습니다. 이러한 중간 산출물은 테스트를 용이하게 하는 아키텍처로 구성되었을 수 있는 요청을 설계자에게 알려줍니다.

기본 설명

자산 조직

참조 아키텍처 자산을 소유하는 조직이 새 시스템의 선택 기준과 일치시켜 소프트웨어 설계자가 쉽게 검색하도록 자산을 구분하고 구성하는 방법을 판별해야 합니다. 현재 RUP 범위에서 참조 아키텍처를 작성하고 저장할 수는 없지만 도메인이 일부 시스템 관점 또는 시스템군에 대한 개념 및 지식을 정의하는 주제 영역인 용어 정의: 도메인이라는 아이디어 위주로 아키텍처를 구성하도록 제안할 수 있습니다. 여기서, 응용프로그램의 아래 레벨에서 '도메인' 용어의 사용을 허용합니다. 이 사용법은 일부 정의(예: [HOF99]에 표시)와 약간 다르지만 [LMFS96]에 있는 정의와는 부합합니다.

"제품 라인 도메인: 제품 라인 전체에서 공통성의 식별, 기술적 처리 및 관리를 위해 커뮤니케이션, 분석 및 엔지니어링을 용이하게 하도록 정의된 기능의 제한된 그룹(현재 및/또는 장래). 그러한 도메인으로는 밀접하게 연관된 일반 사용자 시스템 그룹, 여러 시스템에서 공통으로 사용되는 기능 또는 광범위하게 적용 가능한 기본 서비스 그룹이 있을 수 있습니다."

이 정의에는 시스템을 구성하는데 사용하는 사항이 자체 권한으로 연구할 가치가 있는 도메인에 속한다는 개념을 포함합니다. [LMFS96]에서 발췌한 다음 그림이 이 원리를 설명합니다.

미국 육군의 수평 및 수직 도메인

미국 육군의 수평 및 수직 도메인

이 그림이 주요 시스템군, 정보 시스템, 명령 및 제어와 무기 시스템을 각각 일부 완전히 포함하는 수직 도메인과 이러한 사항 및 시스템군 또한 가로지르는 수평 도메인과 함께 표시합니다. 따라서 실시간 스케줄링 개념이 명령 및 제어의 전술 도메인과 무기 시스템의 모든 수직 도메인에 적용 가능합니다. 따라서 이러한 모든 도메인에 대해 실시간 스케줄링 문제점을 해결하고 지식과 자산을 별개 도메인으로서 개발한 것처럼 취급하는 것은 이치에 맞을 가능성이 큽니다. 그런 다음 이 별개 도메인은 예를 들어 개인 정보 시스템이 아닌 전자전과 연관됩니다.

컨텐츠

참조 아키텍처는 중간 산출물: 소프트웨어 아키텍처 문서 및, 참조 아키텍처가 자산 기반에서 적절하게 분류되도록 프로젝트 참조 및 특성을 일반화하거나 프로젝트 특정 참조를 제거한 연관 모델과 동일한 양식을 갖습니다. 소프트웨어 아키텍처 문서(SDA)와 연관된 일반적인 모델은 유스 케이스 모델, 디자인 모델, 구현 모델 및 배치 모델입니다.

SAD 및 연관 모델에 대한 액세스가 소프트웨어 설계자의 여러 시작점을 제공합니다. 해당 설계자가 아키텍처의 개념적 또는 논리적 파트만을 사용하도록 선택할 수 있습니다(오퍼레이션의 재사용 정책이 허용하는 경우). 다른 한편으로는 소프트웨어 설계자가 자산 기반 완료 작업 서브시스템 및 실제 레벨의 배치 모델에서 선택할 수도 있습니다(완전한 하드웨어 및 네트워크 청사진).

기타 지원 아티팩트가 아키텍처 자산을 재사용가능하는데 필수입니다.  

  1. 유스 케이스 모델이 아키텍처의 동작을 설명하지만 소프트웨어 설계자도 해당 비기능적 품질에 대해 알아야 합니다. 이러한 두 유스 케이스 모델 및 비기능적 요구사항은 소프트웨어 요구사항 스펙에서 이미 캡처되었을 수 있습니다. 이로써, 소프트웨어 설계자가 참조 아키텍처의 현재 요구사항 충족 정도를 판별할 수 있습니다.

  2. 사용, 특히 아키텍처의 수정이 원래 개발과 동일한 안내를 필수로 합니다. 예를 들어, 소프트웨어 설계자가 참조 아키텍처의 형성에 적용된 규칙 및 인터페이스 수정의 어려움 정도를 알아야 합니다. 참조 아키텍처와 연관된 디자인 가이드라인에 액세스하면 해당 질문에 대한 대답에 도움을 얻을 수 있습니다.

  3. (선택사항)임의의 관련된 기존 테스트 계획을 검토하는 것 또한 유용할 수 있습니다. 이러한 테스트 계획은 이전에 유사한 아키텍처를 테스트하는데 사용한 테스트 및 평가 전략을 설계자에게 알려줍니다. 이로써, 아키텍처의 잠재적인 약점에 대한 통찰력을 제공할 가능성이 큽니다.

  4. (선택사항)임의의 관련된 기존 테스트 자동화 아키텍처 및 테스트 인터페이스 스펙을 검토하는 것이 유용할 수 있습니다. 이러한 아티팩트는 테스트를 용이하게 하는 아키텍처에서 작성될 수 있는 적절한 요청의 아키텍처를 알려줍니다.

특성
선택사항
계획됨Yes
사용자 조정
표시 옵션UML 표시: 여러 관련된 아키텍처 보기(유스 케이스, 논리, 프로세스, 배치, 구현, 데이터).

시스템이 완전히 새롭지 않은 이상 참조 아키텍처는 적용 가능성(도메인 및 개발 유형에 대한)에 대해 존재 여부와 개발 조직에 액세스될 수 있는지를 점검해야 합니다. 참조 아키텍처의 작성은 조직 레벨에서 설명되어야 할 문제입니다. 위의 컨텐츠 목록을 줄이고 여전히 아키텍처 재사용으로 일부 장점을 달성하는 것은 확실히 가능합니다. 예를 들어, 아키텍처가 수정되면 테스트를 재작성해야 하지만 테스트 모델을 생략하는 것은 가능합니다. 최소한 디자인 모델 및 일부 작동 설명(유스 케이스 모델의 가능성이 있음)이 기대됩니다. 이 기준에 도달하지 못하면 자산을 참조 아키텍처라고 하기가 어렵습니다. 그러나 유효한 패턴일 수는 있습니다.