Show Menu
Cheatography

Programming Architecture Cheat Sheet by

Programming architecture, design patterns, refactoring

패턴 - 추상팩토리

개요
구체적인 서브클래스들을 의존하지 않고, 여러 클래스 집단을 생성하기 위한 인터페이스
언제
객체들이 생성되는 것을 변경하게 하고 싶을 때, 관련된 여러 객체들이 함께 사용되어야 할 때, 여러 Product 군 중에서 하나를 선택해야 할때
참여자
Abstac­tFa­ctory, Concre­teF­actory, Abstra­ctP­roduct, Concre­teP­rod­uct­,Client
장점
구체 클래스를 client에서 분리, Product 그룹을 쉽게 교체, Product 그룹의 객체들 간의 일관성
단점
전혀다른 새로운 제품 제공이 어렵다.

패턴 - 빌더

언제
복잡한 객체들을 생성하는데 그 객체가 하나의 ADT로 나올 수 있을 때, 객체의 생성방법이 복잡하지만 동일한 생성API를 제공하고 싶을 때
참여자
Builde­r=생­성API, Concre­teB­uil­der­=실제생성, Direct­or=­생성w­ork­flow, Produc­t=제­품의ADT
장점
Product의 생성 로직을 변경할 수 있다, 생성과 Product 클래스를 코드 분리

추상팩토리 vs 빌더

추상팩토리
확장성에 관심, 매 생성시마다 객체가 나옴
빌더
복잡한 객체 생성을 단계별로 쪼개는 데 관심, 내부적으로 모든 작업이 끝난 뒤, 마지막에 하나의 객체가 생성 됨

패턴 - 책임 연쇄

뭐냐
UI event handling
언제
msg receiver들이 다수로 구성되어있고 누가 처리할 지 모를때, msg를 누가 처리할지 정하고 싶지 않을때
참여자
Handler(다른 Handler를 링크), Concre­teH­andler
장점
msg receiver, sender의 결합이 낮아짐(= 동적으로 삭제/추가해도 무방하다는 것)
단점
msg가 반드시 처리되지는 않음,

패턴 - 반복자

뭐냐
Container의 구조를 노출하지 않고 구성요소를 순회하게 하는 것
언제
container의 내부구조를 노출하고 싶지 않을 때, 구성 요소를 순회하는 단일 API를 제공하고 싶을 때, 순회방법을 여러개 추가하고 싶을때
참여자
Aggreg­ate­(Co­ntainer ADT), Concre­teA­ggr­egator, Iterator, Concre­teI­terator

패턴 - Command

뭐냐
요청을 객체화
언제
요청을 지연하거나, 요청을 분산처리, 요청을 되돌리거나
참여자
Comman­d(요청의 API), Concre­teC­ommand, Invoke­r(명령을 하나씩 처리), Receiv­er(­cli­ent에게 알려줌)
장점
요청 추가가 쉽다, 요청을 지연,분산,undo 가능

패턴 - 팩토리메소드

언제
객체의 생성 시점을 client가 정해야 할때, 어떤 클래스를 생성해야 하는지는 서브클래스가 정하게 하고 싶을때
참여자
Product, Concre­teP­roduct, Creator, Concre­teC­reator
장점
생성될 객체를 외부에서 변경할 수 있다.
단점
Product와 Creator 양쪽에 서브클래스를 하게 된다.

패턴 - Adapter

언제
어느 클래스의 인터페이스를 client가 원하는 인터페이스로 변경해야 할 때, 그런데 그 클래스를 수정할 수는 없을 때
참여자
Object­Ada­pte­r(위임), ClassA­dpa­ter­(다중상속) 2개 버전이 있다. Target­=사용자가 바라보는 인터페이스, Adapter, Adapte­e(문제아)

Adapter vs Proxy

Adapter는 기존과 다른 interface로 변형 vs proxy는 realSu­bject와 동일한 인터페이스를 redire­ction
Proxy는 객체에 대한 접근을 관리하는 것.

패턴 - 브릿지

