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가 존재함.

Architecture Style 비교

Style	Situation	Component	Pros	Cons	Example
Main-Subroutine		Main Subroutines in multiple layers	Reusability
Layered	관련있는 역할을 가진 클래스들을 모아 계층적인 component 구조로 배치할 수 있는 경우. 각 layer는 독립적인 역할을 가지며 이웃한 layer들 간에 서로 interaction할 수 있음. 상위 layer는 하위 layer에 request를 하며 하위 layer는 상위 layer에 response를 줌.	layers 주로 Presentation layer Business layer Persistance layer Database layer로 구성	Layer별 interface가 먼저 정의된다면 각 layer별로 점진적이고 독립적인 개발이 가능함. 상위 layer의 하위 layer로 부터의 독립성이 높음. 이식성이 높음.	상하위의 layer간 통신만 가능한 구조로 인해 여러 layer를 거치는 통신이 비번한 경우, performance가 낮아질 수 있음. 혹은 하위 layer에서의 오류가 상위 layer들로 전달되어 문제을 야기할 수 있음.	Android Framework OSI 7 layer
Virtual Machine	여러 HW 혹은 OS를 가상화하여 특정 프로그래밍 언어나 특정 어플리케이션 수행 환경을 가상으로 제공함.		HW, OS 혹은 Platform에 독립적인 환경을 제공하여 Portability가 높아짐. 다양한 환경에서 수행되어야 하는 SW의 개발 용이성을 제공함.	Interpreter의 수행으로 실행 속도가 낮음.	Interpreter JVM
Non-buffered Event-Based Implicit Invocations		Event source Event listener	새로운 event handler (event listener)를 추가하기 용이함. 동적인 등록 절차를 통해 event source와 listener가 연결되므로 event source와 listener가 runtime에 변경되기 용이함.	Event listener의 동작이 언제 끝날지 예상되지 않아 테스트와 디버깅이 어려움. Buffered 방식 보다는 event source와 listener가 더 tightly coupled 되어 있음.
Buffered Message-Based	분산된 Component간에 독립성의 높이면서 asynchronouse한 통신 방법이 필요한 경우. Distributed transactional business application에서 많이 사용됨.	Message producers Message consumers Message service provider	message producer와 consumer가 message format만 공유하고 상대방을 알지 않아도 되므로 anonymity (익명성)이 높음. message producer와 consumer이 직접 통신하는 것이 아니므로 concurrency를 제공함. Acknowledgement, priority, control level 등을 통해 메시지 전달 방식을 여러가지로 조정할 수 있어 메시지 전달의 scalability와 reliability를 높일 수 있음.	구현과 테스팅, 디버깅이 어려움.	Publisher-Subscriber
Client-Server	전체 시스템의 기능이 요청하는 역할(Client)와 요청을 처리하는 역할(Server)로 나뉘는 경우.	Client Server	분산 환경에서 UI presentation와 business logic의 분리에 용이함. Server의 reusability가 높음.	요구 사항 변경시 client/server 양단을 변경해야하는 번거로움이 있음. Server의 가용성, 안정성을 유지하는데 어려움이 있음. Server/Client가 분산되어 있어 보다 복잡하고 어려운 보안 이슈가 발생할 수 있음.
Multi-tiers	분산 환경에서 presentation, business logic, database component가 나뉘어 지는 경우. Enterprise application에서 주로 사용됨.	Front-end tier for presentation Middle-tier for business logic and execution Back-end tier for database	middle-tier가 추가됨으로써 reusability와 scalability가 증대됨. Business logic의 변경이 middle-tier에만 국한됨.	Client-Server대비 tier의 수가 많아짐에 따라 test가 더 어려워짐.
Proxy	원격에 있는 객체에 대한 method call을 transparent하게 제공하려고 할 때. 긴 operation을 가진 method를 짧게 바로 끝난 것처럼 보이게 할 때. 서비스 제공 객체에 대한 access control을 제공하고자 할 때.	Service object Service Proxy object			RPC
Dispatcher (Load Balancer)	분산 환경에서 scalability와 availability를 높이기 위해서 여러대의 서버를 사용하면서 client에게는 한 대의 서버로 보이게 할 때. Load balancing		서비스의 availability가 높아짐. Scalability가 높아짐.
Service-oriented (SOA)	Client가 Service directory를 통해 필요한 service를 찾은 후 이 서비스에 request를 보내고 받는 방법. 전체 business sequence나 logic을 명세하기 위해서 Orchestration language가 추가로 필요함.	Client Service Directory Services	작은 단위의 각각의 서비스가 독립적으로 개발되고 수행됨. 서비스의 복합적인 구성이 용이하여 개별 서비스의 reusability가 높고 business application의 개발이 효율적임.개별의 서비스		Web Services
Pipe and Filter	시스템이 여러 단계의 데이터 프로세싱 스텝으로 나뉘는 경우.	Data Source Filter: 데이터를 변경하거나 프로세싱하는 각 단계를 캡슐화하고 있음. (active/passige) Pipe Data Sink Data Stream	Concurrency: High throughput Reusability: 단계별 프로세싱이 filter로 filter를 변경함으로써encapsulation되어 끼워넣거나 치환하기가 쉽다. Modifiability: pipe를 통한 filter간 연결로 filter간 low coupling이 형성되어 새로운 filter를 추가할 때 다른 filter에 주는 영향이 적다. Flexibility: Sequential execution과 parallel execution 두가지를 지원함.	Interaction이 많은 경우에 적합하지 않음. Pip를 통과할 때마다 data parsing에 대한 overhead가 늘어남. Dynamic하게 구성하기 어려움.	Named pipe in Unix
Repository	여러 component가 많은 양의 데이터를 계속 주고 받아야할 경우. 데이터 저장소를 통한 통신 방법.	Agents Repository	데이터 저장소를 통해서만 다른 component와 통신하므로 새로운 component를 추가하기가 용이하다.	Data store의 안정성/가용성이 아주 중요하여 centralized repository의 경우, 쉽게 장애가 발생할 수 있다. Data 구조가 자주 변경되는 경우 agent에 주는 영향이 크다.
MVC	데이터에 의해 변경되기 쉬운 UI를 가진 App인 경우.	Model: 모든 fuctional service를 제공하고 데이터를 encapsulation함. View : 데이터를 display하고 데이터가 변경될 때마다 업데이트하는 역할. Control : User input request를 관리하고 user interaction sequence를 control하고 output display를 위한 view를 선정하고 그 밖의 모든 작업들을 하는 역할.	같은 데이터 모델로 여러 View가 Sync될 수 있음. Modifiability: View를 변경하거나 새로운 View를 추가하기 쉬움. (예를 들어 새로운 View기술을 도입하기 쉬움) Graphics, Programming, DB 개발자가 한 팀에서 함께 일하는 경우, 효율적임.	Data model이 변경되는 경우에는 변경 노력이 비쌈. View와 Controller의 구분이 명확하지 않은 경우가 있음.

