Architectual patterns

1. Pipe and filter architecture

• 이전 단계의 결과물이 다음 단계의 입력으로 들어가 처리되는 형태일 때 많이 사용
• batch sequential model
• interactive system에 적합하지 않음
• 장점 : 병렬적으로(concurrent) 여러 가지가 동시에 실행될 수 있다 / workflow와 비슷하게 나타낼 수 있다
• 단점 : 재사용이 불가능하다(이전 단계의 출력이 어떤 format으로 처리되어 다음단계로 넘어오는지 알아야 하기에 이것과 관련된 약속이 정의되어 있어야 함. 따라서 특정 단계에 있는 걸 떼서 다른 애로 대체하기 힘듦. 데이터 format 맞춰줘야해서)

2. Model-View-Controller(MVC) architecture

• Model : 핵심 로직 (data 관리, 작동과 관련)
• View : 사용자에게 데이터가 어떻게 보여지느냐
• Controller : View와 Model을 이어주는 역할 (interaction 수행해준다 & 이러한 interaction을 View,Modle에게 넘겨줌)
• 데이터를 표현하는 방법이 다양할 때 주로 사용한다 (ex)웹 브라우저로 홈페이지 접속할수도, 이화앱으로도 접속할수도,..)
• 장점 :독립적으로 동작한다(현재chrome에서 동작하는데 edge에서도 동작하게끔 하고 싶으면 model과 상관없이 구현 가능)
• 단점 : 데이터 모델과의 상호작용이 간단하면 controller 안 거치고 model-view가 바로 처리 되는 게 나을 수도 있다

---

Control styles

• Centralised control : main함수에서 호출. 하나가 전체를 책임 진다

       Call-return model : 깊이우선탐색과 같이 진행됨 (main-> routine1-> routine 1.1-> routine2-> routine3-> routine3.3)

       Manager model :main 함수 같은 걸 하는 시스템이 있는데 순서대로가 아니라 "동시에" 처리한다

• Event-based control : 한 곳이 아니라 각각 알아서 제어함 

       Broadcast model : 이벤트가 발생하면 모든 sub-system에게 알려준다. 자기 이벤트가 아니면 듣고 아무 일도 안하고                                         그냥 내 event 발생할 때까지 기다림. 내 event면 그걸 처리한다.

       interrupt-driven model: real-time system에서 사용됨 (cf) interrupt vector : interrupt별로 어떤 interrupt handler 호출해                                                                                                  야하는지 정의되어 있는 table)