뭐냐
구현과 추상을 분리해서 서로 조합하게 함.
언제
추상과 구현을 분리할 때, 구현을 런타임에 변경하고 싶을 때,
참여자
Abstra­ction, Refine­dAb­str­act­ion(확장된 client가 사용할 API), Implem­ent­or(구현부의 ADT), Concre­teI­mpl­ementor
장점
구현이 인터페이스에 얽매이지 않게 됨, 추상과 구현을 각각 확장 가능,상세한 구현을 숨김

Adapter vs Bridge

구조적으로는 서로 똑같음. 목적이 다르다. client가 사용할 수 있도록 인터페이스를 맞추는 것. Bridge는 추상과 구현이 얽매이지 않도록 함.

패턴 - Mediator

뭐냐
복합객체의 workflow를 확장할 수 있도록 한 객체에 몰아주는 것.
언제
메소드 안에 복합객체가 여러 객체들간 intera­ction이 존재할 때, 각 객체들이 다른 객체와 많은 분산된 intera­ction이 존재할 때
참여자
Mediator, Concre­teM­edi­ator, Colleague, Concre­tre­Col­league
장점
다른 객체를 접근하고 제어하는 코드는 모두 Mediator에 통합, 다른 객체들 간의 종속성을 줄어듬, 제어가 중앙집중적, Mediator를 상속해서 제어를 쉽게 수정

Facade vs Mediator

Facade는 편한 Interface 사용이 목적 vs Mediator는 객체간 intera­ction을 가운데서 통제하자.
Facade는 새로운 객체 추가하려면 수정 필요 vs Mediator는 필요 없음.

패턴 - State

언제
객체의 상태에 따라서 런타임에 행동이 달라져야 할때, if-else가 가 너무 많을때
참여자
Contex­t(c­lient의 API), State, Concre­teState
장점
특정 state와 관련된 코드를 별도로 모아둘 수 있다, State를 명확하게 구분하고 state전이를 두드러지 게 한다.

패턴 - Composite

뭐냐
객체의 트리구조를 하나의 클래스로 구성하는 것
언제
트리구조를 만들어야 하는데, 모든 구성요소를 하나의 API로 다룰 수 있도록 하고 싶을때
참여자
Compon­ent­(cl­ient가 사용하는 객체 합성 API를 가짐), Leaf(합성이외에 객체를 행동을 정의), Compos­ite(자식을 Component르 가질 수 있도록 API를 구현함)
장점
client 코드가 단순해짐, 일관된 클래스 hierarchy가 나옴
단점
너무 범용적이라 특수화 된 코드를 넣기가 어려움(자식을 1개만 두고 싶다, 새로운 메소드 추가 등)

패턴 - Visitor

뭐냐
복합객체의 구조와 코드를 유지하면서 외부에서 그 요소에 대한 연산을 수행할 수 있다.
언제
객체의 구조의 요소들이 서로 다른 클래스일 때, 클래스마다 다른 연산을 적용해야 할때, 해당 클래스들은 코드 수정하고 싶지 않을때, 이러한 추가 연산이 앞으로도 또 일어날 때
구조
Visitor, Concre­teV­isitor, Element, Concre­teE­lement
장점
새로운 연산을 쉽게 추가한다, 관련 연산을 추가할때 한군데에 모아둘 수 있다
단점
새로운 Concre­teE­lement 추가하면 모든 Visitor를 다 수정해야 한다.

패턴 - Observer

참여자
Subjec­t(여러개의 Observer를 가지며, notify()가 불려지면 observ­er들에게 통보한다), Concre­teS­ubject, Observer, Concre­teO­bse­rve­r(s­ubj­ect로부터 상태가 변경되었다고 받으면 Concre­teS­ubj­ect에게 notify 한다.)
장점
1:N 의 sender, receiver 구조를 가질 수 있다, 동적으로 변경할 수 있다,

패턴 - Strategy

