[ISAQB] Chapter 3. Designing Software Architectures

목차

🟡 3.1 Overview of SW architecture design process (continued as Ch.2)

 

✅ 3.1.1 "4 levels" of abstraction

 

 

• [1] Input for the architecture design: Central concept / Assign 3 major system categories(information, mobile, embeded)
• [2] Define F-req and nF-req or architecture standard to be followed
• [3] Design of the specific functional and technical components and their interaction
• [4] Implementation - final goal: devleloped software system

 

 

 

✅ 3.1.2 "4 activities" in design process

 

 

• [A] Input is normally analyzed from the next higer abstraction level: define decision criteria
• [D] Decision making: select the best solution based on decision criteria established during the initial analysis
• [E] Evaluate architecture and design decision
• [E] Support and review

 

 

 

✅ 3.1.3 Overview

 

Top-down / Bottom-up 모두 가능

 

 

 

"All activity has interaction and make decision based on criteria"

 

 

 

 

 

 

🟡 3.2 Design principles

 

"4 types of Design principles"

 

 

1) Top-down and bottom-up

 

 

 

- Start with problem

 

 

- Start with the specific machine and builds additional "abstract machines"

 

 

 

 

2) Hierarchical (de)composition

• Divide and conquer: 관리 가능한 level까지 쪼개기. "가장 하위 레벨의 solution이 가장 상위 레벨의 solution도 될 수 있어야 함."
• Decomposition principles: reducing complexity / encapsulation / independent / low coupling and high cohesion / seperate responsibilities clearly and understandably
• The "as-simple-as-possible" principle: suitability / low complexity / easy to understand / easy to change
• Seperation of concerns: based on 'Divide and concuer' / increase quality / traceability of changes and impacts / modularity / information hiding

 

 

 

3) Lean interfaces and information hiding

• Information hiding: encapsulate in building blocks -> increase flexibility about making changes (black box: access to internal structure via interfaces)
• Use of interfaces: relationship between building blocks -> "building blocks and subsystems communicate and cooperate with each other via interfaces"

 

 

 

4) Regular refactoring and redesign

 

"SW is continuosly enhanced"

주기적으로 리팩토링 하는 작업을 통해 적합한 의존성을 유지시킬 수 있고, 단순화 할 수 있다.

 

• Refactoring (noun): “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
• Refactoring (verb): “To restructure software by applying a series of refactorings without changing its observable behavior.

 

 

 

 

 

 

🟡 3.3 Architecture development approach

 

"3 types of Architecture development approaches"

 

1) Domain-driven design(DDD): Collection of principles and patterns that assist developer

     - Design by structuring the functional domain (비즈니스 도메인 별로 나누어 설계)

     - Improve communication between domain experts and developers

     - Ubiquitos language (universal language) : enable precise formulation of requirements

     - Bounded context: easy to determine the appropriate granularity for microservices

 

 

       [Systematic Management]

 

 

• Entities: core objects of a functional domain - have identity + can be modified
• Value objects: describe state of other object - NO identity + cannot be modified
• Servicies: operations that represent the process sequence of domain - NO own status
• Aggregates: encapsulate interlinked domain object
• Factories: NO access to other layers
• Repositories: obtain object references for other objects

 

       [Structuring of the functional domain]

 

 

 

       [Types of domains]

 

 

       [Integration of domains]

 

 

 

 

 

2) Model-driven architecture(MDA)

 

advantages

 

- 독립적인 소프트웨어 자동화 기술

- 코드를 자동으로 찍어낼 수 있게 하기 위한 기술: 모델을 종속적으로 설계하지 않고 플랫폼에 맞춰서 모델에 따른 코드를 생산

- 컴포넌트 플랫폼에 독립적인 기본 설계 모델(PIM)을 정의하고, 이를 기반으로 원하는 플랫폼에 맞는 SW를 생성하는 컴포넌트 기술의 표준 구조

 

"MDD(Model Driven Development)": 소프트웨어를 쉽고 빠르게 개발할 수 있도록 플랫폼에 종속적인 sw 모델로 자동 변환하고 소스코드를 생성하는 개발 방법

  

 

 

3) Reference architectures

 

The goal is "Reuse of system building blocks"

 

 

• AOP(Aspect Oriented Programming): 흩어진 aspect를 모듈화 할 수 있는 프로그래밍 기법 - 기능 단위로 모듈화

 

