본질적으로, 참조 구조는 사전 정의된 구조 패턴 또는 패턴 세트로 특정 비즈니스와 기술 컨텍스트에서 지원 결과물과 함께 사용 가능하도록 부분적으로 또는 완전히 실증되어 설계되고 증명됩니다. 이러한 결과물은 종종 이전 프로젝트에서 얻습니다.  
역할:  소프트웨어 아키텍트 
선택 가능성/발생 시기:  선택사항. 초기화 및 구현화 단계.
템플리트 및 보고서: 
     
예: 
     
UML 표시:  여러 관련된 구조 보기(유스 케이스, 논리적, 프로세스, 전개, 구현, 데이터).
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

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

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

종종, 참조 구조가 시스템을 구성하는데 사용하는 컴포넌트의 인스턴스를 포함하지 않도록 정의됩니다. 그런 경우, 해당 구조는 제품 라인 구조가 되지만 이는 분명하고 빠른 구별이 아닙니다. RUP에서 참조 구조의 개념을 사용하여 참조가 재사용 가능한 기존 컴포넌트(구현)를 포함하도록 합니다.

간략한 개요 페이지 맨 위

자산 조직

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

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

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

가로 및 세로 US 육군 도메인

US 육군의 가로 및 세로 도메인

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

컨텐츠

참조 구조에는 결과물: 소프트웨어 구조 문서프로젝트 특정 참조를 제거하거나 프로젝트 참조 및 특성을 일반화한 연관된 모델과 동일한 양식이 있어 참조 구조가 자산 기반으로 적절하게 분류될 수도 있습니다. SDA(Software Architecture Document)와 연관된 일반적인 모델은 유스 케이스 모델, 설계 모델, 구현 모델 및 전개 모델입니다.

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

기타 지원 결과물이 구조 자산을 재사용 가능하는데 필수입니다.  

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

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

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

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

시기 페이지 맨 위

참조 구조는 구조 통합 및 후보 구조의 선택 중 초기화 및 초기 구현화에 사용됩니다. 참조 구조의 작성은 조직상의 사안이며 현재 RUP의 범위 밖에 있습니다. 프로젝트 종료 중에, 프로젝트 중 작성된 결과물이 조직의 자산 기반에서 획득되고 보유될 수 있는 사항이 있는지를 확인하도록 검사되지만 이를 수행하기 위해 사용된 활동과 기술은 여기에서 구현되지 않습니다.

책임 페이지 맨 위

소프트웨어 아키텍트는 참조 구조의 선택 및 사용에 대한 책임이 있습니다.

사용자 정의 페이지 맨 위

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



Rational Unified Process   2003.06.15