패턴 - 추상팩토리개요 | 구체적인 서브클래스들을 의존하지 않고, 여러 클래스 집단을 생성하기 위한 인터페이스 | 언제 | 객체들이 생성되는 것을 변경하게 하고 싶을 때, 관련된 여러 객체들이 함께 사용되어야 할 때, 여러 Product 군 중에서 하나를 선택해야 할때 | 참여자 | AbstactFactory, ConcreteFactory, AbstractProduct, ConcreteProduct,Client | 장점 | 구체 클래스를 client에서 분리, Product 그룹을 쉽게 교체, Product 그룹의 객체들 간의 일관성 | 단점 | 전혀다른 새로운 제품 제공이 어렵다. |
패턴 - 빌더언제 | 복잡한 객체들을 생성하는데 그 객체가 하나의 ADT로 나올 수 있을 때, 객체의 생성방법이 복잡하지만 동일한 생성API를 제공하고 싶을 때 | 참여자 | Builder=생성API, ConcreteBuilder=실제생성, Director=생성workflow, Product=제품의ADT | 장점 | Product의 생성 로직을 변경할 수 있다, 생성과 Product 클래스를 코드 분리 |
추상팩토리 vs 빌더추상팩토리 | 확장성에 관심, 매 생성시마다 객체가 나옴 | 빌더 | 복잡한 객체 생성을 단계별로 쪼개는 데 관심, 내부적으로 모든 작업이 끝난 뒤, 마지막에 하나의 객체가 생성 됨 |
패턴 - 책임 연쇄뭐냐 | UI event handling | 언제 | msg receiver들이 다수로 구성되어있고 누가 처리할 지 모를때, msg를 누가 처리할지 정하고 싶지 않을때 | 참여자 | Handler(다른 Handler를 링크), ConcreteHandler | 장점 | msg receiver, sender의 결합이 낮아짐(= 동적으로 삭제/추가해도 무방하다는 것) | 단점 | msg가 반드시 처리되지는 않음, |
패턴 - 반복자뭐냐 | Container의 구조를 노출하지 않고 구성요소를 순회하게 하는 것 | 언제 | container의 내부구조를 노출하고 싶지 않을 때, 구성 요소를 순회하는 단일 API를 제공하고 싶을 때, 순회방법을 여러개 추가하고 싶을때 | 참여자 | Aggregate(Container ADT), ConcreteAggregator, Iterator, ConcreteIterator |
패턴 - Command뭐냐 | 요청을 객체화 | 언제 | 요청을 지연하거나, 요청을 분산처리, 요청을 되돌리거나 | 참여자 | Command(요청의 API), ConcreteCommand, Invoker(명령을 하나씩 처리), Receiver(client에게 알려줌) | 장점 | 요청 추가가 쉽다, 요청을 지연,분산,undo 가능 |
패턴 - 팩토리메소드언제 | 객체의 생성 시점을 client가 정해야 할때, 어떤 클래스를 생성해야 하는지는 서브클래스가 정하게 하고 싶을때 | 참여자 | Product, ConcreteProduct, Creator, ConcreteCreator | 장점 | 생성될 객체를 외부에서 변경할 수 있다. | 단점 | Product와 Creator 양쪽에 서브클래스를 하게 된다. |
패턴 - Adapter언제 | 어느 클래스의 인터페이스를 client가 원하는 인터페이스로 변경해야 할 때, 그런데 그 클래스를 수정할 수는 없을 때 | 참여자 | ObjectAdapter(위임), ClassAdpater(다중상속) 2개 버전이 있다. Target=사용자가 바라보는 인터페이스, Adapter, Adaptee(문제아) |
Adapter vs ProxyAdapter는 기존과 다른 interface로 변형 vs proxy는 realSubject와 동일한 인터페이스를 redirection | Proxy는 객체에 대한 접근을 관리하는 것. |
패턴 - 브릿지뭐냐 | 구현과 추상을 분리해서 서로 조합하게 함. | 언제 | 추상과 구현을 분리할 때, 구현을 런타임에 변경하고 싶을 때, | 참여자 | Abstraction, RefinedAbstraction(확장된 client가 사용할 API), Implementor(구현부의 ADT), ConcreteImplementor | 장점 | 구현이 인터페이스에 얽매이지 않게 됨, 추상과 구현을 각각 확장 가능,상세한 구현을 숨김 |
Adapter vs Bridge구조적으로는 서로 똑같음. 목적이 다르다. client가 사용할 수 있도록 인터페이스를 맞추는 것. Bridge는 추상과 구현이 얽매이지 않도록 함. |
패턴 - Mediator뭐냐 | 복합객체의 workflow를 확장할 수 있도록 한 객체에 몰아주는 것. | 언제 | 메소드 안에 복합객체가 여러 객체들간 interaction이 존재할 때, 각 객체들이 다른 객체와 많은 분산된 interaction이 존재할 때 | 참여자 | Mediator, ConcreteMediator, Colleague, ConcretreColleague | 장점 | 다른 객체를 접근하고 제어하는 코드는 모두 Mediator에 통합, 다른 객체들 간의 종속성을 줄어듬, 제어가 중앙집중적, Mediator를 상속해서 제어를 쉽게 수정 |
Facade vs MediatorFacade는 편한 Interface 사용이 목적 vs Mediator는 객체간 interaction을 가운데서 통제하자. | Facade는 새로운 객체 추가하려면 수정 필요 vs Mediator는 필요 없음. |
패턴 - State언제 | 객체의 상태에 따라서 런타임에 행동이 달라져야 할때, if-else가 가 너무 많을때 | 참여자 | Context(client의 API), State, ConcreteState | 장점 | 특정 state와 관련된 코드를 별도로 모아둘 수 있다, State를 명확하게 구분하고 state전이를 두드러지 게 한다. |
패턴 - Composite뭐냐 | 객체의 트리구조를 하나의 클래스로 구성하는 것 | 언제 | 트리구조를 만들어야 하는데, 모든 구성요소를 하나의 API로 다룰 수 있도록 하고 싶을때 | 참여자 | Component(client가 사용하는 객체 합성 API를 가짐), Leaf(합성이외에 객체를 행동을 정의), Composite(자식을 Component르 가질 수 있도록 API를 구현함) | 장점 | client 코드가 단순해짐, 일관된 클래스 hierarchy가 나옴 | 단점 | 너무 범용적이라 특수화 된 코드를 넣기가 어려움(자식을 1개만 두고 싶다, 새로운 메소드 추가 등) |
패턴 - Visitor뭐냐 | 복합객체의 구조와 코드를 유지하면서 외부에서 그 요소에 대한 연산을 수행할 수 있다. | 언제 | 객체의 구조의 요소들이 서로 다른 클래스일 때, 클래스마다 다른 연산을 적용해야 할때, 해당 클래스들은 코드 수정하고 싶지 않을때, 이러한 추가 연산이 앞으로도 또 일어날 때 | 구조 | Visitor, ConcreteVisitor, Element, ConcreteElement | 장점 | 새로운 연산을 쉽게 추가한다, 관련 연산을 추가할때 한군데에 모아둘 수 있다 | 단점 | 새로운 ConcreteElement 추가하면 모든 Visitor를 다 수정해야 한다. |
패턴 - Observer참여자 | Subject(여러개의 Observer를 가지며, notify()가 불려지면 observer들에게 통보한다), ConcreteSubject, Observer, ConcreteObserver(subject로부터 상태가 변경되었다고 받으면 ConcreteSubject에게 notify 한다.) | 장점 | 1:N 의 sender, receiver 구조를 가질 수 있다, 동적으로 변경할 수 있다, |
패턴 - Strategy언제 | 동적으로 알고리즘 교체, 클래스가 같아도 알고리즘은 달라야 할때, 알고리즘의 추가를 고려할때 | 참여자 | Context(client의 API), Strategy, ConcreteStategy | 장점 | 상속을 사용하지 않으므로 알고리즘을 변경하기 위해서 서브클래싱을 찍어내는 걸 안해도 된다, 조건문이 사라짐, 동적으로 알고리즘 선택 | 단점 | 사용자가 각 전략들이 무엇인지 알고있어야 한다, 어떠한 ConcreteStategy는 Stategy로 넘어온 인자가 필요없는 오버헤드가 있을 수 있다, 객체 수가 증가한다. |
SOLID - Single Responsibility Principle정의 | 한 클래스는 하나의 책임만 가져야 한다. | 안되면? | 책임이 결합된다. 분리되어 있으면 일부만 수정한 부분을 조합해서 재사용이 가능했을 것이다. |
SOLID - Open Closed Principle정의 | 확장에 열려있고, 수정에 닫혀있어야 한다. |
SOLID - Liskov substituion principle
SOLID - Interface Segregation principle뭐야? | 사용자가 사용하지 않는 메소드에 의존하도록 해서는 안된다. | 어떻게 해결? | 다중 상속 (mixin, interface), Delegation |
SOLID - Dependency Inversion Principle뭐야? | '구현에 의존하지 말고, 추상화에 의존하자. 상위 수준(ADT)은 하위수준(구체클래스)에 의존해서는 안된다. |
Coupling vs Cohension결합도 -> 코드가 딱 붙어 의존상태가 강한 정도 (상속, Composition, 등) 낮을수록 좋다 | 응집도 -> 클래스가 하나의 책임에 대해 관련 있는 코드만 잘 모여져 있는가. 관련 없는 메소드가 많이 모여 있거나, 책임이 너무 많이 모여있으면 응집도가 떨어진다. |
| | 요구공학요구공학 | System Service (FR)과 Context(NFR)을 찾고 정리하는 것 | SDLC의 종류 | Water fall, Incremental, Evolutionary, Spiral Iterative, Agile, RUP | RUP의 프로세스 | Inception, elaboration, construction, transition | Incremental의 프로세스 | RE는 RE만, code 팀은 code만, Test팀은 Test만 파이프라인 처럼 | Validation vs Verification | Verification은 명세대로 했는가, Validation은 명세가 올바른가 | RE의 과정 | Feasibility Test > RE Elicitation > Req Specification > Req Validation | Elicitation | System model을 만들고 Workshop, Brainstorming, survey, interview, role playing, prototyping 등을 해서 요구사항을 뽑아낸다. Prioritization&Negotiation으로 NFR에 대해 점수를 메긴다. (FR은 반드시 해야 하므로 필요없다) | Negotiation | 요구사항의 우선순위 측정은 ranking, ahp, grouping, bubble sort, hundred dollors | Specification | 뽑아낸 요구사항을 분류 / 조직화한다. | SRS | Software Requirement Specification (요구사항 최종 산출물). 설계나 Plan이 들어있으면 안된다. | Validation | 최종 검증 (프로토타이핑 등) |
요구공학 - QA - FunctionalitySuitability(적합성) | 지정된 작업과 사용자 목적에 따라 적절한 기능들을 제공 | Accuracy | 올바른 결과를 얼마나 잘 제공할 수 있는가 | Interoperability(상호운영성) | 다른 시스템과 interaction 할 수 있는 정도 | Security | 권한이 없는 사람의 접근을 막거나, 데이터의 변조를 막거나, 권한있는 사람이 허용되게 하는 것 | Compliance(준수성) | SW 관련된 법적 규제, 관례, 규정을 준수하는 정도 |
요구공학 - QA - ReliabilityMaturity(성숙성) | SW 결함이 발생하여 고장이 나지 않도록 하는 정도 | Fault Tolerance(결함허용성) | 결함이 발생하여도, 명세한 성능을 유지할 수 있는 정도 | Recoverability(복구성) | 고장 발생시, 명세된 성능으로 다시 돌아가고 영향받은 데이터를 복구 하는 능력 |
요구공학 - QA - UsabilityUsability | 사용자가 쉽게 이해하고 학습하고 사용되고 선호하는 정도 | Understandability(이해성) | 소프트웨어가 적합한지, 어떻게 사용해야 하는지 사용자가 쉽게 이해하는가? | Learnability(학습성) | 사용자가 쉽게 배울 수 있도록 도와주는 능력 | Operability(운영성) | 사용자가 SW를 쉽게 운영/관리 하게 할 수 있는가? | Attractiveness(선호도) | 사용자에 의해 선호되는 정도 |
요구공학 - QA - EffectivnessEffectiviness | 명세된 조건하에서 얼마나 자원을 덜 사용하여 높은 성능을 내는가? | TimeBehavior(시간 반응성) | 명세된 조건하에서 처리시간과 처리율이 얼마나 빠르고 좋은가? | Resource Utilization(자원 활용성) | 기능을 수행하기 위해서 얼마나 덜 자원을 사용하는가 |
요구공학 - QA - MaintainabilityAnalyzability(분석성) | SW 결함의 원인을 진단하는 능력 | Changeability(변경성) | 명세가 변경되었을때 쉽게 구현하는 정도 | Stability(안정성) | SW 변경으로 예상치 않은 결과가 잘 발생하지 않게 하는 정도 | Testability | 변경된 SW를 검사할 수 있는 능력 |
요구공학 - QA - PortabilityAdaptability(적응성) | SW에서 원래 목적으로 제공되는 것 이외에 다른 환경으로 변경될 수 있는 정도 | Installability(설치성) | 명세된 환경에 설치가 얼마나 쉬운가 | Co-existency(공존성) | 공통 자원을 공유해야 하는 환경에 설치될 경우, 다른 SW와 같이 공존하는 정도 | Replaceability(대체성) | 동일한 환경에서 같은 목적인 SW들과 대체가 얼마나 쉬운가 |
최적설계 - Viewpoints 4+1Viewpoints? | 시스템을 바라보는 관점. View는 그 관점에서 시스템의 요소를 도식화 한것. Logical Views는 구조를, Process View는 흐름, 즉 런타임 동작을, Development는 개발팀의 산출물 (패키지, 코드 위치등)을, Deployment는 최종 시스템 요소의 물리적인 설치를 | Use-Case view | Activity/Info Flow Diagram, UseCase diagram | Logical View | Sequence Diagram, Domain Model Class Diagram | Development view | component diagram, package diagram | Domain Model? | RE 에서 요구사항 분석을 위한 Conceptual class diagram. | Process view | sequence, activity diagram | Physical view | deployment diagram |
최적설계 Quality Life cycleProcess Quality | Internal QA | 개발팀 내에서 세분화한 QA | External QA | Stake holder 들이 제시한 QA. 위에 2개 모두 제품 관점에서 산정한 모델 | Quality in use | 사용자 관점에서 산정한 QA의 모델(모음집) | Architecture concerns | 요구사항 이외에 아키텍트가 추가로 넣는 요구사항으로, 일반적으로 이 프로젝트에서 추가하는 요구사항 혹은 경험에 따라서 추가하는 요구사항 들이다. |
최적설계 - GRASPResponsibility란? | 클래스에 주어진 contract 혹은 의무. 다른 메소드 / 객체와 연계해서 메소드로써 구현됨. 메소드로 동작을 하는 책임도 있는 반면, 다른 객체나 private field를 아는 것도 책임에 포함됨 | GRASP | coupling, cohension, expert, controller, creator, don't talk to stranger | Low coupling이 높으면? | 재사용이 힘듬. 하나 바꾸면 다 바꿔야 함, 코드 이해가 어려움, | cohension이 낮으면? | 여러 책임이 한 클래스에 다 모여있어서 이해가 어려움 직관적이지 않음, | Information Expert | 가장 먼저 클래스에 줄 책임은, 가지고 있는 private info (encapsulated)를 관리하고 값을 채워넣는 책임이다. | Creator | A가 B를 매우 친밀하거나, B를 가지고 있거나, B와 aggregate 하거나 B가 생성될때 초기화 정보를 넣어준다면 A가 B를 생성하게 하라. | controller | Don't talk to stranger |
최적설계 - ADD 방법론ADD? | Architecture Design Methodology | Plan do and check | 모듈 선택 -> 분해 -> Architecture Driver 선택 -> NFR해결을 위한 Style 선택 + FR을 위한 하위 모듈 실체화 -> 하위 모듈의 인터페이스 정의 -> Usecase, QA를 검증하고 contraint 확정 -> 이하 반복 |
최적설계 - Unified processUP 구성 | inception phase, elaboration, construction, transition | 각 phase 별 disciplines | test, code, planning, Req, analysis & design, business modeling, deployment, configuration & change management, Project management | Inception phase | Business modeling, Req 추출, Prototyping, feasibility study | Elaboration | ADD 방법론 등을 사용하여 아키텍처 설계를 해서 Baseline Architecture를 정의한다. Baseline archirecture는 skeleton architecture로 elaboration 단계가 끝나면 최종 완성되며 이후 절대로 바뀌어서는 안된다. |
최적설계 - Pattern, Style, IdiumArchitecture Style | == Architecture Pattern | Pattern? | 특정한 문맥(조건,상황)에서 발생하는 설계 문제가 있을때 그것을 잘 해결하는 일반화된 설계 형태를 제시한 것. | Design pattern? | components나 subsystem을 설계할 때 적용 가능한 패턴 | idium | 구현시 적용 가능한 패턴 |
클래스 관계Association | 클래스를 사용함 | Aggregation | 포함 관계가 있지만 owner가 죽어도 owning은 영향 없음. 중간에 다른 객체에 붙을 수도 있음 | Composition | 포함관계가 있으며 라이프 사이클이 동일함. |
품질속성품질속성 시나리오 구성 | Source(위치), 원인(Stimulus), 대상(Artifact), 상태(Environment), 대응(Response), 대응결과(Response Measure) | Modifiability | 변경 지역화(책임을 분리시킴), 기존 인터페이스를 유지, LateBinding | 성능(자원수요) | 필요한 자원을 줄이기(알고리즘 개선, 요청 자체를 없앤다, 이벤트 빈도 줄이기, | 성능(자원관리) | 동시성 제공,데이터 처리가 병목 되지 않도록, 자원을 늘림(HW), | 가용성(오류감지) | Ping,Echo(다른 컴포넌트,프로세스가 잘 동작하는지 확인), HeartBeat(정상이라고 신호를 내가 보낸다), | 가용성(오류복구) | 같은 일을 처리하는 여러개의 프로세스/Node를 둬서 하나가 망가져도 다른쪽이 잘 동작시킴, 롤백 | 보안 | 기밀성(권한 있는 사람만 본다), 무결성(권한 있는 사람만 write), 인증(송신자가 맞는지 확인), Non-Repudication(부인봉쇄, 안보냈다고 뻥카치지 못하게, AccessControl(권한이 있어야 사용 가능), 가용성(권한이 있으면 서비스 이용이 지속되야) |
UML 표기class diagram | class, interface, component, visibility | deployment diagram | artifacts(file, db), node, components | component diagram | port, provided interface, required interface, component, | sequence | lifeline, message, interaction 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 Sequencial의 차이 | 사전 처리 과정이 완료되어야 하지만, 파이프&필터는 데이터가 계속 주어지는 상황을 전제로 한것이다. |
최적설계 - Process Control분류 | Data Flow | 참여자 | Controller, Actuator, Process, Sensor | 뭐냐 | Controller가 현재 상태를 측정값을 보고 Actuator에게 start/stop을 내린다. Actuator는 핵심 기능을 담당하는 Process에게 이 정보를 전달하고 Process에 input이 들어가면 start/stop을 수행한다. 그 결과는 sensor가 수집하여 다시 Controller에게 전달한다. 이처럼 closed - loop의 구조를 주로 띄게 된다. | 장점 | 복잡한 공식이 없어도 상태값을 일정한 수준으로 유지하게 하는게 가능하다. | 추천 적용 | 상태 값을 제어하는 임베디드 시스템, 빌딩 온도 제어 시스템, 핵 발전소 등 |
최적설계 - Repository참여자 | Repository, Components | 뭐냐 | 중간에 공유 저장소가 있는 것. 그래서 저장소를 기반으로 데이터 interaction 하는 것이다. | 장점 | 데이터 통합되게 해준다, BackUp&Restore를 쉽게 달성한다, 각 components의 확장성/ 재사용 가능하다 (직접적으로 interaction을 하지 않기 때문에), | 단점 | 데이터 중복이 발생할 수 있다, 저장된 데이터의 구조에 components들이 높은 의존성, 데이터의 포맷을 변경하고 확장하는 것은 비용이 크다. |
최적설계 - Blackboard분류 | Data Centered | 참여자 | Blackboard, Control, KnowledgeSource | 뭐냐 | KnowledgeSource는 독립된 서브시스템으로 복잡한 문제 1개를 잘 알려진방법으로 해결한다. Blackboard는 공유 저장소를 가지고 있고 여기에 붙은 KnowledgeSource들은 blackboard에 있는 데이터를 각각 해결해서 업데이트한다. Control은 이 변화를 모니터링 한다. | 언제? | 유일한 해결책이 없는 복잡한 문제를 해결해야 할때 | 장점 | KnowledgeSource를 쉽게 추가가 가능하다. 동시성을 제공한다. | 단점 | blackboard의 구조를 바꾸면 매우 많이 바꿔야 한다. 언제까지 계속 데이터를 업데이트 해야 하는지 판단하는 것이 어렵다. 여러 KnowledgeSource들 간에 동기화문제 |
최적설계 - Layered분류 | Hierarchical | 참여자 | Layer | 뭐냐 | 상위 레이어는 하위레이어에 의존한다. 아래에서 위로 의존관계가 맺어지지는 않는다. 하나의 Layer에서 발생한 수정은 다른 layer에 영향을 주지 않는다. | 언제 적용? | 시스템이 확장해가면서 최소한의 의존을 만들고 각 모듈이 모듈성 재사용성을 높이면서 독립적으로 개발될 수 있어야 할때 | 장점 | 인터페이스가 변하지 않는 한, 하위레이어의 수정이 상위레이어에 영향을 주지 않는다, 각 layer는 미리 정의된 인터페이스로 통신하기 때문에 인터페이스만 지켜주면 쉽게 확장/교체 가능하다., | 단점 | 런타임 성능이 떨어진다. 아래까지 내려갔다가 위로 올라와야 하니까, Exception Handling도 마찬가지로 depth가 깊기 때문이다. |
최적설계 - PlugIn Architecture분류 | Hierarchical | 참여자 | CoreSystem, Plug-in modules | 뭐냐 | App 추가 로직을 PlugIn을 떼었다가 붙였다가 하는 것. 핵심로직은 coreSystem으로 미리 구현을 해놓아야 한다. | 장점 | 이식성, 확장성, |
최적설계 - Virtual Machine참여자 | Application, Virtual Machine, Existing Platform | 장점 | 이식성, SW개발 쉬움 | 단점 | 속도 느림 |
최적설계 - Non-buffered event invoc분류 | Implict asynchronous communication software | 참여자 | Event source, event listener | 뭐냐 | 버퍼를 두지 않고 컴포넌트 끼리 비동기로 interaction 한다. 이벤트가 발생하면 바로 쏜다. 옵저버 패턴하고 유사함 | 장점 | 런타임에 listener를 쉽게 추가/삭제, 재사용성(쉽게 다른 source, listener를 붙일 수 있다), | 단점 | listener의 동작이 언제 끝날지 알기가 힘들다, 디버깅이 어려움, 버퍼 비동기보다 직접적으로 의존하므로 결합도가 높다 |
최적설계 - Buffered Message Based분류 | Implicit Asynchronous communication | 참여자 | MessageBroker, Consumer, Producer | 뭐냐 | Producer가 msg를 xml 등과 같은 형태로 broker에 넣는다. Broker는 가공하거나, 보안체크를 하거나 다른 borker로 route하거나 consumer들에게 전달한다. | 언제 적용 | 네트워크 관리, 날씨 예보, 뱅킹 시스템 | 장점 | 비동기가 가능한데 Producer가 메시지를 보낼때 Consumer가 idle 상태가 아니어도 된다, 매우 독립적인 설계가 가능하며 쉽게 교체/확장이 가능하다, producer는 누가 이 메시지를 받을 것인지 어디에 위치하고 있는지 몰라도 된다, 동시성을 보장한다 | 단점 | 메세지 큐에 한계는 있다, 구현에 복잡도가 올라간다, 디버깅이 어렵고 직접호출보다 퍼포먼스가 저하된다. |
최적설계 - Client - server분류 | Distributed | 참여자 | Client, Server | 뭐냐 | 전체 시스템의 구조를 요청자와 처리자로 tier를 분산하는 것이다. | 언제? | 클라이언트가 여러명이 하나의 서비스로 접근하는데 이를 효율적으로 관리하고 싶을때, 리소스 Control은 중앙집중으로 하고 싶고 리소스 자체는 여러 군데 분산시키고 싶을때 | 장점 | 책임을 분리시킬 수 있다. (presentation, businiess logic), 보안성, 서버의 가용성 |
최적설계 - Multi tier분류 | Distributed | 참여자 | Tier | Layer vs Tier | Layer는 소프트웨어 적으로 구분한 구조의 구성 요소, Tier는 물리적인 요소 | 장점 | 중간에 tier를 넣음으로써 확장성과 재사용성, 비지니스 관련은 중간 티어에만 들어감, 트래픽 감소, 신뢰성 증가, | 단점 | 테스트가 더 어렵다 |
최적설계 - Dispatcher분류 | Distributed | 참여자 | Client, Broker, Server | 뭐냐 | Server들은 모두 같은 구현이다. Broker는 Server의 걸린 load를 보고 제일 좋은 Server로 client의 요청을 연결 시켜 준다. Broker또한 별도의 tier이며, Server는 Broker에 register 한다. | 장점 | Client-Server가 결합도가 낮다, 트래픽에 강하다, 서비스 가용성이 좋다, | 단점 | Broker를 거쳐서 통신하므로 퍼포먼스 저하, 테스트가 어렵다. |
최적설계 - Broker분류 | distributed | 참여자 | Broker, Client, Servant | 뭐냐 | CORBA임. 분산객체 각 Node는 Broker를 앞에 달고 있고 Broker는 해당 Node 내에서 등록한 Servant 들을 모두 들고 있음. Node와 Node는 서로 통신이 가능함. | 장점 | 컴포넌트가 로컬에 있건 외부에 어디에 있건 위치 관계없이 의도한 결과를 얻는다, 완전히 다른 서버와 플랫폼 간의 interaction이 쉽게 가능함, 컴포넌트 재사용이 좋다 | 단점 | 성능이 떨어진다, 장애가 발생할 경우 대처가 어렵다 (fault-torelance), 테스트가 어렵다 | 언제? | 많은 시스템이 분산되어있다, 바인딩을 동적으로 바꾸고, 객체로써 다루고 싶고 서비스 제공자의 위치를 알고싶지도 않고.... |
최적설계 - Master slave분류 | Distributed | 참여자 | Master, Slave | 뭐냐 | Master는 Slave 중에서 주어진 문제를 해결할 수 있는 놈을 선정해서 그 결과를 받아옴 | 장점 | fault tolerance, 신뢰성(실패해도 다른 slave와 연결) | 언제 적용 | fault tolerance, reliability가 중요할때 |
최적설계 - P2P분류 | Distributed | 뭐냐 | 동일한 역할을 부여받은 Peer 노드 끼리 Provider 이자 Consumer로써 서로 연결되어 하나의 contents에 대한 일정 비율을 각각 나누어 가져서 제공하는 것 | structured, unstructured | unstructured는 말그대로 중앙이 아무것도 없음, structured는 중앙에 관리 혹은 분배하는 놈이 더 있고 더 효율적임. | 장점 | 중앙이 없으므로 중앙이 실패할 염려도 없음, 확장성이 좋음 그냥 연결해서 붙이면 끝, 별도의 DB나 서버를 둘 필요가 없음 | 단점 | 시스템 전체적으로 일관성을 갖도록 유지하는 것이 어렵다, 각 node 마다 power가 다르다 |
최적설계 - Service oriented분류 | distributed | 뭐냐 | 서비스(흔히 생각하는 OS의 서비스가 아니다)라고 하는 작은 단위에 독립적인 MVC를 모두 가진 서브시스템이 있다. 이 서비스들을 매우 완화된 포맷인 XML등을 사용해서 레고블럭 처럼 쌓아서 통신하는 것이다. 네트워크를 사용할 수도 있고 사용하지 않을 수도 있다. 다른 언어라고 해도 XML만 지원하면 동작한다. | 언제? | 하나의 큰 시스템을 책임으로 묶어서 보다 작은 서비스로 만들어, 이들간에 표준화된 인터페이스를 정의하고 이를 잘 블럭처럼 쌓아올려서 다른 시스템을 만들때 재사용하고자 하는 것 | 장점 | 상호운용성, 확장성, 재사용성 | 단점 | 구축하기 어렵다, 성능이 떨어진다, 병목현상이 발생할 수 있다. |
최적설계 - micro service분류 | Distributed | 뭐냐 | SOA의 일종의 부분집합이다. SOA는 monolithic 아키텍처다. interaction은 언어에서 독립적인 방법으로 수행하지만 공통으로 묶을 수 있는 부분은 묶는다. (예를들면 공용 DB) 반면 Microsoervice는 각 서비스를 작게 쪼개서 네트워크를 통해 API를 제공할 뿐 그 안에 구성은 encapsulation 하듯이 감추는 것이다. DB도 각자사용하거나 DB를 없앤다. | RESTful? | 네트워크로 API를 만들려면 다양한 방식이 있을 것이다. json으로 https로 날려도 되고. RESTful은 이러한 API를 HTTP의 방식 GET, POST 등을 사용해서 표현하는 것을 말한다. 즉 API 정의방법. | 장점 | 독립적인 작은 서비스이므로 확장이 쉽고, 결합도가 낮다. 모듈화 수준이 높다, 테스트/개발이 쉽다. | 단점 | 언제? | 결합도가 너무너무 높다, 하나만 기능을 고치려는데 시스템 전체를 다 체크한다, 기존 시스템을 분해하면 수십개의 micro service가 나온다. |
최적설계 - MVC단점 | View와 Control 구분하는 것이 때로는 명확하지 않다, Model이 변경되면 impact가 크다. |
|
Created By
Metadata
Favourited By
Comments
No comments yet. Add yours below!
Add a Comment