Architectural Design (아키텍처 설계) 결정과 4+1 View

Architectural Design (아키텍처 설계)

정의 (Definition)

• Architectural Design은 소프트웨어 시스템을 어떻게 구성할지 이해하고, 시스템의 전체 구조를 설계하는 것을 목적으로 한다.
  • 요구사항 공학(Requirements Engineering)과 설계(Design) 사이의 중요한 연결 고리.
  • 시스템의 주요 구조적 구성 요소와 이들 간의 관계를 식별.
  • 아키텍처 모델(Architecture Model)은 시스템을 상호작용하는 컴포넌트 집합으로 조직화하는 방법을 설명.

---

The Architecture of Packing Robot Control System

아키텍처 overview Diagram(Top-down 정의)

색칠된 박스는 시스템의 범위(Boundery)이다.

---

Architectural Abstraction (아키텍처 추상화)

1. Architecture in the Large (일반적인 : 서버, 게이트웨이)
   • 복잡한 기업 시스템(Enterprise System)의 아키텍처를 다룸.
   • 다른 시스템, 프로그램, 프로그램 구성 요소를 포함하는 대규모 시스템.
   • 여러 컴퓨터에 분산되며, 각 컴퓨터는 서로 다른 회사가 소유 및 관리 가능.
2. Architecture in the Small (프로그램 하나 예시: 컴포넌트 5~10개 + 레이어드 아키텍처 -> 1개의 jar파일)
   • 개별 프로그램의 아키텍처를 다룸.
   • 프로그램을 컴포넌트로 나누는 방법에 중점

---

Advantages of Architectural Design (아키텍처 설계의 장점)

1. Stakeholder Communication (이해관계자 간 의사소통)
   • 아키텍처는 시스템 이해관계자 간 논의의 초점으로 사용될 수 있음.
2. System Analysis (시스템 분석)
   • 시스템이 비기능적 요구사항(Non-Functional Requirements)을 충족할 수 있는지 분석 가능.
3. Large-Scale Reuse (대규모 재사용)
   • 아키텍처는 다양한 시스템에서 재사용 가능.
   • 제품군 아키텍처(Product-Line Architectures)를 개발할 수 있음.

---

아키텍처를 처음부터 해야하는 상황

Quality Requirements가 가로막는 경우 (NFR 영향)

아키텍처의 큰 영향을 주기 때문

ex) 4Tier Design : 일정 반응 속도 NFR을 절대 만족 할 수 없다.

 

---

Architectural Models (아키텍처 모델)

표현 방식 (Representation)

1. 단순한 비공식 블록 다이어그램(Simple, Informal Block Diagrams)
2. Box and Line Diagrams
3. UML 모델의 확장(Extensions of UML Models)

사용 목적 (Usage)

1. 디자인 논의 촉진:
   • 상세한 정보 없이 시스템의 고수준 관점을 제공하여 이해관계자와 프로젝트 계획 논의에 유용.
2. 설계된 아키텍처 문서화:
   • 시스템의 컴포넌트, 인터페이스, 연결 관계를 보여주는 완전한 시스템 모델 생성

---

Architectural Representations (아키텍처 표현)

1. Simple Block Diagrams (단순 블록 다이어그램)
   • 엔티티와 관계를 간단히 표현.
   • 가장 널리 사용되지만, 관계 유형이나 가시적 속성을 표현하지 못함.
2. Box and Line Diagrams
   • 매우 추상적이며, 컴포넌트 관계나 외부 가시적 속성을 표시하지 않음.
   • 하지만 이해관계자와의 의사소통 및 프로젝트 계획에 유용.
3. Extensions of UML Models (UML 모델 확장)
   • 클래스 다이어그램(Class Diagrams), 객체 다이어그램(Object Diagrams), 복합 구조 다이어그램(Composite Structure Diagrams)을 포함.
   • 아직 널리 사용되지 않음.

---

Architectural Design Decisions (아키텍처 설계 결정)

아키텍터가 함

설계 결정의 특징

• 아키텍처 설계는 창의적 과정(Creative Process).
• 설계 과정은 개발 중인 시스템 유형에 따라 다르지만, 공통적으로 다음 결정을 포함:
  • 시스템의 비기능적 특성(Non-Functional Characteristics)에 영향을 미침.

RUP Elaboration Phase에서 각 Iteration이 프로토타입 개발을 하고 있다. (Iterative, Evolutionary, Incremental)

이렇게도 만들어보고 저렇게도 만들어보는거지, 10%->45%등으로 올라가는 개념이 아니다.

그래서 Iterative하면서 evolutionary(요구사항이 바뀐다)하지만 Incremental 하지 않다.

---

Architecture and System Characteristics (아키텍처와 시스템 특성)

1. Performance (성능)
   • 중요한 작업을 로컬화하고 통신 최소화.
   • 세분화된 컴포넌트보다 큰 컴포넌트를 사용.
2. Security (보안)
   • 중요한 자산을 내부 계층에 배치한 레이어드 아키텍처 사용.
3. Safety (안전성)
   • 안전이 중요한 기능을 소수의 서브시스템에 로컬화.
4. Availability (가용성)
   • 중복 컴포넌트 및 결함 허용 메커니즘 포함.
5. Maintainability (유지보수성)
   • 세분화되고 교체 가능한 컴포넌트 사용.

---

Architecture Reuse (아키텍처 재사용)

