[소프트웨어공학] 5. Architecture Design

 

 Design Process

 

1. 설계 입력: 플랫폼 정보, 요구사항, 데이터 설명

2. 설계 활동: 아키텍처 설계 -> 인터페이스 설계 -> 컴포넌트 설계 => 데이터베이스 설계(<= 아키텍처 설계)

3. 설계 결과: 시스템 아키텍처, 데이터베이스 명세, 인터페이스 명세, 컴포넌트 명세 

 

 - 아키텍처 설계: 시스템의 전체 구조, 주요 구성 요소(하위 시스템, 모듈), 이들의 관계 및 배포 방법을 식별

 - 인터페이스 설계: 시스템 컴포넌트 사이의 인터페이스 정의

 - 컴포넌트 설계: 각 시스템 구성 요소의 작동 방식 설계

 - 데이터베이스 설계: 시스템 데이터 구조를 설계하고, 데이터베이스에서 어떻게 표현할지 결정

 

 

 Software architecture

 

 - 아키텍처 설계: 시스템을 구성하는 하위 시스템과 하위 시스템 제어 및 통신을 위한 프레임워크 식별하는 설계 프로세스

 - 설계 프로세스의 결과는 소프트웨어 아키텍처에 대한 설명.

 - 소프트웨어 아키텍처는 소프트웨어 구성요소와 그들이 지닌 특성 중 외부에 드러나는 특성, 그리고 구성요소들의 관계를 표현하는 시스템의 구조나 구조체

 

+ 아키텍처는 설계시 응집력 높고, 결합력 낮게 설계해야함

 

 

 명백한 아키텍처 장점

 

- 이해관계자 커뮤니케이션: 아키텍처는 시스템 이해관계자 간 논의 주제로 사용

- 시스템 분석: 시스템이 비기능 요구사항 충족할 수 있는지 분석 가능

- 대규모 재사용: 아키텍처는 다양한 시스템에서 재사용 가능. 제품 라인 아키텍처 개발 가능. 소프트웨어 제품 라인이란 특정 시장 영역이나 임무에 특화된 요구 만족시키면서 공통 기능들을 공유하는 소프트웨어 집합 시스템 모음 

 

 

 아키텍처 패턴

 

- 아키텍처 요소와 요소 간의 관계를 패턴으로 표현

 

※ 어느 상황에서 어떤 아키텍처를 사용하면 좋을지. 각 아키텍처의 장단점이 중요

 

(1) 계층형 아키텍처

 - 서브 시스템의 인터페이스를 모델링하는데 사용

 - 시스템을 일련의 서비스를 제공하는 계층 집합으로 구성

 - 다양한 계층에서 서브 시스템의 증분 개발 지원. 계층 인터페이스가 변경되면 인접한 계층만 영향 받음

=> 기존 시스템 위에 새로운 설비를 구축할 때 사용

 

장점: 인터페이스가 유지되는 동안은 전체 계층 교체 가능. 중복 기능을 각 계층에 제공하여 시스템의 신뢰성 높일 수 있음.

단점: 계층 간 명확한 분리가 어려움. 상위 계층이 바로 아래 계층 통하지 않고 하위 계층과 직접 상호 작용 해야할 수 있음. 서비스 요청이 각 계층에서 처리될 때, 계층마다 해석이 달라 성능 문제가 발생할 수도 있음. 

 

ex) 도서관 관리 시스템. 책 대출, 반납, 검색 기능. DB 접근, 비즈니스 로직, 프레젠테이션 로직 분리

 

 

(2) 레포지토리 아키텍처

 - 서브 시스템들은 데이터를 교환해야하는데, 데이터 교환은 "공유 데이터", "각각의 서브 시스템"으로 수행

   공유 데이터: 중앙 데이터베이스 또는 저장소에 보관. 모든 서브 시스템에서 접근 가능

   각각의 서브 시스템: 자체 데이터베이스 유지 관리하고, 다른 서브 시스템에 명시적으로 데이터 전달

  - 많은 양의 데이터를 공유해야하는 경우, 공유를 위한 저장소 모델이 일반적으로 사용. 효율적인 데이터 공유 방법

=> 장기간 저장해야하는 대량의 정보가 생성되는 시스템이 있을 때 사용

 

장점: 컴포넌트가 독립적일 수 있음. 각 컴포넌트는 다른 컴포넌트의 존재를 알 필요 없음. 한 컴포넌트의 변경 사항을 모든 컴포넌트에 전파할 수 있음. 모든 데이터가 한 곳에 있어 일관적으로 관리할 수 있음

