[정보처리기사 필기] 소프트웨어 아키텍처

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

---

1. 아키텍처 설계 개요

소프트웨어 아키텍처는 소프트웨어의 골격이 되는 기본 구조이다. 소프트웨어를 구성하는 요소들간 관계를 표현하는 시스템의 구조 또는 구조체.

• 소프트웨어 개발시 적용되는 원칙과 지침. 이해관계 자들의 의사소통 도구
• 기본적으로 좋은 품질을 유지하면서 사용자의 비기능적 요구사항으로 나타난 제약 반영, 기능적 요구사항을 구한하는 방법을 찾는 해결 과정
• 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정
• 소프트웨어 아키텍처 설계의 기본원리로는 모듈화, 추상화, 단계적 분해, 정보 은닉등이 있다.

크게 상위 설계와 하위 설계로 구분 가능

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

 

모듈화(Modularity)

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

• 프로젝트의 재사용성 향상
• 모듈 크기를 너무 작게 나누면 통합 비용 증가, 너무 크게 나누면 모듈 하나의 개발 비용 증가

 

추상화(Abstraction)

문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화

• 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트 가능
• 최소 비용으로 실상황 대처 가능, 시스템의 구조 및 구성 대략적 파악 가능

추상화의 유형

과정 추상화	자세한 수행 과정 정의하지 않고 전반 적인 흐름만 파악할 수 있게
데이터 추상화	데이터의 세부적인 속성이나 용도 정의하지 않고, 데이터 구조를 대표할수 있는 표현으로 대체
제어 추상화	이벤트 발생의 정확한 절차, 방법 정의 하지않고 대표할 수 있는 표현으로 대체

 

단계적 분해(Stepwise Refinement)

Niklaus Wirth에 의해 제안된 하향식 설계 전략으로, 문제를 상위에서 하위개념으로 구체화 시키는 방법

• 추상화의 반복에 의해 세분화
• 기능에서 부터 점차적으로 구체화하고 알고리즘, 자료 구조 등 상세한 내역은 가능한 한 뒤로

 

정보 은닉(Information Hiding)

정보 은닉은 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

• 다른 모듈과 커뮤니케이션이 필요한 경우에는 필요한 정보만 인터페이스를 통해 교환
• 정보은닉을 통해 모듈을 독립적 수행가능 하고, 때문에 수정, 시험, 유지보수 용이

 

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

소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지 확인 위해 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분하여 구체화시켜 놓은것

 

시스템 측면

• 성능
• 보안
• 가용성: 장애없이 정상적으로 서비스 제공하는것
• 기능성 
• 사용성: 사용자가 사용하기에 명확하고 편리하게
• 변경 용이성: 다른플랫폼에서도 사용가능하게
• 확장성: 시스템 용량, 처리능력 등을 확장 시켰을때 이를 효과적으로 활용할 수 있도록 구현하는것
• 기타 속성: 테스트 용이성, 배치성, 안정성 등

*성능좋은 폰으로 변경해서 용량이 사.기.가(4GB) 확.보 됐다.

비즈니스 측면

• 시장 적시성: 정해진 시간에 맞춰 프로그램 출시하는것
• 비용과 혜택: 개발 비용 더 투자할지 여부 결정하는것. 유연성이 떨어질 경우 유지보수 비용 많이 들어간다는것을 고려
• 예상 시스템 수명: 수명이 길어야 한다면 시스템 품질의 '변경 용이성', '확장성' 중요하게 고려
• 기타 속성: 목표 시장, 공개 일정, 기존 시스템과의 통합 등

아키텍처 측면

• 개념적 무결성: 시스템을 이루는 구성요소들간 일관성 유지
• 정확성, 완결성: 요구사항의 제약사항 모두 충족시키는것
• 구축 가능성: 모듈단위로 구분된 시스템 적절하게 분배하여 유연하게 일정 변경할 수 있도록 
• 기타 속성: 변경성, 시험성, 적응성, 일치성, 대체성 등

 

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

설계 목표 설정, 시스템 타입 결정, 아키텍처 패턴 적용, 서브시스템 구체화, 검토 순서로 진행

1. 설계 목표 설정: 시스템의 개발 방향을 명확히 하기 위해 비즈니스 목표, 우선순위 등의 요구사항을 분석하여 설정함
2. 시스템 타입 결정: 시스템과 서브시스템 타입 결정하고, 설계 목표와 함께 고려하여 아키텍처 패턴 선택
3. 아키텍처 패턴 적용: 아키텍처 패턴 참조하여 시스템의 표준 아키텍처 설계
4. 서브시스템 구체화: 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스 정의
5. 검토: 아키텍처가 설계 목표에 부합 하는지, 요구사항이 잘 반영 되었는지, 설계의 기본 원리 만족하는지 

