[소프트웨어공학] 소프트웨어 아키텍처 패턴

* 소프트웨어 아키텍처 

= 소프트웨어의 내부적인 질을 높이기 위해 고려되는 소프트웨어의 구조

 

* 소프트웨어 아키텍처 패턴

= 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대해 일반화된 솔루션을 제공하는 것

= 세부 구현이 아닌 소프트웨어의 뼈대나 전체적인 고수준의 기반을 담당

 

* 아키텍처 스타일 = 아키텍처 유형 (시스템 분할, 전체 흐름 제어, 오류 처리 방침, 서브시스템 간 통신 프로토콜)

 

 

* 시스템 타입

시스템 타입은 아키텍처 스타일을 결정할 때 영향을 준다

* 대화형 시스템 interactive

- 가장 보편적 시스템 유형

- 사용자-사용자 인터렉션

- 유스케이스 단위로 컴포넌트 설계

- 온라인 쇼핑몰, 모바일 앱

 

* 이벤트 중심 event driven

- 특정 이벤트 발생시 시스템 동작 

- 상태 다이어그램으로 모델링, 상태 단위로 아키텍처 구성 요소 설계

 

* 변환 transformational 

- 입력 데이터를 다른 형태로 변환해서 출력 (과학이나 엔지니어링 계산, 데이터 마이닝, 워크플로 관리)

- 변환 과정이 중요한 요소가 됨 (컴파일러, 원시 코드를 실행 가능한 코드로 변환)

( text to video generation)

 

* 객체 영속 object persistence

- 저장 미디어를 숨기고 db나 fs에 객체를 저장 (데이터베이스)

 

 

* 아키텍처 패턴

* 클라이언트 서버형

네트워크 상 모든 개체는 클라이언트 또는 서버

서버 = 고성능으로 자원 관리, 클라이언트가 요청하는 기능과 자원을 제공, 여러 클라이언트에 대해 동시에 서비스 가능

클라이언트 = 단일 유저 시스템, 자원 사용을 위해 서버에 접속, 클라이언트는 서버에 접속하기 위한 목적의 애플리케이션

 

클라이언트는 서버 자원인 데이터, cpu, 프린터 등을 얻기 위해 직접 통신하지 않고 서버를 통해 간접적으로만 통신한다

서버와 클라이언트는 물리적으로 다른 장소에 존재하고 있다

 

클라이언트-서버에서 파생된 유형이 존재한다

- 3계층 = 프레젠테이션 ui + 애플리케이션 처리 logic + 데이터 관리 data

- 무거운 클라이언트 = 대부분의 처리를 클라이언트에서, 서버는 제공처럼 일부 기능만

- 가벼운 클라이언트 = 대부분의 처리를 서버에서, 클라이언트는 ui 프레젠테이션만 

 

장점

- 데이터 집중화 : 모든 데이터를 서버에 모아서 구성과 관리를 단순화하니 백업과 변경이 쉽다

- 보안 : 인증된 클라이언트만 접근할 수 있고 클라이언트의 요청과 모니터링을 기록할 수 있다

 

단점 

- 병목 : 클라이언트 증가로 서버 통신 부하 증가, 느려짐

- 비용 : 설치 관리 비용이 높음

- 비강인성 : 서버 고장시 클라이언트 단독으로는 작동 불가능

 

* 계층형

- sw 기능을 상호작용하는 수직의 여러 레이어로 분할

- 각 레이어 사이는 메시지를 교환할 수 있지만 바로 위 또는 바로 아래로 제한

- 복잡한 시스템을 추상화 레벨에 따라 나누고 층으로 구성

- 추상화 뷰 : 각 층의 역할과 책임 관계 이해하기 좋다

- 캡슐화 , 응집 , 결합 : 각 층 안에 자세한 데이터나 메서드, 리소스, 구현이 캡슐화되어 각 층의 응집은 높고 층과 층 사이 결합은 낮다

- 재사용성 : 각 층의 의존도가 적어서 쉽게 다른 모듈로 교환할 수 있고 독립성은 높으니 다른 시스템에 재사용이 가능하다

 

- 이웃 층과의 커뮤니케이션이 제한적이고 결합력이 낮아서 계층으로 구성하기 쉽지 않다

 

** 캡슐화와 추상화

- 추상화  abstraction  복잡한 시스템에 서 필요한 부분만을 표현하 여 중요한 정보를 강조하고 불필요한 세부 사항을 숨기 는 것

- 캡슐화  encapsulation  객체의 데이터(속 성)와 메서드(기능)를 하나 의 단위로 묶고, 외부에서 직접 접근하지 못하게 하여 데이터를 보호하는 것

 

* 이벤트 기반 

- 프로그램에서 감지되고 처리될 수 있는 사건 중심 시스템

- 이벤트 스트림을 생성하는 생산자 (스위치, 온도 센서)

- 이벤트 수신을 대기하는 소비자 (팬과 콘덴서 제어부)

- 이벤트는 실시간으로 전달되기 때문에 발생 즉시 소비자가 이벤트에 응답해야 한다

- 이벤트 생산자와 이벤트 소비자는 서로 분리되어 생산자는 수신 대기 중인 이벤트 소비자를 알 수 없다

- 각 이벤트 소비자에게는 모든 이벤트가 표시되고 소비자들은 서로 독립적으로 처리한다

 