Class relationship의 Type

정설은 아니지만 그래도 '현실 개발자' 입장에서 좀 더 명확한 구분을 해 볼 수 있다.

Dependency: 한 클래스의 객체가 다른 클래스의 객체를 잠시(단순히) 이용하는 관계. class 간의 가장 약한 관계인데 A 클래스가 B 클래스를 local variable 이나 method의 파라미터로만 사용하는 경우에 해당한다.

Association: 한 클래스의 객체가 다른 클래스의 객체를 일정 시간 이상 이용하는 경우를 통틀어 표현하는 관계. 대부분은 'Part of'의 의미가 아니거나 관계의 타입이 불분명한 경우. Dependency 이상의 관계인데 (attribute로 가지는 관계인데) aggregation인지 composition 인지 애매하면 그냥 association으로 나타내라. 불명확한 것을 굳이 표현하려고 애쓰면 오해가 생기기 마련.

Aggregation: 넓은 의미로는 (Shared) Aggregation과 Composition을 모두 포함함.

• (Shared) Aggregation: 'Part of'의 관계를 가지지만 Part가 독립적으로도 존재가능할 때. 'Part'가 여러 다른 Class의 'Part'도 되는 경우. 'Whole'을 삭제하여도 'Part'는 남아 있는 경우. Composition과 구분 지어서 생각하는 'Aggregation'일 때는 이 경우이다. 
• Composition: 'Whole'과 'Part'가 생명 주기를 같이 하는 경우. 'Whole'로의 multiplicity는 항상 1이다.

Generalization: super class의 attribute, operations, associations, aggregations 가 모두 sub class에 전달되는 경우. 위의 4가지 경우와 가장 큰 차이점은 compile time에 결정되는 관계라는 점.

Deployment Viewpoint

시스템이 수행될 환경과 그 환경에 배치될 artifact를 표현하는 것.
주로 UML Deployment Diagram으로 표현함.

UML Deployment Diagram의 Key Elements

• Artifact
• Software 개발의 산출물 또는 사용되는 physical entity 혹은 information
• file, document, source, library, executable, script, table 등
• Manifestation (Deployment diagram에서 open-arrow dashed line으로 표현됨)
• 산출물의 model element(?)의 concrete and physical rendering
• packageable element의 사용을 표현하는 것.
• Node
• Artifact가 배치되어 실행될 computational resource
• Node의 종류
• Device : processing capability가 있는 Node
• Execution Environment : OS, workflow engine, data base system, J2EE container 등
• 
  
• Communication Path
• Deployment
• Deployment Specification : artifact의 실행 parameter를 결정하기 위한 property set을 명시해 놓은 것. 주로 *xml으로 표현됨.

Information Viewpoint

시스템 구조를 information 관점에서 설계하여 표현한 것.
주로 Class diagram이나 ER diagram으로 표현함.

주의점!

