Software blog

Consideration when choose arch

• Structural pattern
• Computational model
• Essential invariant of the style
• Common specialization

Pipe and Filter

• Def
  • Each component has input and outputs
  • Component reads stream of data on its inputs and produce stream of data on its data output, and delivering a complete instance

    

• Benefits
  • Easy understand the overall input/output behavior
  • Reusability
  • Enhancements & Maintenance
    • Easy to add and replace new filter or alternations
• Disadvantages
  • Designer should consider transformation of input data to output data
  • Filters are inherently dependant
  • Not good at handling interactive applications

Data Abstraction and Object Oriented Organization

• ADT
• Def
  • Primitive operations are encapsulated in an object or ADT
  • ADT is responsible for preserving the integrity of resources
  • Representation is hidden from other objects
• Benefit
  • Change implementation without affection those clients
  • Designer can decompose the problem into collections.
• Disadvantages
  • Must know identity of the other objects.
    • In the contrast, filters (pipe and filter) don't need to know what other filters are in the systems.

    

Event based, Implicit invocation

• Def
  • Implicit Invocation is that instead of invoking procedure call directly, a component can announce one or more events, other component can register an interest in an event.
• Feature
  • Events don't know which components will be affected.
  • Cannot make assumption about order of processing
  • Can have explicit invocations as complementary form of interaction
• Benefits
  • Strong reuse
  • Implicit invocation eases system evolutions
  • Can changing easily