---

시스템 타입

• 대화형 시스템: 요구발생 시 시스템이 이를 처리하고 반응
• 이벤트 중심 시스템: 외부의 상태 변화에 따라 동작
• 변환형 시스템: 데이터 입력 시 정해진 작업 수행하여 결과 출력
• 객체 영속형 시스템: 데이터베이스 사용하여 파일을 효과적으로 저장, 검색, 갱신

 

협약에 의한 설계

컴포넌트를 설계할 때 클래스에 대한 여러가정을 공유할 수 있도록 명세한것. 소프트웨어 컴포넌트에 대한 정확한 인터페이스 명세

 

협약에 의한 설계 시 명세에 포함될 조건 

선행 조건(Precondition)	오퍼레이션이 호출되기 전에 참이 되어야 할 조건
결과 조건(Postcondition)	오퍼레이션이 수행된 후 만족되어야 할 조건
불변 조건(Invariant)	오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건

---

 

아키텍처 패턴

---

1. 아키텍처 패턴 개요

아키텍처 패턴은 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결방식 또는 예제를 의미

• 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽제시
• 아키텍처 패턴에는 서브시스템들과 그 역할이 정의되어 있으며, 서브시스템 사이의 관계와 여러 규칙, 지침들이 포함되어 있다
• 아키텍처 스타일 또는 표준 아키텍처라고도 한다

아키텍처 패턴의 장점

• 시행착오를 줄여 개발 시간을 단축, 고품질의 소프트웨어 생산가능
• 안정적인 개발 가능
• 의사소통 간편
• 개발에 참여하지 않은 사람도 손쉽게 유지 보수 가능
• 시스템의 특성을 개발전에 예측가능

 

2. 아키텍처 패턴의 종류

레이어 패턴(Layers pattern)

시스템을 계층(Layer)으로 구분하여 구성하는 고전적인 방법 중 하나

• 각각의 서브시스템들이 계층구조를 이루며, 상위 계층은 하위계층에 대한 서비스 제공자, 하위 계층은 상위 계층의 클라이언트
• 서로 마주 보는 두 개의 계층 사이에서만 상호작용 이루며 변경 사항도 마찬가지기 때문에 변경작업 용이
• 특정 계층만을 교체해 시스템을 개선하는것이 가능
• 대표적으로 OSI 참조 모델

 

OSI 참조 모델: 국제표준화기구(SO)에서 네트워크 프로토콜을 계층별로 구분한 모델로 물리, 데이터 링크, 네트워크, 전송, 세션, 표현, 응용 계층으로 구성 

 

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

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

• 사용자가 클라이언트를 통해 서버에 요청하고 클라이언트가 응답을 받아 사용자에게 제공
• 서버는 항상대기 상태 유지해야함
• 클라이언트와 서버는 요청을 받기위해 동기화 하는경우를 제외하고는 서로 독립적

 

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

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

• 필터 컴포넌트는 재사용성이좋고, 추가가 쉬워 확장이 용이
• 필터 컴포넌트들을 재배치하여 다양한 파이프라인을 구축하는것이 가능
• 데이터 변환, 버퍼링, 동기화 등에 사용
• 단방향 및 양방향 모두 구현 가능하며, 필터 간 이동 시 오버헤드 발생
• 필터간 데이터 이동 시 데이터 변환으로 인한 오버헤드 발생
• 대표적으로 UNIX의 쉘(Shell)

 

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

서브시스템을 3개의 부분으로 구조화하는 패턴

 

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

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

컨트롤러(Controller): 사용자로부터 받은 입력을 처리

 

• 각 부분이 별도의 컴포넌트로 분리되어있어 서로 영향 받지않고 개발 작업 수행가능
• 여러개의 뷰를 만들 수 있어 한개으 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합

기타 패턴

• 마스터-슬레이브 패턴(Master-Slave Pattern)
• 브로커 패턴(Broker Pattern)
• 피어-투-피어 패턴(Peer-To-Peer Pattern) 
• 이벤트-버스 패턴(Event-Bus Pattern)
• 블랙보드 패턴(Blackboard Pattern)
• 인터프리터 패턴(Interpreter Pattern)

 

---

 

출처

자료 참고: 

시나공 정보처리기사 필기 2022

표지