Clean Architecture by Robert C. Martin

• 소프트웨어를 Concerns에 따라 layer로 분리할 때, 주로 Framework, Database, Device등 구체적이고 변하기 쉬운 레이어, UI나 외부와의 인터페이스 역할을 하는 레이어, 어플리케이션 종속적인 비지니스 룰을 가진 레이어, 그리고 어플리케이션 독립적인 비지니스 룰을 가진 레이어로 나누어지는 것을 발견할 수 있다. 
• 이 중 비지니스 룰과 같이 추상적이고 공통적인 것들(Policy)일수록 내부 동심원으로, 구체적인 레이어(Mechanism) 일수록 외부 동심원으로 표현하였을 때, 그 레이어간 종속성은 원의 외부에서 내부로, 즉, 구체적이고 변하기 쉬운 것으로부터 추상적이고 공통적인 것으로 향한다. 이것이 Clean Architecture의 'Dependency Rule' 이다. 
• 이렇게 하였을 때, Policy에 해당하는 비지니스 레이어가 Framework, 데이터베이스, UI, 외부시스템으로 부터 독립적일 수 있으며 또한 테스트하기가 용이한 구조가 된다.

https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

Public/Protected/Private Inheritance

Public Inheritance

• 부모의 속성을 그대로 물려 받는다. public --> public, protected --> protected

Protected Inheritance

• 부모의 속성이 protected가 된다. public --> protected, protected --> protected

Private Inheritance

• Java에는 없는, C++에는 있는 상속의 방법으로 부모의 public, protected 영역이 자식의 private이 되는 상속이다. 
• List <-- Stack, TV <-- RemoteCon 과 같이 부모의 기능을 이용하여 자식의 기능을 구현하는 관계(부모의 모든 속성을 다 물려 받을 필요가 없는)에서 사용된다. 
• http://2uropa.tistory.com/entry/public-%EC%83%81%EC%86%8D%EA%B3%BC-private-%EC%83%81%EC%86%8D%EC%97%90-%EB%8C%80%ED%95%B4

https://stackoverflow.com/questions/860339/difference-between-private-public-and-protected-inheritance

Architecture Tradeoff Analysis Method (ATAM)

원문
http://lore.ua.ac.be/Teaching/CapitaMaster/Assignment/ATAM-TR.pdf

카이스트 발표 자료
http://salab.kaist.ac.kr/materials/SEP523/15.%20P11-Arch%20Analysis-v4.pdf

NFR Tactics
http://etutorials.org/Programming/Software+architecture+in+practice,+second+edition/Part+Two+Creating+an+Architecture/Chapter+5.+Achieving+Qualities/5.1+Introducing+Tactics/

Glossary in Software Engineering

Software vs. Program


Software Architecture
시스템의 품질요구사항(Constrains)을 만족시키기 위한 Software 설계 사항을 Software의 구성요소(element)와 구성요소들간의 관계(relation)로 표현한 것.

ISO나 SEI, Clements, Rozanski 등 여러 학자들이 각자의 문장으로 그 정의를 표현하였는데
공통적으로 Software의 Elements, Relations, Property 혹은 Constraints로 표현된 것이라고 말하고 있다.

Software Model

소프트웨어가 포함하고 있는 개념들을 추상화하여 표현한 것. 

Software Architecture Style

ATAM (Architecture Tradeoff Analysis Method)

품질속성 시나리오에 기반하여 아키텍처 Tradeoff를 분석하고 이에 대한 위험요소(Risk)를 찾아내는 아키텍처 평가 방법

1. Business Goal에서 품질 요구사항을 시나리오 형태로 추출 

    - 구체적인 상황과 숫자로 기술되어야 한다.

    - Stimulus (선적용 조건), Stimulus를 발생하는 원인, Stimulus의 결과로 표현

2. 품질 속성의 우선 순위를 결정하고 이를 기반으로 평가할 품질 속성을 결정한다.

    - Importance (Stakeholder입장), Difficulty(개발팀입장)

      Importance를 더 우선시

3. 품질 요구사항을 만족시킬 Architectural approach, tactics, style 등을 결정한다.

4. 4번의 결정 사항을 품질 속성별로 평가 (+/-)

5. 선정된 결정 사항별로 Risk 및 Tradeoff 분석

    - Risk : 아키텍처 결정 사항으로 인한 잠재적 문제 요인 (tradeoff로 드러나지 않은)

    - Tradeoff : 하나의 품질 속성은 만족시키면서 동시에 다른 품질 속성은 떨어 뜨리는 특성.