1. 도메인 기반 아키텍처:
   • 동일 도메인 시스템은 유사한 아키텍처를 가지며, 도메인 개념을 반영.
   • 특정 고객 요구사항을 충족하는 변형이 포함된 제품군 아키텍처(Application Product Line) 구축.
2. 아키텍처 패턴(Architecture Patterns) 및 아키텍처 스타일(Architecture Styles):
   • 아키텍처의 본질을 캡처하여 다양한 방식으로 인스턴스화 가능.

---

Architectural Views (아키텍처 뷰)

뷰의 역할 (Role of Views)

• 각 아키텍처 모델은 다음 중 하나의 관점만 보여줌:
  1. 시스템이 모듈로 분해되는 방식.
  2. 실행 시 프로세스 간 상호작용.
  3. 시스템 컴포넌트가 네트워크에 분산되는 방식.

4 + 1 View Model

1. Logical View: 시스템의 주요 추상화를 객체 또는 클래스 형태로 표현.
2. Process View: 실행 시 상호작용하는 프로세스 간 관계 표현.
3. Development View: 개발을 위한 소프트웨어 분해 구조 표현.
4. Physical View: 하드웨어와 소프트웨어 컴포넌트의 분배 표현.
5. Use Case or Scenario (+1): 다른 뷰를 연결하는 사례.

 

---

Representing Architectural Views (아키텍처 뷰의 표현)

• Unified Modeling Language (UML)은 시스템 아키텍처를 기술하고 문서화하기 위한 후보 표기법으로 사용될 수 있다.
  • 컴포넌트 다이어그램(Component Diagram), 패키지 다이어그램(Package Diagram), 클래스 다이어그램(Class Diagram) 등이 포함된다.
  • 하지만 UML은 고수준 시스템 설명에 적합한 추상화를 포함하지 않는다.
• Architectural Description Languages (ADLs):
  • 아키텍처를 기술하기 위한 전용 언어로 개발되었지만, 아직 널리 사용되지는 않고 있다.
• Naive Diagrams (단순 다이어그램):
  • C&C View(구성 및 연결 뷰)와 같은 간단한 다이어그램이 자주 사용된다.

---

Describing Software Architectures (소프트웨어 아키텍처 설명) -> AD

아키텍처 결과 = AD (large system)

small system같은 경우는 AD가 필수적이지 않고, SDS에 기재하는 경우도 있다.

• ISO/IEC/IEEE 42010:2011:
  • "Systems and Software Engineering - Architecture Description" 표준은 아키텍처 설명(AD)에 대한 요구사항을 명시한다.

• 아키텍처 설명 표준의 주요 원칙 (Key Principles of the Architecture Description Standard):
  1. 이해관계자의 요구 충족:
     • 아키텍처 설명은 시스템의 다양한 이해관계자의 요구를 충족시키는 방법을 입증해야 한다.
  2. 여러 뷰 구성:
     • 다양한 이해관계자의 아키텍처 관련 관심사(Architectural Concerns)를 다루기 위해, 각 뷰가 특정 관심사의 하위 집합을 포괄하는 다중 아키텍처 뷰를 사용하여 AD를 구성해야 한다.
  3. 명시적 규칙 제공:
     • 각 아키텍처 뷰의 형식적 타당성(Well-Formedness), 완전성(Completeness), 분석 가능성(Analyzability)을 보장하기 위한 규칙이 명시적으로 제공되어야 한다.

---

용어

1. Architecture (아키텍처)

• 시스템의 구성 요소와 그들 간의 관계를 정의하고 조직하는 방법이다.
• 소프트웨어 아키텍처는 시스템의 구조적 설계로, 시스템이 어떻게 작동할지를 결정짓는 중요한 기준을 제공한다.

2. Architecture Description (AD) (아키텍처 설명)

• 아키텍처를 표현하기 위한 작업 산출물(work product)이다.

3. Architecture Framework (아키텍처 프레임워크)

• 시스템에 대한 관심을 가진 개별, 팀, 조직 또는 그 클래스들에 대한 틀을 정의한다

4. Stakeholder (이해관계자)

• 시스템에 관심이 있는 사람이나 그룹으로, 시스템 개발 및 운영에 영향을 미치는 다양한 주체를 포함한다.
• 예시: 사용자, 관리자, 시스템 개발자 등.

5. Architecture View (아키텍처 뷰)

• 시스템의 성능, 보안, 확장성 등 특정 관점에서의 아키텍처를 표현하는 뷰.

6. Architecture Viewpoint (아키텍처 뷰포인트)

• 아키텍처 뷰를 구성하고 해석하며 사용하는 방법에 대한 규칙을 설정하는 작업 산출물을 의미합니다.

7. Concern (우려사항)

• 시스템의 환경에서 시스템에 영향을 미치는 요소들로, 특정한 이해관계자나 시스템의 관심사에 해당한다.
• 예시: 개발적, 기술적, 비즈니스, 운영적, 조직적, 정치적, 경제적, 법적, 규제적, 생태적, 사회적 영향 등이 우려사항에 포함될 수 있다.

8. Model Kind (모델 종류)

• 특정한 유형의 모델링을 위한 규약과 방식을 정의하는 종류로, 일반적으로 사용되는 모델 종류로는 데이터 흐름 다이어그램 (Data Flow Diagrams, DFD), 클래스 다이어그램(Class Diagram), 펫리 네트(Petri Nets), 상태 전이 모델(State Transition Models) 등이 있다.