[정처기 필기] 「1」 | 애플리케이션 설계 - (3.1) 소프트웨어 아키텍처, 아키텍처 패턴

[정처기 필기] 「1」 | 애플리케이션 설계 - (3.1) 소프트웨어 아키텍처, 아키텍처 패턴

> 「1」 소프트웨어 설계

- 요구사항 확인, 화면 설계, > 애플리케이션 설계, 인터페이스 설계

「2」 소프트웨어 개발

「3」 데이터베이스 구축

「4」  프로그래밍 언어 활용

「5」  정보시스템 구축 관리

 

> 1 소프트웨어 아키텍처

> 2 아키텍처 패턴

3 객체지향(Object-Oriented)

4 객체지향 분석 및 설계

5 모듈

6 공통 모듈

7 코드

8 디자인 패턴

1. 소프트웨어 아키텍처

소프트웨어 아키텍처의 설계

 

소프트웨어의 골격이 되는 기본 구조, 요소들 간의 관계를 표현하는 시스템의 구조, 구조체

 

- 소프트웨어 개발 시 적용되는 원칙과 지침, 의사소통 도구로 활용

- 좋은 품질 유지, 비기능적 요구사항으로 나타난 제약 반영, 기능적 요구사항을 구현하는 해결 과정

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

- 모듈화, 추상화, 단계적 분해, 정보 은닉

 

>상위 설계와 하위 설계<

 

	상위 설계	하위 설계
별칭	아키텍처 설계, 예비 설계	모듈 설계, 상세 설계
설계 대상	시스템의 전체적인 구조	시스템의 내부 구조 및 행위
세부 목록	구조, DB, 인터페이스	컴포넌트, 자료 구조, 알고리즘

 

상위 설계 : 구조, DB, 인터페이스, 아키텍처

하위 설계 : 모듈, 컴포넌트, 자료구조, 알고리즘

 

모듈화(Modularity)

 

소프트웨어의 성능 향상, 시스템 수정 및 재사용, 유지 관리 등에 용이하도록 시스템의 기능들을 모듈 단위로 나눈 것

 

- 자주 사용되는 기능들을 공통 모듈로 구성, 재사용성을 향상

- 모듈의 크기가 너무 작으면, 모듈 간 통합 비용이 많이 들며, 모듈의 크기가 너무 크면, 모듈 하나의 개발 비용이 많이 듦

- 기능의 분리 가능하여 인터페이스 단순화

- 프로그램의 효율적인 관리, 오류 최소화

- subroutine, function으로 표현 가능

 

추상화(Abstraction)

 

문제의 전체적이고 포괄적인 개념을 세분화하여 구체화시키는 것

 

- 인간이 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법, 시스템과 유사한 모델을 만들어 테스트

- 최소의 비용으로 실체 상황에 대처, 시스템의 구조 및 구성을 대략적으로 파악

- 추상화의 유형

: 과정 추상화 - 전반적인 흐름만 파악

: 데이터(자료) 추상화 - 데이터의 구조를 대표할 수 있는 표현으로 대체

: 제어 추상화 - 대표할 수 있는 표현으로 대체

 

단계적 분해(Stepwise Refinement)

 

문제를 상위의 중요 개념부터 하위의 개념으로 구체화시키는 분할 기법

 

- 추상화의 반복으로 세분화

- 기능에서부터 시작하여 점점 구체화, 알고리즘, 자료구조 등 상세한 내역은 뒤로 미루어 진행

 

정보 은닉(Information Hiding)

 

한 모듈 내부에 포함된 자료 정보가 감춰져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

 

- 정보 은닉 모듈과 상호작용 해야 할 경우, 필요한 정보만 인터페이스를 통해 주고받음

- 모듈을 독립적으로 수행, 수정, 시험, 유지보수에 용이

- IP 주소 같은 물리적 코드, 상세 데이터 구조 등

 

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

 

품질 평가 요소를 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분하여 구체화

 

시스템 측면

: 성능 - 이벤트 발생 시 적절하고 빠르게 처리

: 보안 - 허용되지 않은 접근 막고, 허용된 접근에 서비스 제공

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

: 기능성 - 요구된 기능을 만족스럽게 구현

: 사용성 - 명확하고 편리하게 구현

: 변경 용이성 - 다른 하드웨어나 플랫폼에서도 동작하도록 구현

: 확장성 - 시스템의 용량, 처리 능력 등을 확장 시 효과적으로 활용하도록 구현

: 기타 속성 - 테스트 용이성, 배치성, 안정성 등

 

비지니스 측면

: 시장 적시성 - 정해진 시간에 맞춰 출시

: 비용과 혜택 - 개발 비용을 더 투자하여 유연성 높게 만들 것인지 결정, 아니라면 유지보수 비용 소모 가능성

: 예상 시스템 수명 - 얼마나 오랫동안 사용할 것인지 고려, 수명이 길어야 한다면 '변경 용이성', '확장성' 고려

: 기타 속성 - 목표 시장, 공개 일정, 기존 시스템과의 통합 등

 

아키텍처 측면

: 개념적 무결성 - 구성요소들 간의 일관성 유지

: 정확성, 완결성 - 제약사항 모두 충족시키는 것

: 구축 가능성 - 모듈 단위로 구분된 시스템을 분배하여 일정을 변경할 수 있도록

: 기타 속성 - 변경성, 시험성, 적응성, 일치성, 대체성 등

 

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

 

설계 목표, 시스템 타입 결정, 아키텍처 패턴 적용(스타일 적용 / 커스터마이징) , 서브시스템 구체화, 검토 순으로 진행

 

1 설계 목표 설정 : 요구사항 분석하여 전체 시스템의 설계 목표 설정

2 시스템 타입 결정 : 시스템과 서브시스템 타입 결정, 아키텍처 패턴 선택

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

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

