아키텍처 개요 개발
목적
|
상위 레벨 아키텍처 옵션을 탐색하고 평가하여 시스템 계획을 용이하게 합니다.
의도한 시스템의 상위 레벨 구조를 조기에 이해하여 후원자, 개발 팀 및 기타 이해 당사자(stakeholder)에게 전달합니다.
|
아키텍처 개요는 프로젝트 라이프사이클의 초기, 도입/인식(Inception) 단계에서 작성될 수 있습니다. 비전 구현에 관한 조기 결정과 가정을 반영하며, 실제 및 논리 아키텍처에 관한 결정과 시스템의 비기능적
요구사항도 반영합니다. 이는 종종 프로젝트 후원자와의 협업을 통해 소프트웨어 설계자가 생성하며, 형식에 구애받지 않는 풍부한 그림 스토리보드 또는 아이콘 그래프 형태를 가집니다. 개념적으로, 제안된 솔루션의
본질적인 특성을 설명하며, 핵심 개념을 전달하고 주요 빌딩 블록을 포함하고 있습니다. 아키텍처 개요의 형식성 레벨은 프로젝트에 따라 다릅니다. 예를 들어, 많은 의식(ceremony)을 가지는 대규모 프로젝트에서는
공식적으로 검토할 수 있도록 소프트웨어 아키텍처 문서의 해당 섹션에 아키텍처 개요를 캡처해야 할 수도 있습니다.
현재까지 아키텍처 개요는 잠정적인 첫 번째 패스입니다. 실행 가능한 아키텍처 프로토타입이 디자인, 구현, 배치 관심사항을 비롯하여 아키텍처의 유효성을 검증할 때까지 아키텍처 개요 다이어그램을 기반으로 확약하지
마십시오.
참조 아키텍처, 다른 아키텍처 패턴 또는 기타 아키텍처 자산을 기반으로 한 아키텍처를 고려하십시오.
커뮤니케이션 수단의 역할을 하도록 아키텍처 개요 다이어그램을 정제하고 유지보수할지 여부를 고려하십시오.
어쩔 수 없이 많은 시스템이 기존 하드웨어 및 소프트웨어 환경에서 개발 및 배치되어야 합니다. 이를 위해 소프트웨어 설계자는 현재 환경에 대한 정보를 수집합니다.
예를 들어, e-business 시스템 개발 시 다음 정보가 관련됩니다.
-
기존 네트워크 논리 및 실제 디자인
-
기존 데이터베이스 및 데이터베이스 디자인
-
기존 웹 환경(서버, 방화벽 등)
-
기존 서버 환경(구성, 소프트웨어 버전, 계획된 업그레이드)
-
기존 표준(네트워크, 이름 지정, 프로토콜 등)
텍스트 또는 배치 모델로 이러한 정보를 캡처할 수 있습니다.
|
사용 가능한 자산 조사
목적
|
프로젝트와 관련될 수 있는 자산 식별.
자산과 프로젝트 요구사항 간의 일치 및 차이 분석.
시스템의 영역을 자산의 기반으로 할지 여부 결정.
프로젝트에서 잠재적으로 재사용가능한 자산을 찾아 나열.
필수 지원을 잠재적으로 사용할 수 있도록 예비 평가 수행.
|
자산이 고려되는 환경의 요구사항, 필요한 일반적인 기능성 및 시스템 범위를 이해해야 합니다. 조직적 자산 기반 및 업계 문서를 검색하여 자산 또는 유사한 프로젝트를 식별하십시오. 업계 모델, 프레임워크, 클래스,
경험 등 고려할 몇 가지 유형의 자산이 있습니다(여기에 국한되지는 않음). 가용 자산이 현재 프로젝트의 주요 당면 과제를 해결하는 데 도움이 되는지 여부 및 프로젝트의 제한조건과 호환 가능한지 여부를 평가해야
합니다.
자산과 고객 요구사항 간의 일치 정도를 분석하고 자산 사용을 위해 요구사항이 협상 가능한지 여부를 고려해야 합니다.
자산을 수정하거나 확장하여 요구사항을 충족시킬 수 있는지 여부와 자산을 채택할 경우 비용, 위험성 및 기능성 면에서 어떤 절충이 있는지 평가하십시오.
마지막으로, 원칙적으로 하나 이상의 자산을 사용할지 결정하고, 이런 결정을 내린 근거를 설명하십시오.
|
서브시스템의 상위 레벨 조직 정의
도입/인식(Inception) 중에 아키텍처 통합을 수행하는 데 초점을 맞추고 있는 경우, 이 단계는 이 타스크에서 제외됩니다.
일반적으로 디자인 모델은 계층으로 구성됩니다(중간에서 대규모 시스템에 이르기까지 공통적인 아키텍처 패턴). 계층 수는 정해져 있지 않고 상황에 따라 달라집니다.
아키텍처 분석 중에는 보통 두 개의 상위 레벨 계층 즉, 응용프로그램 계층과 비즈니스 특정 계층에 초점을 맞춥니다. 이것이 서브시스템의 상위 레벨 조직의 의미입니다. 기타 하위
레벨 계층은 타스크: 기존 디자인 요소 통합에서 고려됩니다. 특정 아키텍처 패턴을 사용 중인 경우, 해당 패턴의 아키텍처 템플리트를
중심으로 서브시스템이 정의됩니다.
계층화에 대한 자세한 정보는 중간 산출물 가이드라인: 계층화를 참조하십시오.
|
핵심 추상 식별
목적
|
시스템이 처리해야 하는 핵심 추상을 식별하여 분석 준비(비즈니스 모델링 타스크(해당되는 경우) 및 요구사항 타스크 중 식별된 개념 표시).
|
아키텍처 통합을 수행하는 데 초점을 맞추고 있는 경우, 이 단계는 중간 산출물: 아키텍처 개념 검증 구현/구축(Construction)을 위한 자산 선택 시 소프트웨어 설계자를 안내하고 대표
사용 시나리오를 지원하는 데 필요한 정도로 수행됩니다.
일반적으로 요구사항 타스크 및 비즈니스 모델링 타스크(해당되는 경우)는 시스템이 처리할 수 있어야 하는 핵심 개념은 다루지 않습니다. 이런 개념은 핵심 디자인 추상으로 나타납니다. 이미 작업이 수행되었으므로 타스크: 유스 케이스 분석 중 식별 작업을 다시 반복하지 않아도 됩니다.
요구사항, 용어집, 특히 도메인 모델이나 비즈니스 분석 모델(있는 경우)과 같은 시스템에 대한 일반적인 지식을 기반으로 이런 핵심 추상을 나타내기 위해, 예비 엔티티 분석
클래스를 식별하여 기존 지식을 활용할 수 있습니다.
핵심 추상을 정의할 때 엔티티 클래스 간에 존재하는 관계도 정의하십시오. 하나 또는 여러 클래스 다이어그램으로 핵심 추상을 표시하고 각각에 대한 간략한 설명을 작성하십시오. 도메인, 시스템의 참신성 정도에
따라 시스템을 모델링하는 데 필요한 다수의 핵심 추상을 캡처하는 분석
패턴이 이미 존재할 수 있습니다. 이러한 패턴(도메인에서 이미 사용되었어야 함)은 표시되어야 하는 중요한 개념을 식별하는 부담을 상당히 줄여줍니다. [FOW97a]는 비즈니스 시스템 모델링에 즉시 유용한 일부 분석 패턴을 표시하지만 다른 컨텍스트에서 적용될 수도 있습니다. 또 다른 예인
OMG(Object Management Group) 역시 도메인 기술 위원회 및 연관된 타스크 포스의 작업을 통해 많은 도메인에 대한 인터페이스와 프로토콜을 정의하려고 시도합니다. 필연적으로 이 작업은 도메인의
중요한 추상 식별로 이어집니다.
이 때 식별된 분석 클래스는 프로젝트 진행 중에 변경 및 발전됩니다. 이 단계의 목적은 디자인 내내 존속할 클래스 세트를 식별하는 것이 아니라 시스템이 처리해야 하는 핵심 개념을 식별하는 것입니다. 실제로 유스
케이스가 필요로 하지 않는 클래스와 관계를 식별하게 될 위험성이 있으므로 이 초기 단계에서 엔티티 클래스를 자세히 설명하느라 너무 많은 시간을 소비하지 마십시오. 유스 케이스를 살펴보면 엔티티 클래스와 관계를 더
많이 찾을 수 있음을 기억하십시오.
|
스테레오타입 상호작용 식별
이 단계는 도입/인식(Inception) 중에 이 타스크를 수행하는 경우에만 포함됩니다.
이 단계의 목적은 시스템에서 중요한 종류의 활동을 나타내거나 특징짓는상호작용을 시스템의 핵심 추상 간에 식별하는 것입니다. 이러한 상호작용은 유스 케이스 실현(realization)으로 캡처됩니다.
|
배치 개요 개발
목적
|
시스템 구현의 실현 가능성을 평가하기 위한 기초 제공.
시스템의 지리적 분배 및 운영상의 복잡도 이해.
조기 노력과 비용 예상을 위한 기초 제공.
|
소프트웨어 배치 방법에 대한 상위 레벨 개요를 개발하십시오. 예를 들어, 시스템에 원격으로 액세스해야 하는지 여부 또는 다중 노드로의 분배를 필요로 하는 요구사항이 있는지 여부를 판별하십시오. 고려할 일부 정보
소스는 다음과 같습니다.
-
사용자 프로파일(비전에서) 및 유스 케이스(유스 케이스 모델에서)에 정의된 사용자(위치에서)
-
비즈니스 데이터 조직(사용 가능한 경우 디자인 모델 및 비즈니스 분석 모델에서)
-
서비스 레벨 요구사항(보충 스펙에서)
-
제한조건(레거시 시스템과 상호작용하기 위한 요구사항과 같은 보충 스펙에서)
중요한 분산 시스템이 필요한 경우, 배치 모델을 사용하여 노드 간의 관계를 캡처할 수 있습니다. 여기에는 컴포넌트와 데이터의 잠정 노드 지정이 포함되어야 하며, 사용자가 데이터에 액세스하는 컴포넌트에 액세스하는
방법을 표시해야 합니다. 실현 가능성을 예상하거나 평가하는 데 중요한 경우를 제외하고 노드 및 연결 세부 스펙은 연기됩니다. 적절한 자산이 있는 경우 기존 자산을 사용할 수 있습니다. 이것이 프로젝트에 생성되는 첫
번째 배치 모델이고 상위 레벨에서 신속히 생성되긴 하지만 알려진 경우 또는 지금 이 선택 결정을 하는 것이 중요한 경우에는 실제 하드웨어 및 소프트웨어 제품을 식별할 수 있습니다.
배치 모델이 비기능적 요구사항과 제한조건을 충족하면서 일반 유스 케이스를 수행하는 사용자(특히 필요한 경우 원격 위치의 사용자)를 지원하는지 유효성을 검증하십시오. 노드와 연결이 서로 다른 노드의 컴포넌트 간에,
컴포넌트 및 저장된 데이터 간에 상호작용을 지원하기에 적합한지 유효성을 검증하십시오.
|
분석 메커니즘 식별
목적
|
디자이너가 오브젝트에 "생명"을 불어 넣기 위해 사용하는 분석 메커니즘과 서비스 정의.
|
도입/인식(Inception) 중에 아키텍처 통합을 수행하는 데 초점을 맞추고 있는 경우, 이 단계는 이 타스크에서 제외됩니다.
분석 메커니즘은 하향식(선험적 지식) 또는 상향식(진행해가면서 발견됨)으로 식별할 수 있습니다. 하향식 모드에서 소프트웨어 설계자는 경험을 통해 도메인에 특정 문제가 있어 특정 종류의 솔루션이 필요함을 알 수
있습니다. 분석 중 메커니즘으로 표현될 수 있는 공통 아키텍처 문제점의 예로는 지속성, 트랜잭션 관리, 결함 관리, 메시지 전달, 추론 엔진이 있습니다. 이 모두의 공통적인 측면은 각각이 광범위한 시스템 클래스의
일반적인 기능이며, 각각 기본 응용프로그램 기능성을 지원하거나 이와 상호작용하는 기능성을 제공한다는 점입니다. 분석 메커니즘은 배치된 플랫폼이나 구현 언어에 관계없이 시스템의 기본적인 기능적 요구사항에 필요한
기능을 지원합니다. 또한 다수의 서로 다른 방법으로 분석 메커니즘을 디자인하고 구현할 수 있습니다. 일반적으로 각 분석 메커니즘에 두 개 이상의 디자인 메커니즘이 해당되며, 각 디자인 메커니즘을 구현하는 방법이 두
가지 이상입니다.
상향식 접근 방식은 궁극적으로 분석 메커니즘이 생성되는 토대입니다. 소프트웨어 설계자가 솔루션 세트에서 다양한 문제점에 이르기까지 공통된 주제를 보게 되면서(처음에는 희미하게) 분석 메커니즘이 작성됩니다. 서로
다른 스레드의 요소에 클럭을 동기화할 방법을 제공할 필요성이 있으며, 자원을 할당하는 공통적인 방법이 필요합니다. 분석 언어를 단순화하는 분석 메커니즘은 이러한 패턴에서 등장합니다.
분석 메커니즘 식별은 공통적이고 내재적인(시스템 요구사항이 이를 암시한다는 점에서) 하위 문제점이 존재함을 식별하고 이름을 지정함을 의미합니다. 처음에는 이름 뿐일 수도 있습니다. 예를 들어,
소프트웨어 설계자는 시스템이 지속성 메커니즘을 필요로 함을 인식합니다. 궁극적으로 이 메커니즘은 클래스 모음([BOO98] 참조)의 협업을 통해
구현되는데, 일부는 응용프로그램 기능성을 직접 전달하지 않고 지원하기 위해서만 존재합니다. 이러한 지원 클래스는 계층화된 아키텍처의 중간 이하 계층에 있는 경우가 많으므로 모든 응용프로그램 레벨 클래스에 공통된
지원 서비스를 제공합니다.
식별된 하위 문제점이 충분히 공통적일 경우, 패턴에 필요한 대로 새 클래스를 구현하고 기존 클래스를 바인딩하여 메커니즘을 인스턴스화할 수 있는 패턴이 존재합니다. 이런 식으로
생성된 분석 메커니즘은 추상적이므로 디자인 및 구현을 통해 더 정제해야 합니다.
자세한 정보는 개념: 분석 메커니즘을 참조하십시오.
|
결과 검토
목적
|
아키텍처 분석 결과가 완전하고 일관되도록 합니다.
|
아키텍처 분석을 마치면 식별된 아키텍처 메커니즘, 서브시스템, 패키지 및 클래스를 검토하여 완전하고 일관되도록 하십시오. 아키텍처 분석 결과가 예비적이고 비교적 비정규적인 경우, 검토 역시 비정규적이어야 합니다.
시나리오 또는 유스 케이스를 사용하여 여러 레벨(비즈니스 측면에서부터 발생하는 특정 상호작용에 이르기까지)에서 선택한 아키텍처의 유효성을 검증할 수 있습니다.
이 타스크의 결과 평가에 대한 자세한 정보는 체크리스트: 소프트웨어 아키텍처 문서 - 아키텍처 분석 고려사항을 참조하십시오.
|
|