단점: 저장소에 실패가 발생하면 전체 시스템에 영향 미침. 저장소를 통해 모든 커뮤니케이션 구성하는 것은 비효율적. 여러 컴퓨터에 저장소 배포하는 것은 어려움

ex. 소규모 프로젝트 관리 시스템. 사용자가 프로젝트 관련 데이터 생성, 수정, 삭제 가능.

 

 

(3) 클라이언트-서버 아키텍처

 - 데이터 및 처리가 다양한 컴포넌트에 분산되는 방식을 보여주는 분산 시스템 모델

 - 특정 서비스 제공하는 독립 실행형 서버 집합. 이 서비스를 호출하는 클라이언트 집합

 - 네트워크 통해 클라이언트가 서버에 접근

=> 공유 데이터베이스의 데이터를 다양한 위치에서 접근해야할 때

 

장점: 서버가 네트워크를 통해 분산될 수 있음. 일반 기능은 모든 클라이언트에서 사용될 수 있고, 모든 서비스에서 구현될 필요가 없음

단점: 서비스 거부 공격이나 서버 장애에 취약. 네트워크에 따라 성능이 달라져 예측이 어려움. 다른 조직에서 서버 소유하면 관리 문제 발생

 

ex. 채팅 어플리케이션

 

 

(4) 파이프-필터 아키텍처

 - 기능 변환은 입력을 처리하여 출력 생성

 - 변환이 순차적인 경우, 데이터 처리 시스템에서 광범위하게 사용되는 배치 순차 모델

 - 대화식 시스템에는 적합하지 않음

=> 입력이 출력을 생성하기 위해 별도의 단계에서 처리되는 데이터 처리 애플리케이션에서 사용

 

장점: 워크플로 스타일은 많은 비즈니스 프로세스 구조와 일치. 순차 또는 동시 시스템으로 구현할 수 있음

단점: 데이터 전송 포맷은 변환을 위한 통신 사이에 합의되어야 함. 출력 생성 시 합의된 형식으로 출력 -> 시스템 오베헤드 증가시키고, 호환되지 않는 데이터 구조를 사용하는 기능 변환에는 재사용이 불가능함. 

 

ex. 파일 내 텍스트 데이터 처리. 파일 업로드 후 단어 수 계산 -> 특정 단어 제거 -> 파일 저장

 

 

(5) MVC 아키텍처

 - 프레젠테이션과 상호 작용은 시스템 데이터와 분리

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

  * 모델: 시스템 데이터 및 해당 데이터와 관련된 작업 관리

  * 뷰: 데이터가 사용자에게 표시되는 방식 정의하고 관리

  * 컨트롤러: 사용된 상호 작용을 관리하고 상호 작용을 뷰 및 모델 컴포넌트에 전달

=> 데이터를 보고 상호 작용하는 방법이 여러가지일 때 사용. 데이터의 상호 작용 및 표시에 대한 향후 요구사항을 알 수 없을 때 사용(pc 화면에 띄워지는 것을 모바일 화면에도 연결시키고자 할 때..)

 

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

단점: 데이터 모델과 상호 작용이 단순한 경우에는 추가되는 코드 및 코드 복잡성이 포함

 

ex) 쇼핑몰 웹 애플리케이션. 상품 검색, 장바구니 추가, 결제 진행

ex) 온라인 학습 플랫폼. 강의 검색, 등록. 강의 업로드, 관리. 실시간 채팅, 퀴즈, 성적 관리. 대규모 사용자 수 지원하며 확장 가능. 

 

 

 Control styles

 

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

 -> 콜-리턴 모델, 관리자 모델

 

- 이벤트 기반 제어: 각 서브 시스템들은 다른 서브 시스템이나 시스템 환경으로부터 외부에서 생성된 이벤트에 응답

 -> 브로드캐스트 모델, 인터럽드 기반 모델

 

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

 

(2) 관리자 모델: 동시 시스템에 적용 가능. 하나의 시스템 컴포넌트가 다른 시스템 프로세스의 시작, 중지 및 조정을 제어

 

(3) 브로드캐스트 모델: 이벤트가 모든 서브 시스템에 전달. 원하지 않아도 전달됨

 

(4) 인터럽트 기반 모델: 인터럽트 감지되면 처리를 위해 다른 컴포넌트로 전달되는 실시간 시스템에서 사용. 나한테 적용되는 인터럽트만 받으면 됨