언제
동적으로 알고리즘 교체, 클래스가 같아도 알고리즘은 달라야 할때, 알고리즘의 추가를 고려할때
참여자
Contex­t(c­lient의 API), Strategy, Concre­teS­tategy
장점
상속을 사용하지 않으므로 알고리즘을 변경하기 위해서 서브클래싱을 찍어내는 걸 안해도 된다, 조건문이 사라짐, 동적으로 알고리즘 선택
단점
사용자가 각 전략들이 무엇인지 알고있어야 한다, 어떠한 Concre­teS­tategy는 Stategy로 넘어온 인자가 필요없는 오버헤드가 있을 수 있다, 객체 수가 증가한다.

SOLID - Single Respon­sib­ility Principle

정의
한 클래스는 하나의 책임만 가져야 한다.
안되면?
책임이 결합된다. 분리되어 있으면 일부만 수정한 부분을 조합해서 재사용이 가능했을 것이다.

SOLID - Open Closed Principle

정의
확장에 열려있고, 수정에 닫혀있어야 한다.

SOLID - Liskov substi­tuion principle

 

SOLID - Interface Segreg­ation principle

뭐야?
사용자가 사용하지 않는 메소드에 의존하도록 해서는 안된다.
어떻게 해결?
다중 상속 (mixin, interf­ace), Delegation

SOLID - Dependency Inversion Principle

뭐야?
'구현에 의존하지 말고, 추상화에 의존하자. 상위 수준(ADT)은 하위수준(구­체클래스)에 의존해서는 안된다.

Coupling vs Cohension

결합도 -> 코드가 딱 붙어 의존상태가 강한 정도 (상속, Compos­ition, 등) 낮을수록 좋다
응집도 -> 클래스가 하나의 책임에 대해 관련 있는 코드만 잘 모여져 있는가. 관련 없는 메소드가 많이 모여 있거나, 책임이 너무 많이 모여있으면 응집도가 떨어진다.
 

요구공학

요구공학
System Service (FR)과 Contex­t(NFR)을 찾고 정리하는 것
SDLC의 종류
Water fall, Increm­ental, Evolut­ionary, Spiral Iterative, Agile, RUP
RUP의 프로세스
Inception, elabor­ation, constr­uction, transition
Increm­ental의 프로세스
RE는 RE만, code 팀은 code만, Test팀은 Test만 파이프라인 처럼
Validation vs Verifi­cation
Verifi­cation은 명세대로 했는가, Valida­tion은 명세가 올바른가
RE의 과정
Feasib­ility Test > RE Elicit­ation > Req Specif­ication > Req Validation
Elicit­ation
System model을 만들고 Workshop, Brains­tor­ming, survey, interview, role playing, protot­yping 등을 해서 요구사항을 뽑아낸다. Priori­tiz­ati­on&Ne­got­iat­ion으로 NFR에 대해 점수를 메긴다. (FR은 반드시 해야 하므로 필요없다)
Negoti­ation
요구사항의 우선순위 측정은 ranking, ahp, grouping, bubble sort, hundred dollors
Specif­ication
뽑아낸 요구사항을 분류 / 조직화한다.
SRS
Software Requir­ement Specif­ication (요구사항 최종 산출물). 설계나 Plan이 들어있으면 안된다.
Validation
최종 검증 (프로토타이핑 등)

요구공학 - QA - Functi­onality

Suitab­ili­ty(적합성)
지정된 작업과 사용자 목적에 따라 적절한 기능들을 제공
Accuracy
올바른 결과를 얼마나 잘 제공할 수 있는가
Intero­per­abi­lit­y(상­호운영성)
다른 시스템과 intera­ction 할 수 있는 정도
Security
권한이 없는 사람의 접근을 막거나, 데이터의 변조를 막거나, 권한있는 사람이 허용되게 하는 것
Compli­anc­e(준수성)
SW 관련된 법적 규제, 관례, 규정을 준수하는 정도

요구공학 - QA - Reliab­ility

Maturi­ty(성숙성)
SW 결함이 발생하여 고장이 나지 않도록 하는 정도
Fault Tolera­nce­(결함허용성)
결함이 발생하여도, 명세한 성능을 유지할 수 있는 정도
Recove­rab­ili­ty(복구성)
고장 발생시, 명세된 성능으로 다시 돌아가고 영향받은 데이터를 복구 하는 능력

요구공학 - QA - Usability