출처: [Spring] AOP(Aspect Oriented Programming)란 무엇일까? :: Gyun's 개발일지

 

만약 Class A의 주황색 부분을 수정해야 한다면 B,C Class에 해당하는 곳을 전부 찾아 수정해야 하는데, Aspect(기능)를 이용하여 모듈화 시킬 경우 "재사용"이 가능해진다!!!

 

Cross-cutting Concerns: 공통 기능 로직(반복되는 코드) / 부가 기능
e.g. CAN error handling

 

 

 

즉, Cross-cutting의 분리를 허용함으로써 모듈성을 증가시키는 데에 목적이 있음.

핵심 기능을 도와주는 부가 기능(Cross-cutting)을 쉽게 분리된 모듈로 작성할 수 있게 함으로써, 핵심 기능을 설계하고 구현할 때 객체지향적인 가치를 지킬 수 있게 도와주는 개념.

 

*** Cross-cutting concept ***
 ex) Logging, Performance profiling, Validation, Session, Synchronization, Security, Error handling, Event-driven programming, Software test
1) increase to consistency
2) define constraints for the implementation of many building blocks
3) implemented by a single building block
4) exception handling

*** Don't Repeat Yourself(DRY) ***
모든 내용은 single, unambiguous, authoritative representation의 특징을 가져야 한다!
1) easy to maintain and read
2) loose complexity
3) higher coupling: 지나치게 DRY만 고집할 경우 결합도가 높아진다
4) components that contain redundant code can be improved independently of each other

 

OOP의 한계를 해결하고자 등장!

 

 

• OOP(Object Oriented Programming): 공통된 목적을 띈 데이터와 동작을 묶어 하나의 객체로 정의 - 클래스 단위로 모듈화

 

 

---> 기능 재사용 가능

 

 

 

• Procedural Programming: 복잡한 알고리즘을 재사용 할 수 있는 sub-algorithm들로 쪼갤 수 있도록 함

 개체를 순차적으로 처리 & SoC(Seperation of Concern) 원칙을 바탕으로 구현됨.

    * SoC: 프로그램을 여러 개의 블록으로 나누어 개발 / 복잡한 함수 사용 금지 *

 

 

 

 

 

 

🟡 3.4 Techniques for a good design

 

"8 types of Techniques for a good design" (include 객체지향 설계 원칙 SOLID)

 

1) Avoid degenerated design: Software has to be modified, extended and maintained

 

 

• Fragility: unforeseen errors
• Rigidity: modification is difficult
• Low reusability: cannot be reused due to their many dependencies are risky

 

 

 

2) Loose coupling(Single responsibility principle): reduce complexity of structures and ease of modification

                                                                         e.g. Call, Generation, Data, Execution location, Time, Inheritance

• Tight coupling
  • building block directly call dependent buliding block without interface
  • building block use shared complex data structures
  • building block use shared table

 

3) High cohesion(Single responsibility principle): to be related

 

2) + 3) = 결합도는 낮게, 응집도는 높게: 변경 용이를 위해 연관성이 있는 것들끼리 같은 그룹에 모아둠으로써 직관적으로 알아볼 수 있도록 함! 단 그룹들끼리의 의존도는 낮아야 함

 

 

 

4) Open/Closed principle: Open for extension & Close for modification

기존 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 함. "캡슐화"

 

 

 

5) Dependency inversion: dependencies of abstractions, easy to replace building blocks(확장 용이)

객체 간의 관계를 최대한 느슨하게 해주는 효과가 있음: 다양한 설계 방식 or 복잡한 시스템 설계가 가능

 

"Building blocks shall only depend on each other via abstraction"

추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙. "상위 모듈은 하위 모듈에 의존해서는 안된다"

즉, 의존 관계를 맺을 때 변화하기 쉬운 것에 의존하기 보다는 변화하지 않는 것에 의존하라는 원칙!!!

대체로 추상화 한 interface를 활용하면 이 원칙은 준수된다.  ---> loose coupling

 

 

 

6) Seperation of interfaces(Interface Segregation): seperate the interface into several more specific interfaces

-> easy to implement and maintain

자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙!

'단일 책임 원칙'이 객체가 갖는 하나의 책임이라면, 인터페이스 분리 원칙은 '인터페이스'가 갖는 하나의 책임이다.

 

 

 

7) Resolving cyclic dependencies

 

 

 

