<소프트웨어 설계> - (3) 애플리케이션 설계 ( SW아키텍처 )

[1. 소프트웨어 아키텍처]

1. 소프트웨어 아키텍처

- 소프트웨어의 골격이 되는 기본 구조

- 소프트웨어의 구성 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체

 

- 설계 원칙 : 소프트웨어 개발 시 적용되는 원칙과 지침(이해 관계자들의 의사소통 도구)

- 요구사항 : 비기능적 요구사항(제약) 반영 + 기능적 요구사항 구현

- 모듈 : 애플리케이션의 분할 방법, 분할된 모듈에 할당할 기능, 모듈 간 인터페이스 결정

 

 

 

 

2. 소프트웨어 아키텍처 설계의 기본 원리

<기본원리1> 모듈화(Modularity)

: 시스템의 기능들을 모듈 단위로 나누는 것 → SW 성능 향상, 시스템 수정 및 재사용, 유지관리의 용이성

(1) 모듈 : 전체 프로그램 기능 중 "특정 기능"을 처리할 수 있는 소스 코드

(2) 공통 모듈 : 자주 사용되는 계산식, 기능 → 재사용성 향상

(3) 모듈의 크기

- 너무 작다면? 개별 비용↓ 통합 비용↑

- 너무 크다면? 개별 비용↑ 통합 비용↓

 

 

<기본원리2> 추상화(Abstraction)

: 문제의 전체적, 포괄적인 개념 설계 → 차례로 세분화, 구체화

(1) 장점

- 시스템 유사 모델 → 여러 요인 테스트, 구조 및 구성 파악

- 최소 비용으로 실제 상황 대처

(2) 유형

- 과정 추상화 : 전반적인 흐름만 파악할 수 있게 설계 (↔자세한 수행 과정)

- 데이터 추상화 : 데이터 구조를 대표할 수 있는 표현 (↔데이터의 세부 속성, 용도)

- 제어 추상화 : 이벤트를 대표할 수 있는 표현 (↔이벤트의 정확한 절차, 방법)

 

 

<기본원리3> 단계적 분해(Stepwise Refinement)

: 하향식 설계 전략. 문제를 상위 중요 개념 → 하위의 개념으로 구체화

= 추상화의 반복

(ex> 기능 → 세부기능 → 알고리즘, 자료구조 등)

 

 

<기본원리4> 정보 은닉(Information Hiding)

: 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어짐 → 다른 모듈의 접근, 변경 불가

(1) 특징 및 장점

- 모듈 communication : 필요한 정보만, 인터페이스를 통해

- 독립적인 수행 → 수정, 시험, 유지보수의 용이성

 

 

 

 

 

3. 소프트웨어 아키텍처의 품질 속성

: 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는가? (품질 평가 요소)

(1) 시스템 측면

- 성능 : 이벤트의 적절하고 빠른 처리

- 보안 : 접근의 허용 여부에 따른 서비스 제공

- 가용성 : 장애 없이, 정상적인 서비스 제공

- 기능성 : 사용자 요구 기능 충족

- 사용성 : 편리한 사용을 위한 명확, 편리한 구현

- 변경용이성 : 다른 HW와 플랫폼에서도 동작

- 확장성 : 시스템 용량, 처리능력의 확장 가능

- 테스트 용이성, 배치성, 안정성 ...

 

 

(2) 비즈니스 측면

- 시장 적시성 : 정해진 시간에 맞춘 프로그램 출시

- 비용과 혜택 : 개발 비용을 더 투자하여 유연성 높은 아키텍처를 만들 것인지 결정

(유연성이 떨어진다면 유지보수에 비용 많이 소모됨)

- 예상 시스템 수명 : 시스템을 얼마나 오랫동안 사용할 것인지. (변경용이성, 확장성과 연관)

- 목표 시장, 공개 일정, 기존 시스템과의 통합 ...

 

 

(3) 아키텍처 측면

- 개념적 무결성 : 전체 시스템과 구성요소 간의 일관성

- 정확성, 완결성 : 요구사항, 제약사항의 충족

