소프트웨어 아키텍처의 설계
- 소프트웨어 아키텍처는 소프트웨어의 격이 되는 기본 구조이자, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체이다.
- 소프트웨어 개발 시 적용되는 원칙과 지침이며, 이해 관계자들의 의사소통 도구로 활용된다.
- 소프트웨어 아키텍처의 설계는 기본적으로 좋은 품질을 유지하면서 사용자의 비기능적 요구사항으로 나타난 제약을 반영하고 기능적 요구사항을 구현하는 방법을 찾는 해결 과정이다.
- 애플리케이션의 분할 방법과 분할된 모듈에 할당된 기능, 모듈 간의 인터페이스 등을 결정한다.
- 소프트웨어 아키텍처 설계의 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보은닉이 있다.
상위 설계와 하위 설계
| 상위 설계 | 하위 설계 |
|---|
| 별칭 | 아키텍처 설계, 예비 설계 | 모듈 설계, 상세 설계 |
| 설계 대상 | 시스템의 전체적인 구조 | 시스템의 내부구조 및 행위 |
| 세부 목록 | 구조, DB, 인터페이스 | 컴포넌트 자료구조 알고리즘 |
모듈화(Modularity)
- 모듈화란 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것을 의미
- 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공동 모듈로 구성하여 프로젝트의 재사용성을 향상시킬 수 있다.
- 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈 간의 통합 비용이 많이 들고, 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이 든다.
- 모듈화를 통해 기능의 분리가 가능하여 인터페이스가 단순해진다.
- 모듈화를 통해 프로그램의 효율적인 관리가 가능하고 오류의 파급 효과를 최소화 할 수 있다.
추상화(Abstraction)
- 추상화는 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것이다.
- 인간이 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법으로, 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테 스트할 수 있다.
- 추상화는 최소의 비용으로 실제 상황에 대처할 수 있고, 시스템의 구조 및 구성을 대략적으로 파악할 수 있게 해준다.
추상화의 유형
- 과정 추상화: 자세한 수행과정을 정의하지 않고 전반적인 흐름만 파악할 수 있게 설계하는 방법
- 데이터 추상화: 데이터의 세부적인 속성이나 용도를 정의하지 않고 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
- 제어 추상화: 이벤트 발생의 정확한 절차나 방법을 정의하지 않고 대표할 수 있는 표현으로 대체하는 방법
단계적 분해(Stepwise Refinement)
- 단계적 분해는 Niklaus Wirth에 의해 제안된 하향식 설계 전략으로, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
- 추상화의 반복에 의해 세분화
- 소프트웨어의 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 가능한 한 뒤로 미루어 진행한다.
- 정보 은닉은 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
- 어떤 모듈이 소프트웨어 기능을 수행하는데 반드시 필요한 기능이 있어 정보 은닉된 모듈과 커뮤니케이션할 필요가 있을 때는 필요한 정보만 인터페이스를 통해 주고받는다.
- 정보 은닉을 통해 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이하다.
소프트웨어 아키텍처의 품질 속성
-소프트웨어 아키텍처의 품질 속성은 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지를 확인하기 위해 품질 평가요소들을 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분하여 구체화시켜 놓은것이다.
시스템 측면
| 품질 속성 | 내용 |
|---|
| 성능 | 사용자의 요청과 같은 이벤트가 발생했을 때, 이를 적절하고 빠르게 처리하는 것이다. |
| 보안 | 허용되지 않은 접근을 막고 허용된 접근에는 적절한 서비스를 제공하는 것이다. |
| 가용성 | 장애 없이 정상적으로 서비스를 제공하는 것이다. |
| 기능성 | 사용자가 요구한 기능을 만족스럽게 구현하는 것이다. |
| 사용성 | 사용자가 소프트웨어를 사용하는데 헤매지 않도록 명확하고 편리하게 구현하는 것이다. |
| 변경 용이성 | 소프트웨어가 처음 설계 목표와 다른 하드웨어나 플랫폼에서도 동작할 수 있도록 구현하는 것이다. |
| 확장성 | 시스템의 용량, 처리능력 등을 확장시켰을 때 이를 효과적으로 활용할 수 있도록 구현하는 것이다. |
| 기타 속성 | 테스트 용이성, 배차성, 안정성 등이 있다. |
비즈니스 측면
| 품질 속성 | 내용 |
|---|
| 시장 적시성 | 정해진 시간에 맞춰 프로그램을 출시하는 것이다. |
| 비용과 혜택 | - 개발 비용을 더 투자하여 유연성이 높은 아키텍처를 만들 것인지를 결정하는 것이다.
- 유연성이 떨어지는 경우 유지보수에 많은 비용이 소모될 수 있다는 것을 고려해야 한다. |
| 예상 시스템 수명 | - 시스템을 얼마나 오랫동안 사용할 것인지를 고려하는 것이다.
- 수명이 길어야 한다면 시스템 품질의 변경 용이성, 확장성을 중요하게 고려해야 한다. |
| 기타 속성 | 목표시장, 공개 일정, 기존 시스템과의 통합 등이 있다. |
아키텍처 측면
| 품질 속성 | 내용 |
|---|
| 개념적 무결성 | 전체 시스템과 시스템을 이루는 구성요소들 간의 일관성을 유지하는 것이다. |
| 정확성, 완결성 | 요구사항과 요구사항을 구현하기 위해 발생하는 제약사항들을 모두 충족시키는 것이다. |
| 구축 가능성 | 모듈 단위로 구분된 시스템을 적절하게 분배하여 유연하게 일정을 변경할 수 있도록 하는 것이다. |
| 기타 속성 | 변경성, 시험성, 적응성, 일치성, 대체성 등이 있다. |
소프트웨어 아키텍처의 설계 과정
- 아키텍처의 설계 과정은 설계 목표 설정, 시스템 타입 결정, 아키텍처 패턴 적용, 서브시스템 구체화, 검토 순으로 진행된다.
- 설계 목표 설정 : 시스템의 개발 방향을 명확히 하기 위해 설계에 영향을 주는 비즈니스 목표, 우선순위 등의 요구사항을 분석하여 전체 시스템의 설계 목표를 설정한다.
- 시스템 타입 결정 : 시스템과 서브시스템의 타입을 결정하고, 설계 목표와 함께 고려하여 아키텍처 패턴을 선택한다.
- 아키텍처 패턴 적용: 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처를 설계한다.
- 서브시스템 구체화 : 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스를 정의한다.
- 검토: 아키텍처가 설계 목표에 부합하는지, 요구사항이 잘 반영되었는지, 설계의 기본 원리를 만족하는지 등을 검토한다.
시스템 타입/ 협약에 의한 설계
- 시스템 타입
- 대화형 시스템 : 사용자의 요구가 발생하면 시스템이 이를 처리하고 반응하는 시스템(온라인 쇼핑몰과 같은 대부분의 웹 애플리케이션)
- 이벤트 중심 시스템 : 외부의 상태 변화에 따라 동작하는 시스템(전화, 비상벨 등의 내장 소프트웨어)
- 변환형 시스템 : 데이터가 입력되면 정해진 작업을 수행하여 결과를 출력하는 시스템(컴파일러, 네트워크 프로토콜 등)
- 객체 영속형 시스템 : 데이터베이스를 사용하여 파일을 효과적으로 저장 · 검색 · 갱신할 수 있는 시스템 (서버 관리 소프트웨어)
- 협약(Contract)에 의한 설계
- 컴포넌트를 설계할 때 클래스에 대한 여러 가정을 공유할 수 있도록 명시한 것으로, 소프트웨어 컴포넌트에 대한 정확한 인터페이스를 맹세한다
- 선행조건(Precondition): 오퍼레이션이 호출되기 전에 참이 되어야 할 조건
- 결과 조건(Postcondition): 오퍼레이션이 수행된 후 만족되어야 할 조건
- 불변 조건(Invariant): 오퍼레이션이 실행되는 동안 항상 만족되어야 할 조건
출처: 2024 시나공 정보처리기사 필기 기본서
