아키텍처 모델
소프트웨어 아키텍처는 아키텍처 스타일 및 품질 속성과 함께 분해 및 구성을 사용하여 소프트웨어 시스템 추상화의 높은 수준의 구조를 포함합니다. 소프트웨어 아키텍처 설계는 시스템의 주요 기능 및 성능 요구 사항을 준수 할뿐만 아니라 안정성, 확장 성, 이식성 및 가용성과 같은 비 기능적 요구 사항을 충족해야합니다.
소프트웨어 아키텍처는 구성 요소 그룹, 연결, 상호 작용 및 모든 구성 요소의 배포 구성을 설명해야합니다.
소프트웨어 아키텍처는 다양한 방법으로 정의 할 수 있습니다.
UML (Unified Modeling Language) − UML은 소프트웨어 모델링 및 설계에 사용되는 객체 지향 솔루션 중 하나입니다.
Architecture View Model (4+1 view model) − 아키텍처보기 모델은 소프트웨어 응용 프로그램의 기능 및 비 기능 요구 사항을 나타냅니다.
ADL (Architecture Description Language) − ADL은 소프트웨어 아키텍처를 공식적으로 그리고 의미 적으로 정의합니다.
UML
UML은 Unified Modeling Language의 약자입니다. 소프트웨어 청사진을 만드는 데 사용되는 그림 언어입니다. UML은 OMG (Object Management Group)에서 생성되었습니다. UML 1.0 사양 초안은 1997 년 1 월 OMG에 제안되었습니다. 이는 소프트웨어 개발의 기초가되는 소프트웨어 요구 사항 분석 및 설계 문서의 표준 역할을합니다.
UML은 소프트웨어 시스템을 시각화, 지정, 구성 및 문서화하는 범용 시각적 모델링 언어로 설명 될 수 있습니다. UML은 일반적으로 소프트웨어 시스템을 모델링하는 데 사용되지만이 경계 내에서 제한되지 않습니다. 또한 제조 단위의 프로세스 흐름과 같은 비 소프트웨어 시스템을 모델링하는 데 사용됩니다.
요소는 완전한 UML 그림을 만들기 위해 다양한 방식으로 연관 될 수있는 구성 요소와 같습니다. diagram. 따라서 실제 시스템에서 지식을 구현하려면 다양한 다이어그램을 이해하는 것이 매우 중요합니다. 우리는 두 가지 광범위한 다이어그램 범주를 가지고 있으며 하위 범주 즉,Structural Diagrams 과 Behavioral Diagrams.
구조 다이어그램
구조 다이어그램은 시스템의 정적 측면을 나타냅니다. 이러한 정적 측면은 주요 구조를 형성하고 따라서 안정적인 다이어그램 부분을 나타냅니다.
이러한 정적 부분은 클래스, 인터페이스, 개체, 구성 요소 및 노드로 표시됩니다. 구조 다이어그램은 다음과 같이 세분화 할 수 있습니다.
- 클래스 다이어그램
- 개체 다이어그램
- 구성 요소 다이어그램
- 배포 다이어그램
- 패키지 다이어그램
- 복합 구조
다음 표는 이러한 다이어그램에 대한 간략한 설명을 제공합니다.
| Sr. 아니. | 다이어그램 및 설명 |
|---|---|
| 1 | Class 시스템의 개체 방향을 나타냅니다. 클래스가 정적으로 관련되는 방식을 보여줍니다. |
| 2 | Object 런타임시 개체 집합 및 해당 관계를 나타내며 시스템의 정적보기를 나타냅니다. |
| 삼 | Component 시스템의 모든 구성 요소, 상호 관계, 상호 작용 및 인터페이스를 설명합니다. |
| 4 | Composite structure 모든 클래스, 컴포넌트의 인터페이스 등 컴포넌트의 내부 구조를 설명합니다. |
| 5 | Package 패키지 구조 및 구성을 설명합니다. 패키지의 클래스와 다른 패키지의 패키지를 다룹니다. |
| 6 | Deployment 배포 다이어그램은 노드와 그 관계의 집합입니다. 이러한 노드는 구성 요소가 배포되는 물리적 엔터티입니다. |
행동 다이어그램
행동 다이어그램은 기본적으로 시스템의 동적 측면을 포착합니다. 동적 측면은 기본적으로 시스템의 변경 / 이동 부분입니다. UML에는 다음과 같은 유형의 행동 다이어그램이 있습니다.
- 사용 사례 다이어그램
- 시퀀스 다이어그램
- 통신 다이어그램
- 상태 차트 다이어그램
- 활동 다이어그램
- 상호 작용 개요
- 시간 순서도
다음 표는 이러한 다이어그램에 대한 간략한 설명을 제공합니다.
| Sr. 아니. | 다이어그램 및 설명 |
|---|---|
| 1 | Use case 기능과 내부 / 외부 컨트롤러 간의 관계를 설명합니다. 이러한 컨트롤러를 액터라고합니다. |
| 2 | Activity 시스템의 제어 흐름을 설명합니다. 활동과 링크로 구성됩니다. 흐름은 순차, 동시 또는 분기 일 수 있습니다. |
| 삼 | State Machine/state chart 시스템의 이벤트 기반 상태 변경을 나타냅니다. 기본적으로 클래스, 인터페이스 등의 상태 변화를 설명합니다. 시스템의 내 / 외부 요인에 의한 반응을 시각화하는 데 사용됩니다. |
| 4 | Sequence 특정 기능을 수행하기 위해 시스템에서 호출 순서를 시각화합니다. |
| 5 | Interaction Overview 활동 및 시퀀스 다이어그램을 결합하여 시스템 및 비즈니스 프로세스의 제어 흐름 개요를 제공합니다. |
| 6 | Communication 객체의 역할에 초점을 맞춘다는 점을 제외하면 시퀀스 다이어그램과 동일합니다. 각 통신은 시퀀스 순서, 번호 및 과거 메시지와 연관됩니다. |
| 7 | Time Sequenced 상태, 조건 및 이벤트의 메시지 별 변경 사항을 설명합니다. |
아키텍처보기 모델
모델은 특정 관점 또는 관점에서 여러보기로 구성된 소프트웨어 아키텍처에 대한 완전하고 기본적이며 단순화 된 설명입니다.
뷰는 관련된 관심 사항의 관점에서 전체 시스템을 표현한 것입니다. 최종 사용자, 개발자, 프로젝트 관리자 및 테스터와 같은 다양한 이해 관계자의 관점에서 시스템을 설명하는 데 사용됩니다.
4 + 1보기 모델
4 + 1보기 모델은 Philippe Kruchten이 다중 및 동시보기 사용을 기반으로하는 소프트웨어 집약적 시스템의 아키텍처를 설명하기 위해 설계되었습니다. 이것은multiple view시스템의 다양한 기능과 문제를 해결하는 모델입니다. 소프트웨어 설계 문서를 표준화하고 모든 이해 관계자가 설계를 쉽게 이해할 수 있도록합니다.
소프트웨어 아키텍처 설계를 연구하고 문서화하기위한 아키텍처 검증 방법이며 모든 이해 관계자를위한 소프트웨어 아키텍처의 모든 측면을 다룹니다. 네 가지 필수 뷰를 제공합니다.
The logical view or conceptual view − 디자인의 객체 모델을 설명합니다.
The process view − 시스템의 활동을 설명하고 설계의 동시성 및 동기화 측면을 포착합니다.
The physical view − 소프트웨어를 하드웨어에 매핑하는 방법을 설명하고 분산 된 측면을 반영합니다.
The development view − 환경 개발에서 소프트웨어의 정적 조직 또는 구조를 설명합니다.
이 뷰 모델은라는 뷰를 하나 더 추가하여 확장 할 수 있습니다. scenario view 또는 use case view최종 사용자 또는 소프트웨어 시스템 고객 용. 다른 4 개의 뷰와 일관성이 있으며 "플러스 원"뷰, (4 + 1) 뷰 모델로 제공되는 아키텍처를 설명하는 데 사용됩니다. 다음 그림은 5 개의 동시보기 (4 + 1) 모델을 사용하는 소프트웨어 아키텍처를 설명합니다.
5 대신 4 + 1이라고하는 이유는 무엇입니까?
그만큼 use case view시스템의 높은 수준의 요구 사항을 자세히 설명하는 반면 다른 사용자는 이러한 요구 사항이 어떻게 실현되는지 자세히보기 때문에 특별한 의미가 있습니다. 다른 네 가지보기가 모두 완료되면 효과적으로 중복됩니다. 그러나 다른 모든 견해는 그것 없이는 불가능합니다. 다음 이미지와 표는 4 + 1보기를 자세히 보여줍니다.
| 논리적 | 방법 | 개발 | 물리적 인 | 대본 | |
|---|---|---|---|---|---|
| 기술 | 시스템의 구성 요소 (Object)와 상호 작용을 보여줍니다. | 시스템의 프로세스 / 워크 플로 규칙 및 해당 프로세스가 통신하는 방법을 보여 주며 시스템의 동적보기에 중점을 둡니다. | 시스템의 빌딩 블록보기를 제공하고 시스템 모듈의 정적 구성을 설명합니다. | 소프트웨어 응용 프로그램의 설치, 구성 및 배포를 보여줍니다. | 검증 및 일러스트레이션을 수행하여 설계가 완료되었음을 보여줍니다. |
| 뷰어 / 스테이크 보유자 | 최종 사용자, 분석가 및 설계자 | 통합 자 및 개발자 | 프로그래머 및 소프트웨어 프로젝트 관리자 | 시스템 엔지니어, 운영자, 시스템 관리자 및 시스템 설치자 | 그들의 견해와 평가자의 모든 견해 |
| 중히 여기다 | 기능 요구 사항 | 비 기능적 요구 사항 | 소프트웨어 모듈 구성 (소프트웨어 관리 재사용, 도구 제약) | 기본 하드웨어와 관련된 비 기능적 요구 사항 | 시스템 일관성 및 유효성 |
| UML – 다이어그램 | 클래스, 상태, 개체, 시퀀스, 통신 다이어그램 | 활동 다이어그램 | 구성 요소, 패키지 다이어그램 | 배포 다이어그램 | 사용 사례 다이어그램 |
아키텍처 설명 언어 (ADL)
ADL은 소프트웨어 아키텍처를 정의하기위한 구문과 의미를 제공하는 언어입니다. 시스템의 구현과 구별되는 소프트웨어 시스템의 개념적 아키텍처를 모델링하기위한 기능을 제공하는 표기법 사양입니다.
ADL은 아키텍처 설명의 빌딩 블록 인 아키텍처 구성 요소, 연결, 인터페이스 및 구성을 지원해야합니다. 아키텍처 설명에 사용되는 표현의 한 형태이며 구성 요소를 분해하고, 구성 요소를 결합하고, 구성 요소의 인터페이스를 정의하는 기능을 제공합니다.
아키텍처 설명 언어는 프로세서, 장치, 버스 및 메모리와 같은 하드웨어 구성 요소는 물론 프로세스, 스레드, 데이터 및 하위 프로그램과 같은 소프트웨어 기능을 설명하는 공식 사양 언어입니다.
ADL과 프로그래밍 언어 또는 모델링 언어를 분류하거나 구별하기가 어렵습니다. 그러나 ADL로 분류되는 언어에는 다음과 같은 요구 사항이 있습니다.
모든 관련 당사자에게 아키텍처를 전달하는 데 적합해야합니다.
아키텍처 생성, 개선 및 검증 작업에 적합해야합니다.
추가 구현을위한 기반을 제공해야하므로 최종 시스템 사양이 ADL에서 파생 될 수 있도록 ADL 사양에 정보를 추가 할 수 있어야합니다.
대부분의 일반적인 건축 스타일을 표현할 수 있어야합니다.
분석 기능을 지원하거나 빠른 생성 프로토 타입 구현을 제공해야합니다.