• Class나 Entity의 이름은 단어의 조합으로 표현하지 말 것.
• 예를 들어 UserInfo 대신 그냥 User
• "Persistant" "Object"만 표현
• Sub system, Database, View 같은 것들은 표현하지 말것.

Software Functional Components와 Interface

Software Component는 연관된 기능을 캡슐화한 software package 또는 module을 일컫는다. 내부에는 기능적으로는 일부 Use Case의 functionality를 포함하고 있으며 그 크기에 따라 Class일수도 있고 Package일 수도 있다.

Component는 Interface를 통해 다른 component와 통신하는데 interface를 component 내부의 implementation과 분리함으로써 component의 replaceability를 높일 수 있다. 

• Blackbox Component with Facade Type Interface
• Use case의 functionality가 Interface의 method가 됨.
• Blackbox Component with Mediator Type Interface
• Use case의 sequence diagram의 workflow를 통해 interface의 method가 도출됨. 
• 통상, Facade type보다 개수가 적음. 하지만 workflow의 변경이 있는 경우, interface가 추가되거나 변경될 수 있음.
• Whitebox Component
• Component level의 interface를 제공하지 않는다.

Interface의 타입별 특성을 알아보자.

• View Component의 Interface
• Single system인 경우, API가 아닌 end-user를 위한 UI 그 자체일 수 있다.
• Platform인 경우라면 다양한 application을 위한 API일 수도 있다.

• Data Component의 Interface
• Data Component는 주로 서로 연관된 Entity Object들의 집합
• Entity Object의 Interface
• 해당 Entity Object가 다루는 데이터를 attribute로 가지며 그 attribute에 대한 CRUD operation이 interface가 된다.
• Entity Object는 persistent storage (Database등) 에 대한 dependency를 숨겨주는 역할을 한다.
• Data Component의 Interface는 entity object들에 대한 Facade type API임
• Data를 다루는 기능이므로 workflow를 제공하는 Mediator type API를 가지지 않음.

Use case와 Functional Component

Use case는

• 시스템의 Functionality 단위
• 그래서 이름이 주로 동사로 표현됨. "~하기

Functional Component는

• Functionality를 제공하는 SW 모듈의 단위
• 그래서 이름이 명사 형태로 표현됨. "~하는 것(Manager, Provider 등)"

Functional Component를 도출하는 방법으로는

• SW 설계와 해당 도메인에 경험과 지식이 많아서 사용자 요구사항에서 바로 도출할 수도 있겠지만
• Use case를 정의하고 그룹핑한 것을 Functional Component로 정의하는 것이 더 정확할 수 있다.

자, 이제 Functional Component가 정의 되었다면 Component의 인터페이스르 정의해 보자.

Overview of SW Architecture Design

Definition of SW Architecture (ISO/IEC 42010)

SW Architecture는

• Element(=Component)
• Relationships(=Inter-component relationships)
• Principles(=Constrains on how the architecture consists of components and their relationships)

로 구성된다.

How to Design Architecture?

• 방법론 (Methodology or Process)

• SW Architecture Method에 대한 Knowledgebase
• Architecture Styles (30개)
• Architecture Viewpoints (6~7개)
• Design Tactics for Quality Properties (NFR)

을 함께 이용한다. (둘중 하나라도 없어서는 안된다.)

Architectural Views

• (*) Functional View (Data Manipulation, Logical View)
• (*) Information View (Persistant Data View, Logical View)
• (*) Concurrency View (Behavior or Process View)
• (*) Context View
• Development View
• (*) Deployment View
• Operation View

Activities of the Process

• A1. Architectural Requirement Refinement
• A2. System Context Analysis (Context View 작성)
• A3. Skeleton Architecture Design 
• Architectural style을 결정하고 사용하는 단계.
• 변경/유지보수의 대상이 아님
• A4. View-Specific Architecture Design
• A5. NFR-Specific Architecture Design
• A6. Architecture Validatation

대기업 임원이 보는 Architect의 Role

대기업 임원이 보는 Architect의 Role

• 비젼 제시자
• 핵심 기술조언자
• 의사 결정자
• 코치
• 조정자
• 구현능력
• 대변자

소개를 한 그 임원은 Architect가 가져야 할 중요한 역량으로 리더쉽과 커뮤니케이션 능력을 꼽았다. 그 리더쉽과 커뮤니케이션의 종류에 기술적인 것과 일반적인(관리적인) 것이 모두 포함된다고 설명했는데 회사는 Architect가 둘다를 가지기를 기대한다고 했다. 이것이 우리 회사 아니 한국의 많은 회사들의 현주소인 것이다.

다만, Architect의 경우, 기술적인 리더쉽과 커뮤니케이션 능력이 일반적인 부분에서의 그것보다 훨씬 더 크다는 점에서 General Manager와 다르다고 부연설명을 했다. 

Architect와 Manager의 역할이 섞여 있어 이론적으로는 동의하기 어려우나 현실적으로는 맞는 것 같다.