Usability
사용자가 쉽게 이해하고 학습하고 사용되고 선호하는 정도
Unders­tan­dab­ili­ty(이해성)
소프트웨어가 적합한지, 어떻게 사용해야 하는지 사용자가 쉽게 이해하는가?
Learna­bil­ity­(학습성)
사용자가 쉽게 배울 수 있도록 도와주는 능력
Operab­ili­ty(운영성)
사용자가 SW를 쉽게 운영/관리 하게 할 수 있는가?
Attrac­tiv­ene­ss(선호도)
사용자에 의해 선호되는 정도

요구공학 - QA - Effect­ivness

Effect­iviness
명세된 조건하에서 얼마나 자원을 덜 사용하여 높은 성능을 내는가?
TimeBe­hav­ior(시간 반응성)
명세된 조건하에서 처리시간과 처리율이 얼마나 빠르고 좋은가?
Resource Utiliz­ati­on(자원 활용성)
기능을 수행하기 위해서 얼마나 덜 자원을 사용하는가

요구공학 - QA - Mainta­ina­bility

Analyz­abi­lit­y(분석성)
SW 결함의 원인을 진단하는 능력
Change­abi­lit­y(변경성)
명세가 변경되었을때 쉽게 구현하는 정도
Stabil­ity­(안정성)
SW 변경으로 예상치 않은 결과가 잘 발생하지 않게 하는 정도
Testab­ility
변경된 SW를 검사할 수 있는 능력

요구공학 - QA - Portab­ility

Adapta­bil­ity­(적응성)
SW에서 원래 목적으로 제공되는 것 이외에 다른 환경으로 변경될 수 있는 정도
Instal­lab­ili­ty(설치성)
명세된 환경에 설치가 얼마나 쉬운가
Co-exi­ste­ncy­(공존성)
공통 자원을 공유해야 하는 환경에 설치될 경우, 다른 SW와 같이 공존하는 정도
Replac­eab­ili­ty(대체성)
동일한 환경에서 같은 목적인 SW들과 대체가 얼마나 쉬운가

최적설계 - Viewpoints 4+1

Viewpo­ints?
시스템을 바라보는 관점. View는 그 관점에서 시스템의 요소를 도식화 한것. Logical Views는 구조를, Process View는 흐름, 즉 런타임 동작을, Develo­pment는 개발팀의 산출물 (패키지, 코드 위치등)을, Deploy­ment는 최종 시스템 요소의 물리적인 설치를
Use-Case view
Activi­ty/Info Flow Diagram, UseCase diagram
Logical View
Sequence Diagram, Domain Model Class Diagram
Develo­pment view
component diagram, package diagram
Domain Model?
RE 에서 요구사항 분석을 위한 Conceptual class diagram.
Process view
sequence, activity diagram
Physical view
deployment diagram

최적설계 Quality Life cycle

Process Quality
Internal QA
개발팀 내에서 세분화한 QA
External QA
Stake holder 들이 제시한 QA. 위에 2개 모두 제품 관점에서 산정한 모델
Quality in use
사용자 관점에서 산정한 QA의 모델(모음집)
Archit­ecture concerns
요구사항 이외에 아키텍트가 추가로 넣는 요구사항으로, 일반적으로 이 프로젝트에서 추가하는 요구사항 혹은 경험에 따라서 추가하는 요구사항 들이다.

최적설계 - GRASP

Respon­sib­ility란?
클래스에 주어진 contract 혹은 의무. 다른 메소드 / 객체와 연계해서 메소드로써 구현됨. 메소드로 동작을 하는 책임도 있는 반면, 다른 객체나 private field를 아는 것도 책임에 포함됨
GRASP
coupling, cohension, expert, contro­ller, creator, don't talk to stranger
Low coupling이 높으면?
재사용이 힘듬. 하나 바꾸면 다 바꿔야 함, 코드 이해가 어려움,
cohension이 낮으면?
여러 책임이 한 클래스에 다 모여있어서 이해가 어려움 직관적이지 않음,
Inform­ation Expert
가장 먼저 클래스에 줄 책임은, 가지고 있는 private info (encap­sul­ated)를 관리하고 값을 채워넣는 책임이다.
Creator
A가 B를 매우 친밀하거나, B를 가지고 있거나, B와 aggregate 하거나 B가 생성될때 초기화 정보를 넣어준다면 A가 B를 생성하게 하라.
controller
Don't talk to stranger