Refactoring
소프트웨어의 maintainability를 높이기 위해 external behavior의 변경없이 코드의 구조를 변경하는 일. 주로 기본적인 micro refactoring을 연속으로 수행함으로써 큰 규모의 구조까지 변경한다.

Golden Master Testing

• 기존 코드의 실제 동작을 characterize하여 저장(Golden Master)하였다가 코드가 수정되었을 때 이전의 결과와 비교함으로써 코드 변경으로 인한 예기치 않은 오류를 확인할 수 있도록 하는 테스트 방법이다.
• Unit test가 없는 legacy code를 기반으로 기능 확장을 하거나 refactoring할 때 유용하게 사용된다.

SOLID Principle

• Single Responsibility Principle (SRP)
• a class should have only a single responsibility
• Open/Close Principle (OCP)
• open for extension, but closed for modification
• Liskov Substitution Principle (LSP)
• replaceable with instances of their subtypes
• Interface Segregation Principle (ISP)
• many client-specific interfaces are better than one general-purpose interface
• Dependency Inversion Principle (DIP)
• depend upon abstractions

References

https://www.sei.cmu.edu/architecture/start/glossary/index.cfm

Design Pattern의 혼합

1. Builder + Composite

Composite pattern의 Composite을 구성하는 것이 반복적이고 복잡하고 실수하기 쉽기 때문에 Composite 의 구성(Composite pattern의 Client) 코드를 Builder pattern을 적용하여 분리한다.

2. Decorator/Composite + Prototype

3. Visitor + Composite + Iterator

4. Abstract Factory + Singleton

5. Facade + Singleton

6. Observer + Mediator

Kruchten의 4+1 View Model

복잡한 시스템의 구조를 하나의 모델로 이해하기 불가능하기 때문에 여러 관점에서 구조를 표현하고 이해할 필요가 있다.

Viewpoint는 시스템을 바라보는 관점이고 그 관점에서 시스템을 구성하는 요소와 그 요소들 간의 관계를 표현한 것이 View이다.

Kruchten은 아래와 같은 4+1 View로 시스템 구조를 표현하고 이해할 수 있다고 했다.

• Logical View
• 시스템이 사용자에게 제공하는 기능을 구조적 구성요소와 역할로 분해하고 그 간의 관계를 명시하는 것에 촛점을 맞춘 View이다. 
• Abstraction의 level에 따라 다르게 표현될 수 있고 반복적인 구조 설계의 과정을 거치면서 상세화된다.
• 주로 Class diagram이나 state diagram으로 표현된다.
• Process View
• 시스템을 구성하는 프로세스들이나 그것들 간의 통신 등 run-time의 동작을 표현하는 데 촛점을 맞춘 View이다.
• Concurrency, fault-tolerant, throughput 등 non-functional 요구사항에 대한 설계 해결책을 표현한다. 
• 주로 Activity diagram, class diagram(process나 thread 같은 stereo type으로 표시되는 클래스), collaboration diagram 등으로 표현된다.
• Physical View (Deployment View)
• 시스템을 구성하는 물리적인 구성요소 (주로 hardware)와 거기에 배치되는 software 산출물, 그리고 그 구성요소간의 관계를 표현하는 데 촛점을 맞춘 View이다.
• 주로 시스템을 설치하는 Software engineer의 관점이며 availability, reliability, performance 등의 non-functional requirement들이 정량적으로 고려된다.
• 주로 Deployment diagram으로 표현된다. 
• Development View (Implementation View)
• 개발팀에 의해서 개발되는 물리적인 산출물의 관점에서 구조를 표현한다.
• 개발자나 개발 관리자의 관점에서 maintainability, reusability, 개발을 위한 subsystem으로의 partitioning 등에 대한 고려사항이 표현된다.
• 주로 Component diagram이나 Package diagram으로 표현된다.

+ 

• Scenarios
• 중요한 요구사항들을 scenario의 형태로 표현하여 4개의 모든 View를 연결시키는 역할을 하는 View이다. 
• 주로 Use case diagram으로 표현된다. 

Association Class

클래스간의 관계에 속성을 부여할 때 사용하는 클래스. 다대다 관계에서 association instance가 존재할 경우에만 association class의 instance가 생성되며 각 association instance에 대해 unique하게 association class의 instance가 존재함.