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가 증가 할 가능성이 높음
  • 좀더 많은 클래스와 메서드들이 필요.

       

       

Tomasulo Data Structure

Tomasulo-Style Register Renaming

• Names
  • Architectural registers
• Locations
  • 레지스터 location은 레지스터 파일과 reservation station 두 곳.
  • Value는 두 곳 모두 있을 수 있음.
    • WAR hazard를 제거하는 카피들.
  • Value 기반 또는 copy 기반 renaming이라고 부름.
• Location은 내부적으로 tag들에 의해 참조 됨.
  • 레지스터 테이블에서 tag로 이름을 변환함.
  • Tag
    • 0인 경우 레지스터 파일 안을 의미하고
    • 0이 아닌 경우 할당된 RS#Tag 안을 의미한다.
  • CDB는 브로드캐스트할때 Tag와 value를 붙여서 한다.
    • 그래서 인스터럭션은 자기들이 찾는 어떤 값이 뜨는 지 알 수 있다.
• Allocation scheme

  

  • RS에 해당 Tag가 비어 있으면 할당 하는데
    • 이때 Functional Unit의 오퍼렌드에 해당 하는 Value를 실제 레지스터로부터 복사하여 값을 넣어 둔다.
      • 값을 RS에 카피하는 것이 이 알고리즘에서는 큰 의미가 있는 것으로 보임.
      • 복사를 통해서 해당 물리 레지스터를 자유롭게 만들어 줌.
      • 인스트럭션이 이슈 되기 전에 이미 해당 레지스터들이 카피 되었기 때문에 anti-dependency와 output-dependency가 해결 될 수 있음.
      • Mapping을 통한 rename이 내가 생각 했던 false 디펜던시들의 레지스터 이름을 교환 하는 것이 아닌 것으로 보임. 실제로 매핑 테이블에는 RS Tag를 넣는데 이 매핑 정보는 true dependency가 존재 할 때만 assign되므로 단순히 인스트럭션의 레지스터 이름들을 각각 변경 한다기 보다는 다음 인스트럭션에서 해당 인스트럭션이 복사 되지 않고 (not ready) 기다려야 하는지에 대한 이름을 통해서 알고(value-based) 실제 인스트럭션이 execution 될 때는 오퍼렌드들이 reservation station에 존재 하기 때문에 레지스터 이름이 V1,V2,T1,T2를 참조하도록 Renaming 했다고 명명 하는 것으로 보여짐.
      • Hennessy가 virtual register들은 실제 물리 레지스터보다 많을 수 있다는 것이 복사 의해서 RS와 실제 물리 레지스터들에 값들이 존재 하는 것으로 볼 수 있음
      • 개인적으로는 인스트럭션마다 4개의 캐시 레지스터를 할 당 할 수 있는 유한 원소의 테이블을 가지고 있는 것으로 Replace victim시 stall을 수행 하고 할당하는 동작 전체가 캐시와 거의 유사하게 보임, 그다지 매력적인 알고리즘으로 보이지는 않지만, 사이클당 인스트럭션의 dependency를 specific하게 판단 할 수 있게 하는데 의의가 있는 것으로 보여짐.
    • 만약에 실제 레지스터가 다른 인스트럭션에 의해 수행 되는 것 때문에 디펜던시가 존재 한다면 태그 값을 카피 하여 넣어 둔다.

Tomasulo's algorithms example

• 기본적인 동작
  • DS는 Stall의 경우를 제외 하고는 들어온 순차적으로 수행(in-order)
  • IS 전에서는 Register Status를 체크하고 Dependency가 없는 경우만 IS에 진입 할 수 있도록 함.
  • EX, IS가 이슈 되고 나면 다음 단계에서는 반드시 실행.
  • WB에서는 Register Status와 RS를 Release해 줌.
• 1 cycle

  

  • 순차적 수행으로 디스패치를 수행, 첫 번째 인스트럭션의 RS를 할당하고 Write의 f0fmf 위한Register status를 할당.
• 2 cycle

  

  • 두번째 사이클에서 Busy인 ldf를 이슈함. Mulf를 위한 RS를 할당하고 fo의 dependency를 copy함
  • Write 대상을 위해 f4에 대한 register status를 할당.
• 3 cycle

  

  • IS된 ldf는 execution 사이클
  • mulf는 확인결과 해당 오퍼랜드1의 레지스터 f0가 release 되지 않았으므로 이슈 시키지 않고 스킵 함.
  • 디스패치에서는 다음 인스트럭션인 stf를 가져와서 RS에 할당. 오버랜드1을 Register Status에서 check해보니 할당된 RS가 존재 하므로 Dependency를 T1을 통해 복사.

       