최적설계 - ADD 방법론

ADD?
Archit­ecture Design Method­ology
Plan do and check
모듈 선택 -> 분해 -> Archit­ecture Driver 선택 -> NFR해결을 위한 Style 선택 + FR을 위한 하위 모듈 실체화 -> 하위 모듈의 인터페이스 정의 -> Usecase, QA를 검증하고 contraint 확정 -> 이하 반복

최적설계 - Unified process

UP 구성
inception phase, elabor­ation, constr­uction, transition
각 phase 별 discip­lines
test, code, planning, Req, analysis & design, business modeling, deploy­ment, config­uration & change manage­ment, Project management
Inception phase
Business modeling, Req 추출, Protot­yping, feasib­ility study
Elabor­ation
ADD 방법론 등을 사용하여 아키텍처 설계를 해서 Baseline Archit­ecture를 정의한다. Baseline archir­ecture는 skeleton archit­ecture로 elabor­ation 단계가 끝나면 최종 완성되며 이후 절대로 바뀌어서는 안된다.

최적설계 - Pattern, Style, Idium

Archit­ecture Style
== Archit­ecture Pattern
Pattern?
특정한 문맥(조건,­상황)에서 발생하는 설계 문제가 있을때 그것을 잘 해결하는 일반화된 설계 형태를 제시한 것.
Design pattern?
compon­ents나 subsystem을 설계할 때 적용 가능한 패턴
idium
구현시 적용 가능한 패턴

클래스 관계

Associ­ation
클래스를 사용함
Aggreg­ation
포함 관계가 있지만 owner가 죽어도 owning은 영향 없음. 중간에 다른 객체에 붙을 수도 있음
Compos­ition
포함관계가 있으며 라이프 사이클이 동일함.

품질속성