- 구축 가능성 : 모듈 단위 시스템의 분배 → 유연한 일정 변경

- 변경성, 시험성, 적응성, 일치성, 대체성 ...

 

 

 

 

 

4. 소프트웨어 아키텍처 설계 과정

(1) 설계 목표 설정 : 비즈니스 목표, 우선순위 등의 요구사항 분석 → 설계 목표, 개발 방향 수립

(2) 시스템 타입 결정 : 시스템, 서브시스템의 타입 결정 → 설계 목표에 맞는 아키텍처 패턴 선택

(3) 아키텍처 패턴 적용 : 시스템 표준 아키텍처 설계

(4) 서브시스템 구체화 : 서브시스템 기능, 동작, 인터페이스

(5) 검토 : 설계 목표, 요구사항, 기본 원리 측면의 검토

 

**아키텍처 패턴 : 미리 만들어 놓은 전형적인 해결방식, 예제

→ 설계 목표, 상황에 맞는 패턴을 적용

**시스템 타입

- 대화형 시스템 : 사용자 요구 발생 시 처리, 반응 (ex> 웹 애플리케이션)

- 이벤트 중심 시스템 : 외부 상태 변화에 따라 동작 (ex> 내장 소프트웨어(전화, 비상벨))

- 변환형 시스템 : 데이터 입력 시 정해진 작업 수행 (ex> 컴파일러, 네트워크 프로토콜)

- 객체 영속형 시스템 : DB를 통해 파일의 저장, 검색, 갱신 수행 (ex> 서버 관리 SW)

 

 

============================================================

 

 

[2. 아키텍처 패턴]

1. 아키텍처 패턴 (= 아키텍처 스타일 = 표준 아키텍처)

: 아키텍처 설계 시 참조할 수 있는 전형적인 해결 방식, 예제

→ 시스템 구조(시스템 아키텍처) 구성을 위한 기본적인 윤곽

 

(1) 구성

- 서브시스템들과 그 역할

- 서브시스템들 간 관계

- 규칙, 지침

 

(2) 장점

- 시간 : 개발 시간 단축

- 품질 : 고품질 SW 생산

- 안정 : 검증된 구조로 안정적인 개발 가능

- 의사소통 : 공통된 아키텍처의 공유

- 유지보수 : 시스템 구조의 쉬운 이해로 쉽게 유지보수 가능

- 예측 : 개발 전 시스템의 특성 예측 가능

 

 

 

 

2. 아키텍처 패턴 종류

<패턴1> 레이어 패턴(Layers Pattern)

: 고전적 방법. 시스템을 계층(Layer)로 구분하여 구성

- 상위 계층 : 하위 계층에 대한 서비스 제공자

- 하위 계층 : 상위 계층의 클라이언트

 

 

(1) 특징

- 상호작용 : 서로 마주보는 두 계층 사이에서만

- 변경작업 : 마주보는 계층에만 영향이 있어 용이, 특정 계층만 교체도 가능

 

(2) 활용

OSI 참조 모델 : 국제 표준화 기구(ISO)에서 정의한 네트워크 프로토콜

- 7계층 : 물리 계층, 데이터 링크 계층, 네트워크 계층, 전송 계층, 세션 계층, 표현 계층, 응용 계층

 

 

 

<패턴2> 클라이언트-서버 패턴(Client-Server Pattern)

: 하나의 서버 컴포넌트 + 다수의 클라이언트 컴포넌트

**컴포넌트 : 독립적인 업무 또는 기능을 수행하는 실행코드 기반의 모듈

(1) 특징

- 의사소통 : 사용자 ↔ 클라이언트 ↔ 서버

- 서버 : 항상 대기 상태 유지

- 독립적 : 클라이언트와 서버는 요청, 응답을 위한 동기화를 제외하고는 서로 독립적

 

 

<패턴3> 파이프-필터 패턴(Pipe-Filter Pattern)

: 데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화 → 파이프(Pipe)를 통해 데이터 전송

**데이터 스트림 : 데이터가 송수신되거나 처리되는 일련의 연속적인 흐름

(1) 필터 컴포넌트