• Disadvantages
  • Relinquish control ( if other components didn't response it then fall the panic)
  • Exchanging data (Global memory using)

    

Layered Architecture

• Def
  • Organized hierarchically, each layer providing service to the layer above layer it and serving to the layer below it.
• Benefits
  • Increasing level of abstractions
  • Enhancements
  • Reuse
• Disadvantages
  • Requiring closer coupling
  • Difficult to find right level of abstractions.

    

Repository (Black boards)

• Def
  • Consist of two kinds of components as follows
    • Central data structure (Current state)
    • Collection of independent component operate on the central data store
• Blackboard Architecture
  • Properties
    • The knowledge sources
      • Separate, independent parcel of applications dependent knowledge
    • The blackboard data structure
      • Problem-solving state data
  • Benefit
    • No explicit representation of the control component

      

Table driven interpreter

• Interpreter's analog of its execution state + pseudo program
• Interpreter components
  • Engine to do works
  • Memory contain pseudo code
  • Representation of the control
  • Representation of the current state

  

     

4+1 view model of architecture

• Why need
  • The system designer suffer from design by using a single view such as box and arrow diagram
• 4+1 Model allows that designer build using several architectures to satisfy functional requirements and non-functional requirements of the system

Logical view

• Def
  • Designer decompose the system into a set of key abstractions for supporting functional requirements
• Style
  • Class diagram
  • Statechart

Process view

• Def
  • Account some non-functional requirements
  • Specify which thread of control executes each operations identified in the logical view
• Style
  • Pipe and Filter
  • Client-Server or multiple client - multiple server model
  • ISIS

Development view

• Def
  • Focus on the organization of the actual software module in the software-development environments
• Style
  • Layered architecture

Physical view

• Def
  • Into account of non functional requirements
  • The various elements indentified in the logical process and development view must be mapped on the various devices
• Consideration
  • Highly flexible minimal impact on the source code and change large scalability

Refinements

• 모든 디자인은 refinement와 연관되어 있다.
  • Refinement, High Level understanding에 implementation으로 이동하는 단계
  • 문제의 복잡도에 따라 다수의 레이어가 하나의 문제에 연관 될 수 있음.
• 적절한 레이어 디자인을 위한 프로퍼티
  • Top 레이어는 요구사항을 faithfully represent 해야 한다.
  • 각각의 레이어는 내부적으로 컨시스턴시를 유지해야 함
  • 모든 레이어는 자신의 상위 레이어에게 faithfully represent해야 함.

     

Valid Refinements

• 디자이너는 구현사항이 specification을 만족함을 반드시 논증(demonstrate)할 필요가 있음
• 이 demonstrate는 종종 proof obligations라고 불리는 verification condition셋 들이 사용됨.
• Demonstration은 사용되는 프로세스에 따라 formal 하기도 informal 하기도 함.

     

Specification of class include

• Attribute
  • Type
  • Size
  • Property
• Operations
  • Signature
  • Pre/Post conditions
  • Invariants over the variable

Notation

• Pi, i번째 abstract specifications.
• Qi는 Pi에 상응하는 concrete operations.
• S 는 abstract states의 집합
• s는 S의 원소 (attribute value의 조합)
• s'는 s operation에 의한 다음 abstract states.
• Inv 는 invariant
  • invC - concrete invariant
  • invA - abstract invariant
• Pre-Pi (s, args)
  • s와 args로 수행되는 Pi의 이전 상태
• Post-Pi (s, args, s', res)
  • s, args로 시작하여 s', res로 끝나는 Pi의 포스트 컨디션
• t는 set T에 포함되는 concrete state임
  • Concrete state - concrete attributes의 state들 조합
• retr
  • Retrieve 함수
  • Concrete state로부터 상응하는 abstract state를 회수하는 함수.
  • 예를 들면 retr(t) = s, s는 t에 상응하는 unique 한 abstract state.

Demonstrate

• Property 1 -- The top layer should faithfully represent the requirements
  • 어떻게 이것을 수행 할 수 있는 가.
    • 일반적으로 이 부분은 개인적이거나 아니면 공식적인 회의를 통한 review형식을 통해서 체크할 수 있음.
• Property 2 - Each layer must be internally consistent
  • 특정 클래스의 consistency를 논증하는 방법
    • 각 operation이 invariants를 모두 유지하고 있음을 보증하면 됨.
  • Valid operation을 만족 해 야함.
• Property 3 -- Each layer must faithfully represent the layer above it
  • 각각의 레이어가 상위의 레이어에게 faithfully represent해야 함
  • abstract 레이어와 concrete refinement간의 매핑을 검토 해보는 것으로 해결가능
  • 그럼 이 매핑을 어떻게 검토해볼 것인가?
    • Abstract state는 적어도 하나의 concrete state로 매핑 가능 해 야함
    • Total
      • 각각의 concrete 레이어는 abstract state에 의도한 바를 벗어나서 매핑 되면 안됨.
    • Abstract 오퍼레이션은 반드시 하나의 concrete 형태로 faithfully 모델 되어야 함.

Formality

• Valid operations (Property 2)
  • Concrete, Abstract 포함하여 모든 specification에서 invariants는 모두 보존되어야 함.
  • 다시 말해서 오퍼레이션 이전, 실행 이전에 invariants가 true였으면 그 이후에도 true 여야 함
  • Inv(S) ^ Pre-Pi(s, args) ^ Post-Pi (s, args, s', res) <=> inv(s')
• Adequate Represent
  • Refinement는 반드시 적절해야 함
  • 구현은 각각의 abstract state가 concrete state로 구체화 될 만큼 충분해야 함
  • 만약 각각의 abstract invariant가 true 였다면 구현에 의한 invariants 역시 true여야 함.
  • All s ∈ S : inv(s) => Any t ∈ T : invC(t) ^ t = retr(t)
    • 모든 abstract state는 concrete state 에서 변화가 없어야 하므로 and시 변화가 없을 것이고 이는 retr에 의해서 원복 되는 abstract s와 동일함.
• Total represent
  • 우리는 refinements가 abstract specification에 상응되지 않는 어떤 state를 만들지 않음을 보장해야 함.
  • 주어진 abstract state에 대해서 아주 많은 concrete 모델이 있을 수는 있으나 각각의 concrete state는 반드시 abstract specification에 상응 해야 한다.
  • Retrieve 함수는 반드시 total이 되어야 한다는 것과 동일.
  • All t ∈ T : invC(t) => (Any s ∈ S: s = retr(t) ) ^ invA(retr(t))
    • Abstract state와 반드시 상응해야 하므로 t에 의해 회수된 s와 이전 s는 동일하고 이 s의 값은 s의 invariant와 동일함.

Operations

• Refine을 하기 위해서 크게 두 가지를 고려해야 함
  • 구현은 specification에 묘사된 모든 입력에 대해서 핸들 가능해야 함.
  • 오퍼레이션에 의해서 클래스 attribute의 변경에 따라 생산되는 아웃풋은 반드시 operation specification을 만족 해야 함.
• Operation Modeling
  • Precondition
    • Abstract specification에서 만족될만한 circumstance들은 모두 concrete 구현에서 만족 될 수 있음.
    • Refinement 는 pre-condition에서 약해 질 수 있음.
    • All t ∈ T: invC(t) ^ pre-Pi(retr(t), args) => pre-Qi (t, args)
  • Postcondition
    • 구현에 대한 실행은 반드시 abstract specification에 언급된 내용들에 상응하는 valid한 상태로 시스템을 남겨 둬야 한다.
    • Concrete post condition은 반드시 abstract post condition에 상응되어야 함.
    • Any t ∈ T: invC(t) ^ Pre-Qi(t, args) ^ Post-Qi(t, args, t', res)
      => Post-Pi(retr(t), args, retr(t'), res)

Summary

• 디자이너는 다음 아래 5가지 상황에 대해서 반드시 requirements 문서와 specification 문서를 검토해야 함.
  • 오퍼레이션의 각 레벨은 반드시 invariant를 보존 해야 함
  • Refinement는 적절해야 함
  • Refinement는 total이어야 함.
  • 오퍼레이션 precondition은 충분히 느슨(weak)해야 함.
  • 오퍼레이션 postcondition은 충분히 강해야 함.

Design Quality

• 오브젝트의 퀄리티를 산정하는 데는 매우 여러 가지 어프로치가 존재
  • Design review
  • Metrics
  • Prototyping
  • 충실한 가이드라인 (Adherence to guidelines)

Design Guidelines

• 디자인 원칙과 가이드라인은 비공식적인 형식의 어드바이스임
• WRT OO 가이드라인의 경우 해야 할 것과 해야 하지 말아야 할 것에 대해서만 기술하고 있음
  • 예를 들어 bad smell이나 휴리스틱 사용과 같은

Review three important foundational concepts

• Coupling
  • 다른 모듈과의 독립성에 대한 영역
    • 가급적 낮은 커플링이 좋음
  • 소프트웨어 Maintenance 비용을 줄이는 한 가지 방법이 됨.
• Cohesion
  • 한 모듈이 하나의 목적만을 이루는 것을 다룸
    • 높은 코히션이 좋음(Strive for high cohesion)
  • 코히션이 높아지면 코드 readability와 reusability가 좋아짐.
    • 하나의 펑션 또는 모듈이 하나의 기능만 하기 때문에 그만큼 추상화 수준이 이해하기 쉬워 지므로 읽기 쉽고, 그 의미 단위로 그대로 사용 할 수 있기 때문에 재사용성이 좋아지는 것은 당연함.
• Orthogonality
  • 다양한 Feature들이 서로 독립적으로 동작할 수 있도록 함.
  • 시스템 디스크립션을 명세
  • Weird combinations
    • Orthogonality를 만족할 경우 모듈간 자연스러운 조합이 가능해짐.

Information Hiding Principles

• 간략한 정의
  • Information hiding은 hiding과 관련된 디자인 결정에 일부로 만약 시스템에 잦은 변화가 요구된다면 요구된 특정 프로그램의 다른 파트를 그러한 변화로부터 보호 하는 역할을 함.
• Encapsulation이라고도 부름
• 상속에 의한 Violation이 가능.

Liskov Substitution Principle

• 서브클래스의 인스턴스는 반드시 부모 클래스의 Definition을 만족 해야 함.
  • 만약 클라이언트가 부모 클래스의 인스턴스를 엑셉트 하고 정상적으로 동작 시킬 수 있다면 자식 클래스 인스턴스 역시 동작 할 수 있어야 함
• 다시 이야기 하면 이는 자식 클래스의 인스턴스는 반드시 부모 클래스의 invariants 또는 메서드 contract를 지켜 줘야 한다는 것임
  • Pre/ post 컨디션 처리가 모두 만족 되어야 함.
  • 자식 메스드의 precondition은 좀 더 약할 수 있음.
  • Postcondition은 좀 더 강함.
  • 더 많이도 그렇다고 더 적지도 않게 이를 지켜주면 됨.

Law of Demeter

• 정의
  • 오브젝트 O의 메서드 M이 있다고 가정하면 이 메서드를 호출 할 수 있는 오브젝트는 Direct component Object 밖에 없음.
    • 오브젝트 O
    • 메서드 M에 기술된 파라미터 오브젝트
    • M 안에서 생성되거나 초기화 되는 오브젝트
• 내부 모듈간의 디펜던시를 줄임
• 래퍼 클래스를 야기 할 수 있음.
• Lieberherr

Hollywood Principle

• 오브젝트 오리엔티드 프레임워크는 클라이언트 코드에 의해서 불리기 보다는 클라이언트 코드를 불려야 함.
  • OO 프레임워크는 추상 클래스에 협업하는 셋임.
  • "Don't call us; we'll call you"
  • 컨트롤 인버젼
    • Cohesion이 올라가고 커플링이 낮아짐.
    • Maintenance, 디버깅등이 쉬워짐.

Dependency Inversion Principle

• 정의(Martin)
  • 하이레벨 모듈은 하위레벨의 모듈에 의존 하지 않아야 함
  • 둘 다 abstraction에 의존 해야 함.
• 인버젼 컨트롤과 관계가 있음
• 전통적인 레이어드 아키텍쳐에 반대 되는 것임

Open-Closed Principle

• 클래스는 익스텐션에 있어야 하나 수정에는 닫혀 있어야 함
• 클래스를 상속 하고 나면 클래스를 변경 하지 않아야 함.
• 두 가지 뷰가 존재
  • 구현 상속 (Implementation Inheritance, Mayers)
  • 인터페이스 상속 (Interface inheritance, Martin)

Martin's Principles

• Interface Segregation Principles
  • 인터페이스 분리 원칙
  • 대부분의 클라이언트는 큰 인터페이스의 클래스의 일부부만 사용 하는 경향이 존재
    • 복잡한 클래스 인터페이스를 부분적으로 분리
  • 인터페이스 분리 시 Collaboration, Role-based 설계 원칙을 고수

     

• Release Reuse Equivalency Principles
  • 재사용에 그래뉼(granule)은 릴리즈의 그래뉼임.
  • 리유저는 변화를 track하고 싶어함.
  • 패키지 아이디어는 release, reuse 아이디어가 잘 적용 된 예임.
• Common Closure Principle
  • 같은 무리들은 같이 변경하고 소유하도록 함
  • 디펜덴시를 최소화하여 변화에 대한 임팩츠를 줄임
• Common Reuse Principle
  • 같이 재사용 되지 않는 클래스들은 하나의 그룹으로 묶어 내지 않는 원칙
  • 특정 변화가 있을 때 리유저에게 임팩트를 최소화 함.
• Acyclic Dependency Principle
  • 패키지들끼리 디펜던시 사이클이 생기지 않도록 해야함
  • 사이클을 분리하는 방법
    • A와 B가 사이클이 있다면 그 기능을 하는 C를 만들고 A,B가 C에게 디펜던시를 가지도록 함
    • A의 인터페이스를 B에 추가하고 A의 기능을 B에서 구현
• Stable Dependencies Principle
  • Stable이 안정성을 의미하는 것이 아니라 수정하기 어려운 정도를 이야기 하는 것임.

    "Stable" roughly means "hard to change", whereas "instable" means "easy to change".

  • 모든 패키지에 대해서 stability를 낮추는 것이 목적.
  • Stability Metric
    • I = Ce / (Ca + Ce)
    • Ce는 efferent coupling, 즉 나가는 아크를 이야기 하는데 주어진 컴포넌트가 의존하고 있는 컴포넌트 수
    • Ca 는 afferent coupling, 들어오는 아크를 의미함. 다시 말해서 주어진 컴포넌트를 참조하고 있는 컴포넌트의 수
• Stable Abstraction Principle
  • Stable 패키지는 반드시 추상 패키지가 되어야 한다.
    • 다른 패키지에 많이 의존적인 패키지는 반드시 Abstract되어야 한다.
    • 이러한 패키지들은 변경하기는 어렵지만 확장하기는 쉬운 특징이 있음.
  • Abstractness
    • A = Na / Nc
      • Na = # of abstract classes
      • Nc = total # of classes
  • Normalize Distance
    • D' = | A + I - 1 |
    • Distance는 짧을 수록 좋음.
      • 추상도가 높은 것이 좋긴 하나 추상도가 높다는 것은 Martin 모델에서는 stable하다는 것으로 판단 하는 경향이 있는 것으로 보임.
      • Stability는 당연히 낮은 것이 좋으므로 결국 A + I 는 같은 의미로 판단됨.

Bad Smell

• 디자인 문제의 증상.
  • 중복된 코드, 너무 많은 코멘트, 너무 긴 클래스등..
• 리팩토링이 필요함을 인식 할 수 있음

     

Design Heuristics

• 클래스의 유저들은 API에 의존적이나 클래스는 그것의 유저들에게 의존하지 않아야 함.
• 분산 시스템에서는 가급적 수평적(Horizontally) 한 것이 좋음.
• GOD 클래스나 오브젝트를 생성 하지 말것

  (스캇 마이어스가 한 이야기가 그대로 언급되는데, 실제 원자는 Riel로 보임)

• 분산 시스템에서 수직적으로는 좁아지고 더 깊어지는 하이라키를 견제 (Containment) 해야 함.

Factoring

• 데이터, behavior, 인터페이스등 Commonality의 요소(Factor)를 상속 하이라키에서 가능한 한 높이는 것임.

Inheritance

• 상속은 Specialization 하이라키 모델에서만 사용 되어야 함
• 컴포지션, Aggregation, Delegation등이 선호됨.
• 상속 클래스에서 부모 클래스의 NOP 매서드를 오버라이드 하는 것은 안됨.

Abstraction

• 인터페이스를 사용 하지 않고 오브젝트 상태를 변화 시키면 안됨.
• 단순히 Setter 를 호출 하지 않고 클래스내의 변수를 바꾸지 않기만 하면 되는 것인가?

Transparency

• 시스템이 변화 후에도 이전 External 인터페이스를 호출 할 수 있으면 transparent한 것임.
• 또는 내부 behavior가 변경되는 동안에도 가능한 External 인터페이스를 사용 할 수 있어야 함.

Intentionality

• 코드 내의 manifest, localized 는 디자이너의 의도된 영역임
• Traceablility, validation, maintainability 등을 지원.

Design Pattern

• 컨텍스트 기반의 문제 해결책
  • 특정 컨텍스트 영역에 알려진 일반적인 다지인 문제에 특화된 클래스와 오브젝트간의 커뮤니케이션에 대한 디스크립션
  • 다자인 Knowledge 캡처링 수단임.
• 히스토리
  • 건설쪽 아키텍처에서 유래됨.

Mediator

• Object Behavioral 분류
• 오브젝트 Interact의 집합을 어떻게 Encapsulate할 것인가가 관건
  • 오브젝트간 커플링을 줄임
  • 재사용성을 권장
  • Intentionality 향상
  • Mediator 클래스에 유사 행동집합(Collective behavior)을 추상화 시킴.
• 응용처
  • 오브젝트 인터렉션이 매우 잘 정의 되어 있지만 복잡하게 사용 될때
  • 오브젝트 내에 Behavior를 임베딩 하는 것은 reusability를 줄일때.
  • 관련된 컴포넌트들 사이의 인터렉션을 동적으로 선택하고 싶을때.
• 

     

  

• Colleague간에 통신이 없음. Mediator를 통한 Communication만 존재.
• Participants
  • Mediator
    • Collaboration 인터페이스를 정의함.
  • ConcreteMediator
    • Colleague 클래스 간에 디펜던시를 정의함.
    • Colleague의 명세를 알고 있음
  • Colleague
    • Mediator는 알고 있지만 다른 Colleague를 알지 못함.
  • Collaborations
    • Colleague는 Mediator와 통신함.
    • Mediator는 request를 route하는 역할만 진행
• Colleague간 Decouple, 커플링이 없으므로 Colleague의 재사용성 확보
• 프로토콜의 Simplify, Colleague와 Mediator간의 통신만 존재
• Intentionality
  • Collaboration이 Maintenance을 목적으로 한다면 Mediator만 고치면 됨
• Collaboration을 커스터마이징 할때 Mediator에 서브클래싱은 제한적임.
• 구현 이슈
  • 만약 Colleague가 하나의 Mediator와만 통신을 한다면 추상 Mediator 클래스는 필요 없을 것임.
  • Mediator는 Observer로 구현 가능함
  • Colleague는 스스로를 Mediator의 파라미터로 전달 할 수 있기 때문에 이를 통해서 Mediator는 이벤트의 근원지를 추적 할 수 있음

     

Creational Patterns

• Abstract Factory
  • 구체 클래스에 대한 명세 없이 object 패밀리를 명세 할 수 있음
    • UI 툴킷과 같은 경우 매우 다양한 Look and feel 클래스들을 가지고 있음
    • 어플리케이션은 스스로 look and feel에 대해서 모름
  • 프로덕트 오브젝트 패밀리들을 수정 할 수 있음
• Builder
  • 복잡한 오브젝트의 생성을 분리해냄
  • 생성될 오브젝트를 어떻게 구성 할 것인가를 수정할 수 있음.
• Factory Methods
  • 서브클래스는 어떤 클래스를 Initiate 할 것인지 결정 할 수 있음.
  • 프레임워크는 매우 드물게 생성을 요청하기에 명세된 생성은 구체 Factory 클래스에서 이루짐.
• Prototype
  • 오브젝트 생성을 가이드 하기 위해서 클래스보다는 프로토타이핑 인스턴스를 사용함
• Singleton
  • 생성되는 클래스 인스턴스가 하나라는 것을 보장함.

Observer Pattern

• 상태를 가지고 있는 하나의 오브젝트와 상태의 변화에 대한 정보에 관심이 있는 다수의 오브젝트의 1:n 관계를 제공함.
• Listener, Subscribe등으로도 알려져 있음.
• 시나리오
  • 데이터에 대한 업데이트와 프리젠테이션을 분리함.
  • 하나이상의 뷰어가 있는 경우 데이터가 State가 바뀌었을때 모든 뷰가 업데이트가 필요함.
• State와 Observer들간의 커플링을 줄임.
  • 묵시적 invocation을 제공
  • Consistency Maintenance
• 응용처
  • 두 개의 Participants로 구성
    • 하나가 다른 여러 개에 의존함.
    • Asymmetrical 정보 흐름
• 구조
• 
  • Subject

    Observer들의 track하고 있음. Attach/Detach 인터페이스를 통해서 옵저버들을 연결.

  • ConcreteSubject

    State를 저장하고 변화에 대한 Notification을 하는 실체

  • Observer
    • 변화를 인지해야 하는 오브젝트의 인터페이스
    • Subject에 등록 되어 있는 모든 Observer가 Update될 수 있도록 이에 대한 인터페이스를 제공함.
    • 이 인터페이스는 서브젝트에서 자신에게 등록되어 있는 모든 옵저버의 Update인터페이스를 호출 하도록 설계
  • ConcreteObserver
    • 변화에 대한 Notification을 반영하여 실제 Update를 구현하는 실체.
    • 업데이트는 필요한 시점에 호출 되는 것이므로 실제 이 통지에 대한 변화의 상태를 읽어야 하는데 이때 구체 Subject 클래스를 참조.
• Collaboration
  • Observer는 Subject에 등록함.
  • Subject는 등록된 Observer에 대해서 변화가 있을때 이를 통지함.
  • Observer는 명세된 State 데이터 를 서브젝트로부터 요청함.

    

• 결론
  • 서브젝트와 옵저버간에 커플링을 줄일 수 있음
    • 종종 서브젝트는 레이어드 아키텍처의 하위 단 레이어와 유사한 역할을 하게 됨
  • 브로드캐스트 또는 멀티 캐스트 방식의 커뮤니케이션을 지원.
• 구현 이슈
  • 어떻게 서브젝트는 옵저버를 Keep track 할 것인가.
    • 서브젝트내에 벡터나 해시 테이블 같은 것으로 구현
  • 하나 이상의 서브젝트에 대한 이슈
    • 서브젝트는 this 포인터를 오브젝트에 전달 함으로 어떤 서브젝트의 state가 변화 했는지를 캐치 하도록 하게 함
  • Notify에 대해서 누가 처리할 것인가
    • 서브젝트가 할 것인가 아니면 클라이언트가 할 것인가
  • 서브젝트가 삭제 되었을때 Referential integrity
  • 서브젝트가 notify를 시도하기 전에 셀프 consistent 확임
  • Push를 할것인가 Pull을 할 것인가.
    • 서브젝트가 통지 이후에 state 정보를 보낼 것인가 아니면 옵저버가 오청하는 형태로 가져 갈것인가
    • 좀 더 Complex state는 어떻게 처리 할 것인가?
  • ChangeManager
    • 하나의 변화가 다수의 서브젝트에 영향을 미칠 때 이를 관리
    • 서브젝트와 옵저버를 Map시켜둠
    • Strategy를 Update함
    • ChangeManger를 동적으로 변경 할 수 있도록 지원

    

Visitor Pattern

• 정의
  • 해당 데이터 구조체를 담고 있는 클래스에 변화 없이 복잡한 구조체 엘리먼트에 대한 다양한 동작을 수행해야 할때 쓰임.
• Motivation
  • 구조와 동작의 비독립적 컬렉션 또는 집합을 구성함
  • 두 가지 클래스가 있음.
    • 다른 형태의 구조적 엘리먼트들을 다루는 하나의 클래스
    • 다른 형태의 동작(Operation)을 다루는 또 다른 클래스
• 응용처
  • 복잡한 구조체와 관계된 몇몇 동작을 수행 해야 할때
  • Factoring out 동작들(Operations)에 의한 엘리먼트들의 간략화
  • 구조체는 별로 변화 하지 않지만 오퍼레이션은 자주 변할때
• 구조

  

  • Visitor
    • 각 ConcreteElement들에 대한 visit 오퍼레이션들을 정의 해둔 추상 클래스
  • ConcreteVistior
    • 각 ConcreteElement들에 대한 오퍼레이션의 구현
    • 로컬 state를 저장 하는 등의 행동을 취함.
  • Element
    • Visitor를 아규먼트로 받기 위해 인터페이스를 열어둔 추상 클래스 (Accept)
  • ConcreteElement
    • Accept에 대한 실제 구현
    • Accept는 Visitor에게 자신의 포인터를 전달 시킴.
  • ObjectStructure
    • 엘리먼트들을 가진 컬렉션 또는 Composite 클래스.
  • Client
    • 클라이언튼ㅌ ConcreteVisitor 오브젝트를 생성한 뒤에 ObjectStructure를 순회 하면 됨.
    • 순회 시에 ConcreteElement는 자신의 포인터를 아규먼트로 하여 visit 오퍼레이션을 순차적으로 호출함.
• 결론
  • 다른 타입에 대한 오퍼레이션의 구현이 하나로 수집된 장소에서 이루어짐
  • 새로운 동작을 추가하는 것이 바로 이루어짐
    • 클래스의 구조에 변화 없이 단순이 오퍼레이션을 visitor에서 확장하는 것으로 가능
  • 새로운 엘리먼트를 삽입하는 것은 어려움
  • Encapsulation 위반

Problems with Pattern

• 패턴은 상속과 오브젝트 Composition 이 두 가지로 구현된다.
  • Composition시 레퍼런스를 쓰면 Association으로 분류 될 것이고 컨테이닝하면 Aggregation으로 구성됨.
• 하지만 패턴은 복잡도를 높이는 성향이 있음
  • 엑스트라 오브젝트가 필요함, 예를 들면 Strategy, Decorator, Adapter, State, Bridge등
  • 엑스트라 레벨의 간접 참조가 필요

Object Schizophrenia

• 특정 variation을 반영 하기 위해서 같은 파트의 Functionality가 다른 오브젝트로 분리될 수 있음
• Delegation이 깨짐
• 추가적인 this와 같은 파라미터가 생김
• 랩핑 된 오브젝트가 사용하는 레퍼런스등에 의한 버그 생산 가능성이 존재.
• 해결책
  • SOP, Subject Oriented Programming
  • VOP, Variation Oriented Programming

       

Preplanning Problems

• 패턴은 현재 프로젝트에 적용 시키기 전에 충분히 이해하고 이를 계획성 있게 적용 해야함
  • 물론 리펙토링이 이를 많은 부분 완충 시켜 줄 수 있음
  • 패턴에 대한 리버스 엔지니어링이 필요 할 수 있음

Traceability problems

• 패턴을 적용한 프로그램은 자신이 사용한 패턴이 무엇인지 기술 할 필요가 없음
  • 따라서 이에 대한 추가적인 문서 작성은 반드시 필요함
• 코드 Fragment가 증가 할 가능성이 높음
  • 좀더 많은 클래스와 메서드들이 필요.

       

       

Introduction
애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸다. 익스트림 프로그래밍 (XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있다.

• Long term 계획보다 최소한의 계획을 가진 작은 increment 단위를 선택
• 타임박스로 불리는 작은 단위의 프레임을 반복함. 프레임의 시간 단위는 2~4주 정도 임.
• 각각의 iteration은 planning, analysis, design, coding, testing등의 완전한 소프트웨어 개발 사이클을 가짐
• Iteration 단위 하나는 프로덕트를 양산하는데 못 미치는 기능을 가진 산출물을 생성하지만 각각의 마지막 단계의 목표는 최소한의 버그와 함께 릴리즈 될 수 있다.
• Agile 메서드는 서면 작성된 문서를 넘어 face to face 커뮤니케이션을 강조한다.

Agile process

• 커스터머가 무엇을 필요로 하는지에 대한 description, 즉 시나리오 driven 개발 방식이다
• 짧은 기간 에서의 요구사항을 인지함.
• 소프트웨어 개발은 반복적인 컨스트럭션 액티비티를 매우 강조함.
• 다수의 소프트웨어 increment를 델리버함.
• 변화가 있을 때 적응 하기 쉬움.

Extreme Programming

• 가장 널리 agile 프로세스로 사용됨, 켄트 벡에 의해서 제시 되었음.
• XP Planning
  • 유저 시나리오를 만드는 것 부터 시작함
  • Agile 팀은 각각의 스토리를 평가하고 cost를 부가함.
  • 각각의 스토리는 델리버리가 가능한 increment 단위로 그릅화 됨
  • 델리버리 날짜를 commitment함
  • 처음 increment 후 project velocity는 순차적인 다른 increment 델리버리 일정을 정의하는데 도움을 줌.
• XP Design
  • KIS principle을 따름
  • CRC 카드 사용을 장려함
  • 어려운 문제를 위해서 Spike solution을 만들 것을 장려함, 일종의 프로토타입
  • 리팩토링을 장려함, 내부적인 프로그램 설계에 있어서 반복적인 정제 작업
• XP Coding
  • 코딩을 시작하기 전에 유닛 테스트를 생성 하는 것을 추천함
  • 페어 프로그래밍을 추천
• XP Testing
  • 모든 유닛 테스트는 매일 실행
  • 테스트는 커스터머에 의해 정의 되며 커서터머의 functionality를 평가하기 위해 사용됨.
  • 

ASD, Adaptive Software Development

• 구분되는 feature
  • 미션 driven planning
  • 컴포넌트 기반에 포커스
  • Time boxing을 사용함
  • 리스크를 명시적으로 고려함.
  • 요구사항 수집을 위한 협동을 강조함
  • 프로세스 도처에 learning을 강조함.
  • 

Scrum

• 30일 정도의 단위로 동작 가능한 제품을 제공하는 스프린트를 중심으로한 개발 프로세스
• 매일 정해진 시간에 정해진 자오셍서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론
• 구별되는 특징
  • Packet단위로 개발 일이 파티션 됨
  • 제품이 생산되는 시점 부터 테스팅과 문서의 작성읜 계속 진행됨
  • 스프린트 내에서 현재 요구사항의 백로그로부터 일이 전개 됨
  • 미팅은 매우 짧고 가끔 의장도 없음.
  • 할당된 타임 박스 마다 커스터머에게 데모를 델리버리 함.

FDD, Feature Driven Development

• feature마다 2주 간격으로 반복 개발을 실시한다. UML을 이용한 설계 기법과도 밀접한 관련이 있다.
• 
• 구별되는 특징
  • 2주나 그 이하에 구현이 가능한 커스터머의 요구 기능을 feature라고 부름.
  • Feature를 정의 하는 것을 강조함.
    • <action> the <result> <by | for | of | to> a(n) <object>
  • Feature 리스트가 장성되고 feature에 의한 plan이 실행 된다.
  • 디자인과 컨스트럭션이 융합된 형태.