5 검토 : 설계 목표에 부합하는지, 요구사항 반영, 설계의 기본원리 만족 등 검토

 

>시스템 타입 / 협약에 의한 설계<

 

- 시스템 타입

대화형 시스템 : 요구가 발생하면, 반응하고 처리하는 시스템, 대부분의 웹 애플리케이션

ex) 온라인 쇼핑몰

이벤트 중심 시스템 : 외부의 상태 변화에 동작하는 시스템, 내장 소프트웨어

ex) 전화, 비상벨

변환형 시스템 : 데이터가 입력되면 수행하여 결과를 출력하는 시스템

ex) 컴파일러, 네트워크 프로토콜

객체 영속형 시스템 : 데이터베이스 사용하여 파일을 효과적으로 저장 / 검색 / 갱신할 수 있는 시스템

ex) 서버 관리 소프트웨어

 

- 협약(Contract)에 의한 설계

클래스에 대한 여러 가정을 공유하도록 명세한 것, 인터페이스를 명세

 

: 선행 조건(Precondition) : 오퍼레이션이 호출되기 전, 참이 되어야 하는 조건

: 결과 조건(Postcondition) : 오퍼레이션이 수행된 후, 만족되어야 하는 조건

: 불변 조건(Invariant) : 오퍼레이션이 실행되는 동안, 만족되어야 하는 조건

2. 아키텍처 패턴

아키텍처 패턴(Patterns)의 개요

 

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

 

- 외부에서 인식할 수 있는 특성이 담긴 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽

- 서브시스템과 역할, 관계(Interface), 규칙, 지침 등 정의

-  == 아키텍처 스타일, 표준 아키텍처

- 아키텍처 패턴의 장점

  : 개발시간 단축, 고품질 소프트웨어 생산

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

  : 공통된 아키텍처 공유하므로 의사소통 용이

  : 유지보수 용이

  : 개발 전 예측이 가능

- 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴 등

 

레이어 패턴(Layers Pattern)

 

시스템을 계층으로 구분, 고전적인 방법

 

- 각각의 서브시스템들이 계층 구조를 이루며, 하위 계층은 서비스 제공자, 상위 계층은 클라이언트

- 서로 마주 보는 두 개의 계층 사이에서만 상호작용 이뤄짐, 변경 작업 용이

- 특정 계층만 교체하여 시스템 개선 가능

- OSI 참조 모델

 

Layer n

↓

Layer n - 1

˙ ˙ ˙

Layer 1

 

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

 

하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성

 

- 사용자는 클라이언트와만 의사소통, 클라이언트를 통해 서버에 요청하고 클라이언트가 사용자에게 제공

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

- 클라이언트와 서버는 독립적

 

Client

→

Server

 

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

 

데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송

 

- 필터 컴포넌트는 재사용성 좋고, 추가 쉬워 확장에 용이, 재배치하여 다양한 파이프라인 구축 가능

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

- 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드 발생

- UNIX의 쉘(Shell)

 

Soure

(Pipe 1) →

Filter1

(Pipe 2) →

Filter2

(Pipe 3) →

Sink

 

모델-뷰-컨트롤러 패턴(MVC; Model-View-Controller Pattern)

 

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

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

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

: 컨트롤러(Controller) - 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령

 

- 별도의 컴포넌트로 분리되어 있으므로 서로 독립적

- 여러 개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합

 

(input) → → → → →	→   Controller   →	(갱신) → → → → →	Model
	↓ (갱신) ↓	↙ ↗ (변경 알림)↙ ↗(정보 요청) ↙ ↗
(output) ← ← ← ← ←	↓ ← ←   View

 

기타 패턴

 

마스터-슬레이브 패턴 (Master-Slave Pattern)	- 마스터 컴포넌트와 동일한 구조, 동일한 기능을 사용하는 슬레이브 컴포넌트로 작업 분할 후, 슬레이브 컴포넌트에서 처리된 결과물을 돌려받는 방식 - 마스터 컴포넌트는 모든 작업의 주체, 슬레이브 컴포넌트는 지시에 따라 작업 수행하여 결과 반환 - 장애 허용 시스템, 병렬 컴퓨팅 시스템
브로커 패턴 (Broker Pattern)	- 브로커 컴포넌트가 컴포넌트와 사용자 연결 - 원격 서비스 호출에 응답하는 컴포넌트가 여러 개 있을 때 적합 - 분산 환경 시스템
피어-투-피어 패턴 (Peer-To-Peer Pattern)	- 피어를 하나의 컴포넌트로 간주, 피어가 클라이언트가 될 수도, 서버가 될 수도 있음 - 클라이언트와 서버는 멀티스레딩 방식을 사용
이벤트-버스 패턴 (Event-Bus Pattern)	- 이벤트 메시지 발행하면, 구독한 리스너들이 이벤트를 처리 - 4가지 주요 컴포넌트 : 이벤트를 생성하는 소스(Source) : 이벤트를 수행하는 리스너(Listener) : 이벤트의 통로인 채널(Channel) : 채널을 관리하는 버스(Bus)
블랙보드 패턴 (Blackboard Pattern)	- 모든 컴포넌트들이 공유 데이터 저장소, 블랙보드 컴포넌트에 접근 가능, 검색을 통해 블랙보드에서 원하는 데이터 찾음 - 해결책이 명확하지 않은 문제 처리 - 음성 인식, 차량 식별, 신호 해석
인터프리터 패턴 (Interpreter Pattern)	- 코드의 각 라인을 수행하는 방법 지정, 기호마다 클래스 갖도록 구성 - 특정 언어로 작성된 프로그램 코드 해석

 

 

 

 

 

 

출처 | <시나공> 정보처리기사 필기 2024 기본서 (길벗알앤디)