- 재사용성 : 재배치를 통한 다양한 파이프라인 구축 가능

- 확장성 : 추가하여 확장 가능

**파이프라인 : 필터와 파이프를 통해 처리되는 일련의 처리 과정

 

(2) 활용

- 데이터 변환, 버퍼링, 동기화

- UNIX의 쉘(Shell)

 

 

 

<패턴4> 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern = MVC Pattern)

: 서브시스템을 3개의 부분으로 구조화

- 모델(Model) : 서브시스템의 핵심 기능과 데이터 보관

- 뷰(View) : 사용자에게 정보 표시

- 컨트롤러(Controller) : 사용자로부터 받은 입력의 처리, 뷰의 제어, UI 기능

(1) 특징

- 독립적 : 각각 별도의 컴포넌트로 분리

- 여러개의 뷰를 만들 수 있음

 

(2) 활용

- 대화형 애플리케이션 : 사용자 요구 발생 시 처리, 반응하는 SW

(ex> 온라인 쇼핑몰, 스마트폰 앱 등)

 

 

 

<패턴5> 마스터-슬레이브 패턴(Master-Slave Pattern)

- 마스터 컴포넌트 : 모든 작업의 주체, 슬레이브 컴포넌트들에게 작업 분할

- 슬레이브 컴포넌트 :  마스터의 지시에 따라 작업 수행 후 결과 반환

(1) 활용

- 장애 허용 시스템(Fault Tolerance System) : 시스템 일부가 결함, 고장으로 기능이 정지 BUT 전체 시스템은 정상적 수행 가능

- 병렬 컴퓨팅 시스템

 

 

 

<패턴6> 브로커 패턴(Broker Pattern)

: (사용자)원하는 서비스, 특성을 요청 → (브로커 컴포넌트) 요청에 맞는 컴포넌트와 사용자를 연결

(1) 활용

- 원격 서비스 호출에 응답하는 컴포넌트가 여러 개 있는 경우

- 분산 환경 시스템

ex>  Apache ActiveMQ, Apache Kafka, RabbitMQ, JBoss Messaging

 

 

 

<패턴7> 피어-투-피어 패턴(Peer-To-Peer Pattern)

- 피어(Peer) : 하나의 컴포넌트. 클라이언트(서비스 호출), 서버(서비스 제공) 모두 가능

(1) 특징

- 멀티스레딩 방식 이용 : 프로세스를 두 개 이상의 실행 단위로 구분하여 자원 공유하며 병렬로 수행하는 방식

 

(2) 활용

- 파일 공유 네트워크 : Gnutella, G2

- 비트코인, 블록체인

 

 

 

<패턴8> 이벤트-버스 패턴(Event-Bus Pattern)

: (소스) 이벤트 메시지 발행(publish) → (해당 채널 구독한 리스너) 이벤트 처리

(1) 구성(4가지 주요 컴포넌트)

- 소스(Source) : 이벤트 생성

- 리스너(Listener) : 이벤트 수행

- 채널(Channel) : 이벤트의 통로

- 버스(Bus) : 채널들의 관리

 

(2) 활용

- 안드로이드 개발

- 알림 시스템

 

 

 

<패턴9> 블랙보드 패턴(Blackboard Pattern)

: 모든 컴포넌트들이 검색을 통해 공유 데이터 저장소와 블랙보드 컴포넌트에서 원하는 데이터 찾음

(1) 구성

- blackboard : 솔루션의 객체를 포함하는 구조화된 global memory

- knowledge source : 자체 표현을 가진 특수 모듈

- control component : 모듈의 선택, 설정, 실행 역할

 

(2) 활용

- 해결책이 명확하지 않은 문제 처리

- 음성 인식, 차량 식별, 신호 해석 등

 

 

 

<패턴10> 인터프리터 패턴(Interpreter Pattern)

: 코드의 각 라인을 수행하는 방법 지정, 기호마다 클래스를 갖도록 구성

(1) 활용

- 특정 언어로 작성된 프로그램 코드의 해석 컴포넌트

 

(그림 : towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013)