- 상태 기반 처리이므로 발생 이벤트 종류와 현재 시스템 상태에 따라 다른 처리를 수행하게 된다

 

- 캡슐화, 응집 : 이벤트 생산자와 소비자의 분리로 캡슐화된다

- 확장성 : 소비자는 각각 독립적이며 새 소비자를 쉽게 추가할 수 있다

- 이벤트 도착 즉시 소비자가 이벤트에 응답 가능하다

- 하위 시스템에서 이벤트 스트림을 독립적으로 확인할 수 있다

 

- 복잡성 : 상태에 따라 복잡하고 정교한 제어가 필요하다

- 테스팅 : 허용되지 않은 이벤트에 대한 적절한 오류 제어 필요

 

** 이벤트와 상태

- 이벤트: 시스템 내에서 발생한 특정 사건이나 변화의 순간을 의미하며, 주로 상태 전환을 촉발한다

- 상태: 현재 시스템의 상황을 나타내는 값이나 조건을 의미하며, 시간에 따라 변경될 수 있다

 

 

* MVC = model view controller 

- 사용자 인터페이스로부터 비즈니스 로직과 데이터를 분리한 시스템

- 시각적 요소와 로직을 서로 영향 없이 쉽게 수정 가능하다

- 각 담당  계층 (구성 요소)의 응집력은 높아진다

- 여러 다른 ui를 만들고 그 간의 결합을 낮출 수 있다

 

- model 데이터 상태 변화 시 controller 와 view에 통보한다

view는 최신 결과를 업데이트해서 보여주고

controller는 변화에 따라 적용 가능한 명령을 수행할 수 있다

 

- view 모델로부터 정보를 가져와 사용자가 볼 결과물, 상호작용할 화면을 구성한다

 

- controller 모델에 명령을 보내서 모델 상태를 변경한다

 

- 각 컴포넌트가 느슨하게 결합하고 있어서 다른 부분에 영향을 주지 않고 수정할 수 있고 확장도 가능하다

- 한 모델을 위해 다수의 다른 뷰를 제공하는 것이 쉽다

- 비동기로 애프리케이션 작동이 빠르다

 

- 컴포넌트 분리로 복잡도 향상

- 뷰에서 데이터에 접근하는 것이 비효율적

- 각 컴포넌트 구현을 위한 여러 기술 이해 필수

** 비즈니스 로직과 테크 로직

비즈니스 로직은 시스템이 수행할 핵심 업무 규칙을 정의하고 실행해서 유저의 니즈를 충족하고 비즈니스 골을 달성한다

테크 로직은 시스템의 기술적인 기능 수행에 목적을 두고 비즈니스 로직은 핵심 기능 관련 규칙 정의에 목적을 둔다

 

 

* 파이프 필터

- 데이터 스트림을 처리하기 위해 자주 사용되는 유형

- 여러 단계의 필터와 필터를 연결하는 파이프로 구성

- 공유된 자료가 중요한 시스템에서 주로 채택

 

- 데이터는 각 필터에 의해 순차적으로 처리되고 각 필터에서 데이터 일부를 가공하거나 변형한다

- 변형 버전은 배치 처리 파이프 필터 :: 배치 순차 처리를 다음 단계 시작 전에 각 단계 완료해야하고 처리 데이터를 병렬로 필터링한다

 

- 단순성 : 시스템을 쉽게 구조화 가능

- 재사용 : 모듈화, 타 프로그램에서 필터 재사용 및 교체 가능

- 병렬성 : 병렬 처리로 구현 가능

 

- 시간 공간 낭비 가능 : 여러 형태로 저장해야하고, 필터에 맞게 입출력 형식을 변환해야한다

- 오류 조건 처리 어려움 : 다음 단계에 오류가 영향 줄 수 있으니 별도 처리 필요

 

- 공유 데이터 저장소와 공유 데이터 접근자

- 각 접근자는 서로에 대해 모르고 직접 통신은 불가능하다. 공유 데이터에 대한 업데이트로 간접적 통신을 수행한다.

- 접근자는 공유 데이터를 추가, 삭제, 수정할 수 있다

 

- 블랙보드, 레포지토리 

 

- 접근자 간 영향을 주지 않는 낮은 결합

- 접근자 각각 수정과 확장이 쉬운 확장성

 

- 단일 장애 지점 Single point of failure : 공유 데이터 장애로 전체가 장애 유발

 

 

 

* peer to peer 

- 각 컴포넌트 peer (모든 엔드 시스템)는 동등한 기능과 책임을 가지고 있어 클라이언트와 서버 역할을 동시에 수행할 수 있고 어느 쪽이든 커뮤니케이션을 시작할 수 있다

- 각 peer 는 데이터와 저장 공간, 처리 능력 등의 자원을 제공하면서도 소비하는 양방향적 역할을 모두 수행한다

 

- p2p file sharing ... webhard 등

 

- 전담 애플리케이션이나 서버가 없다

- 컴포넌트 고장 있더라도 전체 시스템은 작동 가능해서 규모 확장성과 신뢰성이 개선되었다고 할 수 있다

 

- 보안에 취약하고 중앙 제어가 불가능하며 공유 자원으로 인해 성능 악화 가능성이 있다