품질속성 시나리오 구성
Source­(위치), 원인(Sti­mulus), 대상(Art­ifact), 상태(Env­iro­nment), 대응(Res­ponse), 대응결과(R­esponse Measure)
Modifi­ability
변경 지역화(책임을 분리시킴), 기존 인터페이스를 유지, LateBi­nding
성능(자원수요)
필요한 자원을 줄이기(알고리즘 개선, 요청 자체를 없앤다, 이벤트 빈도 줄이기,
성능(자원관리)
동시성 제공,데이터 처리가 병목 되지 않도록, 자원을 늘림(HW),
가용성(오류감지)
Ping,E­cho(다른 컴포넌트,프로세스가 잘 동작하는지 확인), HeartB­eat­(정상이라고 신호를 내가 보낸다),
가용성(오류복구)
같은 일을 처리하는 여러개의 프로세스/Node를 둬서 하나가 망가져도 다른쪽이 잘 동작시킴, 롤백
보안
기밀성(권한 있는 사람만 본다), 무결성(권한 있는 사람만 write), 인증(송신자가 맞는지 확인), Non-Re­pud­ica­tio­n(부인봉쇄, 안보냈다고 뻥카치지 못하게, Access­Con­tro­l(권한이 있어야 사용 가능), 가용성(권한이 있으면 서비스 이용이 지속되야)

UML 표기

class diagram
class, interface, component, visibility
deployment diagram
artifa­cts­(file, db), node, components
component diagram
port, provided interface, required interface, component,
sequence
lifeline, message, intera­ction use,
activity diagram
swim lanes, merge node, decision node, initial node, final node, merge node, fork node
data flow
external entity, process, datastore
 

최적설계 - Batch Sequencial

분류
Data Flow
뭐냐
Data Flow AS 중 하나. 데이터가 단방향으로 하나의 서브시스템에서 다른 서브시스템으로 이동한다. 각 서브시스템은 input이 넘어와야만 작업할 수 있다.
참여자
Program, Data Store
장점
오직 데이터(파일)에 의해서만 연결되어있이므로 데이터 포맷만 맞추면 쉽게 분리 가능,
단점
데이터만 input이므로 외부에서 각 서브시스템을 제어하기에는 다소 맞지 않는다. 동시성을 지원하지 못하므로 높은 latency를 가진다.

최적설계 - Pipe and Filter

분류
Data Flow
뭐냐
스트림을 따라서 데이터가 필터에 도착하면 데이터를 가공하고 다음 필터로 파이프로 전달.
참여자
데이터스트림, 필터, 파이프
장점
동시성을 제공한다. 데이터가 끊임없이 밀려오고 각 필터는 자기 담당만 처리하므로., 재사용, 변경이쉽다, 단순하다.
단점
동적으로 데이터의 포맷을 변경할 수 없다.
Batch Sequen­cial의 차이
사전 처리 과정이 완료되어야 하지만, 파이프&필터는 데이터가 계속 주어지는 상황을 전제로 한것이다.

최적설계 - Process Control

분류
Data Flow
참여자
Contro­ller, Actuator, Process, Sensor
뭐냐
Contro­ller가 현재 상태를 측정값을 보고 Actuator에게 start/­stop을 내린다. Actuator는 핵심 기능을 담당하는 Process에게 이 정보를 전달하고 Process에 input이 들어가면 start/­stop을 수행한다. 그 결과는 sensor가 수집하여 다시 Contro­ller에게 전달한다. 이처럼 closed - loop의 구조를 주로 띄게 된다.
장점
복잡한 공식이 없어도 상태값을 일정한 수준으로 유지하게 하는게 가능하다.
추천 적용
상태 값을 제어하는 임베디드 시스템, 빌딩 온도 제어 시스템, 핵 발전소 등

최적설계 - Repository

참여자
Reposi­tory, Components
뭐냐
중간에 공유 저장소가 있는 것. 그래서 저장소를 기반으로 데이터 intera­ction 하는 것이다.
장점
데이터 통합되게 해준다, BackUp­&R­estore를 쉽게 달성한다, 각 compon­ents의 확장성/ 재사용 가능하다 (직접적으로 intera­ction을 하지 않기 때문에),
단점
데이터 중복이 발생할 수 있다, 저장된 데이터의 구조에 compon­ents들이 높은 의존성, 데이터의 포맷을 변경하고 확장하는 것은 비용이 크다.

최적설계 - Blackboard

분류
Data Centered
참여자
Blackb­oard, Control, Knowle­dge­Source
뭐냐
Knowle­dge­Source는 독립된 서브시스템으로 복잡한 문제 1개를 잘 알려진방법으로 해결한다. Blackb­oard는 공유 저장소를 가지고 있고 여기에 붙은 Knowle­dge­Sou­rce들은 blackb­oard에 있는 데이터를 각각 해결해서 업데이트한다. Control은 이 변화를 모니터링 한다.
언제?
유일한 해결책이 없는 복잡한 문제를 해결해야 할때
장점
Knowle­dge­Source를 쉽게 추가가 가능하다. 동시성을 제공한다.
단점
blackb­oard의 구조를 바꾸면 매우 많이 바꿔야 한다. 언제까지 계속 데이터를 업데이트 해야 하는지 판단하는 것이 어렵다. 여러 Knowle­dge­Source들 간에 동기화문제

최적설계 - Layered

분류
Hierar­chical
참여자
Layer
뭐냐
상위 레이어는 하위레이어에 의존한다. 아래에서 위로 의존관계가 맺어지지는 않는다. 하나의 Layer에서 발생한 수정은 다른 layer에 영향을 주지 않는다.
언제 적용?
시스템이 확장해가면서 최소한의 의존을 만들고 각 모듈이 모듈성 재사용성을 높이면서 독립적으로 개발될 수 있어야 할때
장점
인터페이스가 변하지 않는 한, 하위레이어의 수정이 상위레이어에 영향을 주지 않는다, 각 layer는 미리 정의된 인터페이스로 통신하기 때문에 인터페이스만 지켜주면 쉽게 확장/교체 가능하다.,
단점
런타임 성능이 떨어진다. 아래까지 내려갔다가 위로 올라와야 하니까, Exception Handling도 마찬가지로 depth가 깊기 때문이다.

최적설계 - PlugIn Archit­ecture

분류
Hierar­chical
참여자
CoreSy­stem, Plug-in modules
뭐냐
App 추가 로직을 PlugIn을 떼었다가 붙였다가 하는 것. 핵심로직은 coreSy­stem으로 미리 구현을 해놓아야 한다.
장점
이식성, 확장성,

최적설계 - Virtual Machine

참여자
Applic­ation, Virtual Machine, Existing Platform
장점
이식성, SW개발 쉬움
단점
속도 느림

최적설계 - Non-bu­ffered event invoc

분류
Implict asynch­ronous commun­ication software
참여자
Event source, event listener
뭐냐
버퍼를 두지 않고 컴포넌트 끼리 비동기로 intera­ction 한다. 이벤트가 발생하면 바로 쏜다. 옵저버 패턴하고 유사함
장점
런타임에 listener를 쉽게 추가/삭제, 재사용성(쉽게 다른 source, listener를 붙일 수 있다),
단점
listener의 동작이 언제 끝날지 알기가 힘들다, 디버깅이 어려움, 버퍼 비동기보다 직접적으로 의존하므로 결합도가 높다

최적설계 - Buffered Message Based

분류
Implicit Asynch­ronous commun­ication
참여자
Messag­eBr­oker, Consumer, Producer
뭐냐
Producer가 msg를 xml 등과 같은 형태로 broker에 넣는다. Broker는 가공하거나, 보안체크를 하거나 다른 borker로 route하거나 consum­er들에게 전달한다.
언제 적용
네트워크 관리, 날씨 예보, 뱅킹 시스템
장점
비동기가 가능한데 Producer가 메시지를 보낼때 Consumer가 idle 상태가 아니어도 된다, 매우 독립적인 설계가 가능하며 쉽게 교체/확장이 가능하다, producer는 누가 이 메시지를 받을 것인지 어디에 위치하고 있는지 몰라도 된다, 동시성을 보장한다
단점
메세지 큐에 한계는 있다, 구현에 복잡도가 올라간다, 디버깅이 어렵고 직접호출보다 퍼포먼스가 저하된다.

최적설계 - Client - server

분류
Distri­buted
참여자
Client, Server
뭐냐
전체 시스템의 구조를 요청자와 처리자로 tier를 분산하는 것이다.
언제?
클라이언트가 여러명이 하나의 서비스로 접근하는데 이를 효율적으로 관리하고 싶을때, 리소스 Control은 중앙집중으로 하고 싶고 리소스 자체는 여러 군데 분산시키고 싶을때
장점
책임을 분리시킬 수 있다. (prese­nta­tion, businiess logic), 보안성, 서버의 가용성

최적설계 - Multi tier

분류
Distri­buted
참여자
Tier
Layer vs Tier
Layer는 소프트웨어 적으로 구분한 구조의 구성 요소, Tier는 물리적인 요소
장점
중간에 tier를 넣음으로써 확장성과 재사용성, 비지니스 관련은 중간 티어에만 들어감, 트래픽 감소, 신뢰성 증가,
단점
테스트가 더 어렵다

최적설계 - Dispatcher

분류
Distri­buted
참여자
Client, Broker, Server
뭐냐
Server들은 모두 같은 구현이다. Broker는 Server의 걸린 load를 보고 제일 좋은 Server로 client의 요청을 연결 시켜 준다. Broker또한 별도의 tier이며, Server는 Broker에 register 한다.
장점
Client­-Se­rver가 결합도가 낮다, 트래픽에 강하다, 서비스 가용성이 좋다,
단점
Broker를 거쳐서 통신하므로 퍼포먼스 저하, 테스트가 어렵다.

최적설계 - Broker

분류
distri­buted
참여자
Broker, Client, Servant
뭐냐
CORBA임. 분산객체 각 Node는 Broker를 앞에 달고 있고 Broker는 해당 Node 내에서 등록한 Servant 들을 모두 들고 있음. Node와 Node는 서로 통신이 가능함.
장점
컴포넌트가 로컬에 있건 외부에 어디에 있건 위치 관계없이 의도한 결과를 얻는다, 완전히 다른 서버와 플랫폼 간의 intera­ction이 쉽게 가능함, 컴포넌트 재사용이 좋다
단점
성능이 떨어진다, 장애가 발생할 경우 대처가 어렵다 (fault­-to­rel­ance), 테스트가 어렵다
언제?
많은 시스템이 분산되어있다, 바인딩을 동적으로 바꾸고, 객체로써 다루고 싶고 서비스 제공자의 위치를 알고싶지도 않고....

최적설계 - Master slave

분류
Distri­buted
참여자
Master, Slave
뭐냐
Master는 Slave 중에서 주어진 문제를 해결할 수 있는 놈을 선정해서 그 결과를 받아옴
장점
fault tolerance, 신뢰성(실패해도 다른 slave와 연결)
언제 적용
fault tolerance, reliab­ility가 중요할때

최적설계 - P2P

분류
Distri­buted
뭐냐
동일한 역할을 부여받은 Peer 노드 끼리 Provider 이자 Consumer로써 서로 연결되어 하나의 contents에 대한 일정 비율을 각각 나누어 가져서 제공하는 것
struct­ured, unstru­ctured
unstru­ctured는 말그대로 중앙이 아무것도 없음, struct­ured는 중앙에 관리 혹은 분배하는 놈이 더 있고 더 효율적임.
장점
중앙이 없으므로 중앙이 실패할 염려도 없음, 확장성이 좋음 그냥 연결해서 붙이면 끝, 별도의 DB나 서버를 둘 필요가 없음
단점
시스템 전체적으로 일관성을 갖도록 유지하는 것이 어렵다, 각 node 마다 power가 다르다

최적설계 - Service oriented

분류
distri­buted
뭐냐
서비스(흔히 생각하는 OS의 서비스가 아니다)라고 하는 작은 단위에 독립적인 MVC를 모두 가진 서브시스템이 있다. 이 서비스들을 매우 완화된 포맷인 XML등을 사용해서 레고블럭 처럼 쌓아서 통신하는 것이다. 네트워크를 사용할 수도 있고 사용하지 않을 수도 있다. 다른 언어라고 해도 XML만 지원하면 동작한다.
언제?
하나의 큰 시스템을 책임으로 묶어서 보다 작은 서비스로 만들어, 이들간에 표준화된 인터페이스를 정의하고 이를 잘 블럭처럼 쌓아올려서 다른 시스템을 만들때 재사용하고자 하는 것
장점
상호운용성, 확장성, 재사용성
단점
구축하기 어렵다, 성능이 떨어진다, 병목현상이 발생할 수 있다.

최적설계 - micro service

분류
Distri­buted
뭐냐
SOA의 일종의 부분집합이다. SOA는 monolithic 아키텍처다. intera­ction은 언어에서 독립적인 방법으로 수행하지만 공통으로 묶을 수 있는 부분은 묶는다. (예를들면 공용 DB) 반면 Micros­oer­vice는 각 서비스를 작게 쪼개서 네트워크를 통해 API를 제공할 뿐 그 안에 구성은 encaps­ulation 하듯이 감추는 것이다. DB도 각자사용하거나 DB를 없앤다.
RESTful?
네트워크로 API를 만들려면 다양한 방식이 있을 것이다. json으로 https로 날려도 되고. RESTful은 이러한 API를 HTTP의 방식 GET, POST 등을 사용해서 표현하는 것을 말한다. 즉 API 정의방법.
장점
독립적인 작은 서비스이므로 확장이 쉽고, 결합도가 낮다. 모듈화 수준이 높다, 테스트/개발이 쉽다.
단점
언제?
결합도가 너무너무 높다, 하나만 기능을 고치려는데 시스템 전체를 다 체크한다, 기존 시스템을 분해하면 수십개의 micro service가 나온다.

최적설계 - MVC

단점
View와 Control 구분하는 것이 때로는 명확하지 않다, Model이 변경되면 impact가 크다.

최적설계 - PAC

 
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.