왼쪽 그림과 같이, A class -> B class / B class -> C class / C class -> A class로 접근할 수 있는 구조를 "Cyclic dependency"라고 한다. 이는 메모리 누수를 발생시킬 수 있고 어떤 결과가 발생할 지 예측하기 힘들기 때문에 지양해야 하는 구조이다.

따라서 오른쪽 그림처럼 A class가 CA interface를 구현하게 만든 후, C class에 CA interface로 A를 전달하면 의도하지 않은 상황을 방지함으로써 인터페이스에 구현된 기능만 사용할 수 있게 된다.

 

 

 

8) Liskov's substitution principle: basic class(parent) should be replaced by its derived class(sub)

  

 

   - 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙

   - 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 '확장'만 수행

 

 

 

 

 

 

🟡 3.5 Architectural patterns

 

"4 types of Architectural patterns" 

 

 

1) Adaptable systems: extension of applications, adaptation to evolving technologies and changing F-req

 

🔸 Dependency injection

: 외부에서 두 객체 간의 관계를 결정해주는 디자인 패턴 / 인터페이스를 사이에 둠으로써 클래스 레벨에서는 의존 관계가 고정되지 않도록 하고, 런타임 시에 관계를 동적으로 주입하여 유연성을 확보 & 결합도를 낮춘다.

 

ex) The Spring Framework

 

 

 

 

2) Interactive systems

 

🔸 MVC(Model-View-Controller) pattern

 

 

• Model: encapsulate business logic and data (서브 시스템의 핵심 기능과 데이터 보관)
• View: provide views of the model (사용자에게 정보 표시)
• Controller: process user event, execute business logic, trigger update of view component (사용자 입력 처리)

출처: MVC 패턴이란? (Model-View-Controller) — 개발자 호소인

 

사용자의 Action들은 Controller에 들어오게 됩니다.
Controller는 사용자의 Action를 확인하고, Model을 업데이트합니다.
Controller는 Model을 나타내줄 View를 선택합니다.
View는 Model을 이용하여 화면을 나타냅니다.
 
출처: https://beomy.tistory.com/43 [beomy:티스토리]

 

 

🔸 MVP(Model-View-Presenter) pattern

 

 

* MVC 패턴과 달리 View와 Model의 의존성이 없음!!! *

 

출처: [디자인패턴] MVC, MVP, MVVM 비교

사용자의 Action들은 View를 통해 들어오게 됩니다.
View는 데이터를 Presenter에 요청합니다.
Presenter는 Model에게 데이터를 요청합니다.
Model은 Presenter에서 요청받은 데이터를 응답합니다.
Presenter는 View에게 데이터를 응답합니다.
View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.
 
출처: https://beomy.tistory.com/43 [beomy:티스토리]

 

 

 

🔸 PAC(Presentation-Abstraction-Control) pattern

• Presentation: 시각적인 동작을 위한 컴포넌트
• Abstraction: 데이터를 핸들링하는 컴포넌트
• Control: Presentation과 Abstraction을 연결하고 다른 Agent들과 통신하기 위한 컴포넌트

 

 

 

 

3) From chaos to structure

 

🔸 Layers pattern (= Layered architecture)

: only interact with counterpart layer

 

 

--> reduce dependencies between components / provide increased reusability / can be exchanged specific layer / flexibility in modifying or changing the system

 

 

🔸 Pipes and filters

: sequence of processing units / 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송

--> good reusability easy to extend / Decoupling multiple steps of an execution

각 process(=filter)의 결합도를 없애므로써 재사용성 및 확장성 증가

 

ex) IT systems which process data streams

 

 

🔸 Blackboard

: 모든 컴포넌트가 블랙보드에 접근

 

 

• 블랙보드 (blackboard) — 솔루션의 객체를 포함하는 구조화된 전역 메모리
• 지식 소스 (knowledge source) — 자체 표현을 가진 특수 모듈
• 제어 컴포넌트 (control component) — 모듈 선택, 설정 및 실행을 담당

e.g. digital signal processing - image acquisition, color correction, compression...

 

 

 

4) Distributed systems

 

🔸 Broker

: 'broker' component is central point of communication

User requests wanted services to broker, then broker forward to the correct client

 

 

 

🔸 Service orientation

: 서비스 인터페이스를 통해 소프트웨어 구성 요소의 재사용과 상호 운용성을 가능하게 하는 방법을 정의

