<5> Architecture design 2

이 글은 기말고사가 2일하고 22시간 남은 학부생이 기말고사 암기를 위해 작성한 내용입니다... 내용은 지현박교수님의 강의자료를 참고하였음을 밝힙니다...........🎀

 

 

 

🎀 Pipe and filter architecture

각진 네모: input, 둥근 네모: process

 

: 입력이 관련 출력을 생성하기 위해 별도의 단계에서 처리되는 데이터 처리 어플리케이션(일괄처리, 트랙잭션 기반)에서 주로 사용됨.

• 입력을 처리하여 출력을 생성 -> 이전 단계의 출력을 입력으로
• UNIX 쉘과 같음
• 변형이 매우 일반적. 변환이 순차적인 경우 : batch sequential model(데이터 처리 시스템에서 광범위하게 사용됨)
• 대화식 시스템에서는 적합하지 않음.

장점 

1. 많은  비즈니스 프로세스의 구조와 일치
2. 순차 또는 동시 시스템으로 구현 가능

단점

1.  데이터 전송 포맷은 변환을 위한 통신 사이에 합의되어야 함.
2. 각 변환은 입력을 해석하여 처리한 후, 출력을 생성할 때 합의된 형식으로 출력 (포맷이 지정됨) → 시스템 오버헤드 증가, 호환되지 않는 데이터 구조를 사용하는 기능 변환에는 재사용이 어려움.

---

 

🎀 MVC(Model-View-Controller) Architecture

: 데이터를 보고 상호작용하는 방법이 여러가지인 경우 + 데이터의 상호작용 및 표시에 대한 향후의 요구사항을 알 수 없는 경우에 사용

 

* Seperates presentation and interaction from system data 

* 시스템은 서로 상호작용하는 3가지 논리적 컴포넌트로 구성됨

1. 모델 컴포넌트: 시스템 데이터 및 해당 데이터와 관련된 작업 관리 (내부로직, 데이터들)
2. 뷰 컴포넌트: 데이터가 사용자에게 표시되는 방식 정의 및 관리 (외부 sys와 상호작용하는. 외부로 보여지는 것)
3. 컨트롤러 컴포넌트: 사용된 상호작용(ex 키 누름, 마우스 클릭 등)을 관리, 상호작용을 뷰 및 모델에 전달(view와 model을 이어주는 역할)

 

장점

1. 데이터가 해당 표현과 독립적으로 변경되거나 그 반대로 변경될 수 있음.
2. 동일한 데이터를 다른 방식으로 표시할 수 있도록 지원.

단점

1. 데이터의 모델과 상호작용이 단순 -> 이 모델을 사용하면 추가되는 코드 및 코드 복잡성이 포함될 수 있음. (관련 view도 같이 수정해야 하는 오버헤드 존재)

 

---

 

프로그램을 어떤 식으로 제어할 것인가?

1. 중앙집중식 제어: 하나의 서브시스템이 다른 서브 시스템들을 시작/정지/제어하는 전반적 책임을 가짐

 

 

 

 1🎀 콜-리턴 모델 

  : 제어가 서브루틴 계층의 맨 위에서 시작해서 아래로 이동하는 하향식 서브루틴 모델. 순차시스템에 적용 가능

 

구조상으로는 tree, but sequential하게 진행 - Routine 1이 끝나야 Routine 2 호출

 

 

2🎀 관리자 모델

 : 동시에 여러 시스템 수행시, 하나의 시스템 컴포넌트가 다른 시스템 프로세스의 시작, 중지 및 조정을 제어함. 동시 시스템에 적용 가능. ex) 자동차-실시간sys

 

 

 

 

---

 

 

 

2. 이벤트 기반 제어: 각 서브시스템들을 다른 서브 시스템이나 시스템의 환경으로부터 외부에서 생성된 이벤트에 응답할 수 있음.

 

 1🎀 브로드캐스트 모델

  : 이벤트가 모든 서브 시스템으로 전달됨. ex) 외부의 network packet을 catch해서 동작하는 앱

전체 process에게 event 발생에 대해 알려줌.(통제x) / 이벤트 처리는 각 sub-sys가 진행

 

 

 

  2🎀 인터럽트 기반 모델

   : 인터럽트가 인터럽트 핸들러에 의해 감지 -> 처리를 위해 다른 컴포넌트로 전달되는 실시간 시스템에서 사용

 

인터럽트별로 어떤 핸들러로 처리돼야 하는지. 적절한 것 호출

 

 

 

---

🎀 SW 아키텍처 평가

• SW 아키텍처가 개발될 SW에 요구되는 품질 특성을 충족시킬 수 있는가를 아키텍처 수준에서 평가
  • 아키텍처가 완성되고 구현되기 전 SW 아키텍처와 요구사항 명세 이용하여 평가
• 평가 방법
  • Scenario based
  • Simulation based
  • Mathmatical model based
  • Experience based