소개
아키텍처란 용어는 현재 빌드의 전통적 의미 밖에서도 널리 사용되고 "아키텍처"(시스템 컨텍스트에서) 및 "시스템 아키텍처"의 정의는 다음과 같이 다양합니다.
"시스템 아키텍처: 시스템 요소, 인터페이스, 프로세스, 제한조건 및 동작에 의해 정의된 기본 및 통합 시스템 구조."
[INCOSE Systems Architecture Working Group at INCOSE '96(Boston, MA)에 의해 승인된 기본 정의, 1996년 7월 8일]
"시스템 아키텍처는 시스템의 주요 실제 특성, 스타일, 구조, 상호작용 및 목적으로 구성됩니다."
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz
Pirbhai, Dorset House Publishing 2000]
"아키텍처: 시스템 파트 간 구조, 시맨틱 동작 및 관계를 정의하는 개념 및 규칙. 일정 부분의 구성 계획. 아키텍처는 사물을 구성하는 요소, 요소 간의 관계, 관계에 영향을 미치는 제한조건, 사물의 일부에
집중 및 사물을 전체로 보고 집중하는 요소를 포함합니다."
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001. 이 문서는 ISO/IEC 10746-2: Information
Technology - Open Distributed Processing - Reference Model: Foundations를 소스로 참조함]
"아키텍처: 프로그램/시스템에 있는 컴포넌트, 컴포넌트의 상호관계 및 시간에 따른 컴포넌트의 디자인과 전개를 제어하는 원리와 가이드라인의 구조.
[DoD 5000.59-P, "Modeling and Simulation Master Plan," 1995년 10월]
아키텍처는 "컴포넌트, 컴포넌트의 상호관계 및 시간에 따른 컴포넌트의 디자인과 전개를 제어하는 원리와 가이드라인의 구조입니다."
[IEEE STD 610.12, Integrated Architectures Panel (IAP) of the C4ISR Integration Task Force (ITF) in DoD
Architecture Framework, 버전 1.0에 의해 약간 확장됨]
다양한 단어 및 구현이 사용되고 일부 정의는 동일한 측면을 정확히 설명하지 못하지만 분명히 겹치는 부분이 있습니다. 이러한 정의는 시스템 아키텍처가 다음으로 구성됨을 나타냅니다.
-
요소, 컴포넌트 및 파트에 의한 시스템의 구조
-
이러한 요소 간의 관계
-
요소 및 요소의 관계에 영향을 미치는 제한조건
-
시스템이 표시하는 동작 및 해당 동작을 생성하는 요소 간에 발생하는 상호작용
-
시스템을 구성하고 시스템의 전개를 제어하는 원리, 규칙 및 근거
-
시스템의 실제 및 논리 특징 및 특성
-
시스템의 목적
따라서 이러한 모든 측면을 완전히 포함하려면 다양하고 복잡할 수 있는 정보 세트가 필요하지만 일부 이해 당사자(stakeholder)가 모든 측면을 동시에 확인하거나 이해할 필요는 없음을 명심해야 합니다.
시점의 아이디어를 사용하면 이러한 다양한 관심사항이 구분되고 이해 당사자의 클래스에는 효과적인 참여에 필요한 요소만 표시됩니다. 특정 시점의 관점에서 높은 추상 레벨에 해당하는 저해상도에서
구현을 위한 파트 등의 구체적 스펙에 해당하는 고해상도까지 다양한 "해상도"로 시스템을 볼 수도 있습니다.
시점
시스템의 시점은 "시스템 내에서 특정 관심사항에 초점을 맞추기 위해 선택한 아키텍처 개념 및 구조화 규칙 세트를 사용하여 작성한 추상 양식입니다"[ISO/IEC 10746-2: Information
Technology - Open Distributed Processing - Reference Model: Foundations]. 표에는 다양한 관심사항을 캡처하도록 선택된 시점의 일부가 나열됩니다. 이러한
시점은 ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview에 있는 시점에 맞춰집니다.
시점
|
관심사항
|
영향
|
작업자
|
조직 및 시스템 작업자의 역할 및 책임은 물론 이러한 요소에 영향을 미치는 정책과 관련됩니다.
|
작업 활동, 인간/시스템 상호작용. 인적 성능 스펙 및 인적 요소.
|
정보
|
시스템에서 처리하는 정보 유형 및 해당 정보의 사용 및 해석의 제한조건.
|
정보 무결성, 용량 제한사항.
정보 액세스 가능성, 무한.
|
논리
|
시스템 서비스를 제공하도록 협업하는 인터페이스에서 상호작용하는 서브시스템 세트로 시스템을 분해.
|
시스템은 원하는 동작을 표시합니다.
시스템은 확장 가능하고 적응 가능하고 유지보수 가능합니다.
자산은 재사용가능합니다.
|
분산/실제
|
시스템 기능 및 분산을 지원하는 데 필요한 하부 구조.
|
기능을 호스팅하고 비기능적 요구사항을 충족하는 시스템 실제 특성의 적합성.
|
프로세스
|
동시성, 확장성, 성능, 처리량, 신뢰성.
|
시스템 반응성, 처리량, 결함 허용치의 적합성.
|
공통 시스템 시점.
이러한 시점은 소프트웨어 중심 시스템에 가장 공통적 시점입니다. 많은 시스템 아키텍처에도 추가 도메인별 시점이 필요합니다. 예제에는 안전, 보안 및 기계적 시점이 포함됩니다. 시점은 시스템 아키텍처 및 디자인에서
검토되어야 하는 서로 다른 관심 영역을 나타냅니다. 전체 아키텍처에 중요한 관심사항이 속한 시스템 이해 당사자(stakeholder) 또는 전문가가 있는 경우에는 시점 중간 산출물 설정이 해당 디자인 결정을
캡처해야 할 필요가 있습니다.
다양한 시점을 감독할 능력이 있는 직원으로 시스템 아키텍처 팀을 구성해야 합니다. 팀은 작업자 시점을 기본적으로 책임지는 비즈니스 분석가와 사용자, 논리적 시점에 주의를 기울이는 소프트웨어 설계자, 실제 시점에
관심을 갖는 엔지니어 및 도메인별 시점의 전문가로 구성될 수 있습니다.
추상 레벨
시점과 함께 시스템 아키텍처에는 스펙 레벨이 필요합니다. 아키텍처를 개발할 때 아키텍처는 일반, 추상 스펙에서 보다 특정, 세부 스펙으로 전개됩니다. 아래 표와 같이 RUP는 네 개의 아키텍처 레벨을 식별합니다.
모델 레벨
|
표현
|
컨텍스트
|
시스템 및 액터
|
분석
|
개념적 접근 방식을 설정하는 시스템의 초기 파티션
|
디자인
|
하드웨어, 소프트웨어 및 사람에 대한 분석 모델의 실현(realization)
|
구현
|
특정 구성으로 디자인 모델 실현(realization)
|
RUP 아키텍처 레벨
이러한 레벨을 통해 디자인은 추상에서 실제로 진행됩니다. 컨텍스트 모델은 시스템과 상호작용하는 모든 외부 엔티티(액터)를 캡처합니다. 이러한 액터는 시스템을 배치하는 기업 외부에 있을 수도 있고 기업 내부에 있을
수도 있습니다. 두 경우 모두 액터는 사람인 작업자일 수도 있고 기타 시스템일 수도 있습니다. 분석 레벨에서 파티션은 하드웨어, 소프트웨어 및 사람의 선택사항을 반영하지 않습니다. 대신 시스템이 수행해야 하는 작업
및 노력을 분배하는 방법을 구분하는 디자인 접근 방식을 반영합니다. 디자인 레벨에서는 필요한 하드웨어 및 소프트웨어 컴포넌트 및 작업자의 정렬에 대한 결정이 이루어집니다. 구현 레벨에서는 디자인을 구현할 하드웨어
및 소프트웨어 기술의 특정 선택사항이 작성됩니다. 예를 들어 디자인 레벨에서 데이터 서버가 지정될 수 있습니다. 구현 레벨에서 특정 데이터베이스 응용프로그램을 실행하는 특정 플랫폼을 사용하도록 결정됩니다.
모델 및 다이어그램
모델은 일반적으로 특정 관심 영역을 나타내는 시스템의 표시입니다. 시스템의 개발 또는 사용에 대한 다양한 관심사항이 있기 때문에 시스템은 일반적으로 모델 세트로 표시됩니다. 각 모델은 보다
일반적이거나 숨겨지거나 캡슐화된 세부사항에서 보다 특정하고 보다 자세하고 명시적인 디자인 결정까지 다양한 추상 레벨로 구성될 수 있습니다.
시점은 이름이 의미하는 대로 시스템에 대한 일부 측면 또는 관심사항이 시각화되는 관념적인 위치이며, 개념적 필터를 형성하는 개념 및 규칙 세트의 적용을 의미합니다. 대개 실제 시스템 모델이 관심사항을
나타내고 설명하도록 수정되었는지 또는 구성되어야 하는지 점검하는 것으로는 이해하기에 충분하지 않습니다.
보기는 특정 시점에서 관련된 엔티티를 표시하는 모델의 투영입니다. 이러한 투영은 일반적으로 일종의 다이어그램으로 표시됩니다.
추상 또는 특수성의 시점 및 모델 레벨의 교차는 해당 추상 레벨에서 해당 시점 또는 관심사항에 관련된 하나 이상의 모델의 보기를 포함(또는 적어도 식별)합니다.
시스템 아키텍처는 다양한 시점 및 레벨의 아키텍처를 표현하는 모델 세트(및 시각화하는 다이어그램)로 캡처됩니다. 아래 모델 프레임워크 표와 같이 모든 시점-레벨 조합에는 모델/다이어그램이 없습니다. 구현 레벨에서
단일 모델이 각 시스템 구성에 대한 하드웨어 및 소프트웨어 컴포넌트의 실현(realization)을 캡처합니다.
모델 레벨
|
시점
|
작업자
|
논리
|
정보
|
분산/실제
|
프로세스
|
컨텍스트
|
UML 조직 보기
|
시스템 컨텍스트 다이어그램
|
엔터프라이즈 데이터 보기
|
엔터프라이즈 지역성 보기
|
비즈니스 프로세스 보기
|
분석
|
일반화 시스템 작업자 보기
|
서브시스템 보기
|
시스템 데이터 보기
|
시스템 지역성 보기
|
시스템 프로세스 보기
|
디자인
|
시스템 작업자 보기
|
서브시스템 클래스 보기
소프트웨어 컴포넌트 보기
|
시스템 데이터 스키마
|
설명자 노드 보기
|
자세한 프로세스 보기
|
구현
|
작업자 역할 스펙 및 지시사항
|
구성: 소프트웨어 및 하드웨어 시스템 컴포넌트가 있는 배치 다이어그램
|
표에 지정된 많은 보기는 표준 UML 모델에서 파생됩니다. 예를 들어 논리 시점의 분석 레벨에서 시스템은 사용자 요구사항을 충족하기 위해 협업하는 서브시스템으로 분해됩니다. 서브시스템은 UML 표준과 같은 시맨틱과
함께 사용됩니다. 이러한 서브시스템은 다시 서브시스템 또는 최종적으로 클래스로 분해됩니다. 논리 보기의 디자인 레벨은 세부사항 클래스 모델의 보기입니다. 프로세스 모델링은 시스템의 활성 클래스에 초점을 맞춘 표준
UML 클래스 모델입니다. 도메인별 시점에도 하나 이상의 레벨을 대신할 중간 산출물의 보기가 있어야 합니다. 이 프레임워크 내에서 프로젝트 중간 산출물 세트는 프로젝트의 개발 사례의 파트가 되어야 합니다.
|