애플리케이션의 기능을 비즈니스적인 의미를 갖는 기능 단위로 묶어서 Rest API를 통해 서비스로 구현하는 소프트웨어 개발 아키텍처

"주로 대용량 분산 시스템 구현에 활용"

 

 

• Service Customer(Requester): 웹 서비스를 이용하는 소비자로, Service Provider에게 특정 서비스를 요청
• Service Provider: 서비스를 생성 및 운영하는 공급자로, Service Customer에게 서비스를 제공
• Service Registry: 서비스를 등록 및 검색하는 중개자로, 서비스에 대한 정보 및 통신 방법을 저장하는 일종의 DB 검색 엔진

 

 

🔸 Modularization

: reduce the complexity / subdivide the overall system into components

'Layerd pattern'과 달리 각 시스템 영역의 책임이 분리될 수 있음.

 

출처: When (‌modular) monolith is the better way to build software ❘ Thoughtworks

 

 

 

🔸 Micro-services

: creation and integration of distributed systems / 작은 서비스 여러 개가 모여서 하나의 시스템 제공 / 각자 별도의 프로세스에서 실행 

 

출처: Monolith vs. Microservices: Key Difference ❘ Webbylab

 

Monolithic System 단점

• 스케일 아웃 시 전체 시스템을 확장해야 하는 비효율
• 빌드/배포 시간이 오래 걸림
• 작은 수정에도 전체 시스템을 빌드/배포 해야 함
• 하나의 버그에도 전체 시스템이 실패할 수 있음
• 기능 간 결합도가 높아 영향도 파악이 어렵다
• 결과적으로 코드가 운영환경에 민첩하게 배포되기 어렵다

 

 

 

 

 

 

🟡 3.6 Design patterns

 

"8 types of Design patterns" 

 

 

1) Adapter(Structural pattern): change class interface to others for being used outside

클래스의 인터페이스를 다른 인터페이스로 변환하여 다른 클래스가 이용할 수 있도록 함.

 

 

 

 

2) Observer(Behavioral pattern): react to state change in the subject knowing the observer

객체 상태가 변할 때, 관련 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 함.

"Observer는 subject와 연관 관계가 없기 때문에 언제든지 삭제될 수도 있고 생겨날 수도 있음!"

 

 

 

 

3) Decorator(Structural pattern): dynamically and transparently adds new functionality to a component, without expanding the component itself

주어진 상황 및 용도에 따라 어떤 객체에 + 다른 객체를 덧붙이는 형식

 

 

 

 

4) Proxy(Structural pattern): provide same interface as the real subject to the outside world

접근이 어려운 객체로의 접근을 제어하기 위해 객체의 placeholder를 제공

 

 

 

 

5) Facade(Structural pattern): make invisible to the outside world, provide integrated interface

서브 시스템에 있는 인터페이스 집합에 대해 하나의 통합된 인터페이스(wrapper) 제공

 

 

 

 

6) Bridge(Structural pattern): abstract class and implementation are managed in 2 different hierachies

구현부에서 추상층을 분리하여 각자 독립적으로 확장할 수 있게 함

 

 

 

 

7) State(Behavioral pattern): serve to encapsulate different, state-dependent behaviors of an object

객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용

 

 

 

 

8) Mediator(Behavioral pattern): arbitrator and controls the cooperative behavior of objects / communication control between the components

한 집합에 속해있는 객체들의 상호작용을 캡슐화하여 새로운 객체로 정의

 

 

 

 

 

 

 

 

<Memo>

Best suitable techniques to illustrate the workflow or behavior of the system at runtime
1. Flowcharts
2. Activity Diagrams
3. Sequential diagram
4. Numbered list of sequential steps

 

 

 

 

 

 

 

 

 

Reference

Mahbouba Gharbi & Arne Koschel & Andreas Rausch - Software Architecture FundamentalsA Study Guide for the Certified Professional for Software Architecture

 

위 책 내용을 챕터별 중요한 포인트 위주로 정리한 자료입니다.

스스로 공부하기 위한 요점정리 노트이므로 상업적인 사용 목적은 전혀 없음을 알려드립니다:)

 

이 시험에 대한 정보 및 각종 자료는 아래 사이트에서 확인하실 수 있습니다. ⬇⬇⬇

https://www.isaqb.org/downloads/

https://isqi.org/en/