• 4 cycle

  

  • WB사이클을 마친 ldf는 CDB를 통해서 해당 f0와 함께 tag RS#2를 브로드캐스트
  • CDB의 브로드캐스트에 의해 Register Status의 f0는 해제 되고 또한 RS의 RS#2 값을 가진 RS들을 룩업, CDB의 Value에 해당 값이 존재 하므로 RS#4의 T1을 제거하고 CDB의 Value값을 V1으로 복사 한 뒤 사이클 수행
  • 다음 인스트럭션 add에 대하여 오퍼랜드 레지스터 복사, 타겟 레지스터를 Register Status에서 확인 후 할당된 RS로 교체
• 5 cycle

  

  • Execution단계에서는 mulf를 수행
  • 이슈단계에서 stf를 확인 해보면 stf의 오퍼랜드1이 RS#4와 dependency가 존재하기 때문에 아직 이슈잉 하지 않고 스킵.
  • 다음 인스트럭션인 add를 확인 결과 dependency가 없기에 add를 이슈함.
  • 다음 ldf의 타겟 레지스터를 확인, f0가 이전에 릴리즈되어 free상태이므로 register status를 RS 태그로 할당하고 RS는 해당 오퍼랜드 레지스터를 복사 하면서 할당.
• 6 cycle

  

  • mulf는 수행 사이클이 3이라고 가정 되었기 때문에 execution 사이클에 대기
  • sft 의 오퍼랜드1이 RS#4와 디펜던시가 존재 하므로 이슈 하지 않음.
  • Add는 이슈가 되었으므로 해당 EX 사이클 수행.
  • ldf 의 오퍼랜드를 확인, 오퍼랜드2가 디펜던시가 존재 하므로 이슈 하지 않음.
  • 다음 인스트럭션인 mulf를 수행하기 위해 register status를 확인
    • f4에 RS#4가 할당 되어 있지만 이는 해당 RS가 FP로 동일하고 먼저 이슈가 된 것이 RS에 의해서 확인이 가능 하기 때문에 반드시 앞에서 수행된 RS가 먼저 WB을 할 것이 확실해짐으로 f4가 사용이 가능함.
    • 이러한 이유로 WAW에 의한 스톨이 없음.
    • f4에 RS태그로 값을 할당하고 RS 할당.
• 7 cycle

  

  • mulf는 아직 사이클 소모가 완전히 되지 않았음,
  • stf를 확인, stf는 오퍼랜드2의 값이 클리어 되지 않았으므로 이슈하지 않음.
  • add인스트럭션은 EX를 마쳤으므로 WB수행.
    • WB후 해당 타겟 레지스터는 완료가 되었으므로 CDB에 의해서 브로드캐스트
    • 브로드캐스트 받은 Register Status에 해당 태그가 존재하는 레지스터를 릴리즈.
    • 브로드 캐스트 받은 RS는 해당 태그의 T값이 존재 하는지 룩업 후, T를 클리어하면서 해당 V값에 CDB의 V값을 복사
  • ldf에는 방금 디펜던시가 존재하던 레지스터가 클리어 되었으므로 이슈가 가능.
    • R1의 Antidependency가 없이 수행 된것과 결과가 동일.
  • stf를 디스패치 하기 위해 확인, sft의 RS가 모두 Full이므로 디스패치가 불가능(인스트럭션 버퍼가 꽉 찾으므로) 해당 인스트럭션은 stall됨.

       

• 8 cycle

  

  • mulf가 EX 사이클을 마쳤으므로 WB수행
    • WB후 CDB에 의해서 RS#4태그가 브로드캐스트
    • Register Status는 두번째 mulf때문에 클리어 할 것이 없음.
    • RS 해당 태그 엔트리는 FREE시키고 해당 태그를 가지고 있는 T 오퍼랜드는 클리어 후 해당 값을 V레지스터로 복사.
• 9 cycle

  

  • 이슈된 stf의 EX 사이클 소모
  • EX가 끝난 ldf의 WB
    • CDB를 통해서 RS#2 태그와 값을 브로드캐스트
    • Register Status에서 해당 값 클리어
    • RS에 해당 값을 클리어하고 CDB의 값을 V에 복사
    • 해당 태그의 RS의 엔트리는 Free
  • mulf는 앞에서 수행 되었던 클리어작업에 의해서 이슈가 가능해짐.
• 10 cycle

  

  • 이슈와 EX가 끝난 stf와 mulf를 차례로 수행.

RS Implementation

• Tag/CDB 파트는 각각 인스트럭션 윈도와 스케줄러라는 이름으로 불림.
• Wakeup
  • CDB 태그 브로드캐스트와 매칭 작업을 의미함.
  • 긴 버스와 함께 많은 비교 작업 수행.
• Select
  • 이번 사이클을 이슈하기 위한 인스트럭션을 수행 할 것을 선택하는 
  
  
  
  
  
  
  Example
  http://www.ecs.umass.edu/ece/koren/architecture/Tomasulo1/tomasulo_files/tomasulo.htm