소프트웨어 아키텍처

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

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

 

특징

• 의사소통 도구: 소프트웨어 개발 시 적용되는 원칙과 지침이며, 이해 관계자 간의 의사소통 도구로 활용.
• 명확성: 이해하기 쉽고 명확하게 작성되어야 한다.
• 제약과 요구사항 반영: 비기능적 요구사항에서 나타난 제약을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 설계 과정.
• 구조 결정: 애플리케이션의 분할 방법, 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정.
• 기본 원리: 설계의 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보 은닉이 있다.

부가 설명

• 기능적 요구사항: 시스템이 제공해야 하는 서비스나 동작을 정의하며, 사용자가 원하는 주요 기능을 다룹니다.
  예: 로그인 기능, 데이터 검색 기능
• 비기능적 요구사항: 시스템의 품질, 성능, 보안 등과 관련된 제약사항이나 요구 조건을 정의합니다.
  예: 응답 시간 1초 이내, 데이터 암호화 필요

---

소프트웨어 아키텍처 뷰(View)

소프트웨어 아키텍처는 다양한 관점(View)을 통해 설계의 복잡성을 관리하고, 다양한 이해 관계자들의 요구를 충족시킵니다. 주요 뷰는 다음과 같습니다.

 

뷰의 종류 및 설명

뷰(View)	설명	주요 관점
유스케이스 뷰	시스템 외부 사용자의 관점에서 사용 사례와 이들 간의 관계를 정의하며, 다른 뷰를 검증하는 용도로 사용.	시스템 사용자
논리적 뷰	설계자의 관점에서 시스템의 기능적인 요구사항이 제공되는 방법을 설명.	설계자
구현 뷰	개발자의 관점에서 서브 시스템 모듈의 구조화를 확인하기 위해 소프트웨어 구성을 보여줌.	개발자
프로세스 뷰	시스템 통합자의 관점에서 자원의 효율적인 사용과 이벤트 처리 등을 표현.	시스템 통합자
배포 뷰	테스터의 관점에서 컴포넌트 배치 및 연결 방식을 보여줌.	테스터

 

특징

• 다양한 관점: 시스템 개발 과정에서 각 이해관계자의 요구를 충족하도록 다양한 관점에서 설계.
• 상호 보완성: 각 뷰는 독립적으로 사용될 수 있으나, 서로 보완적인 역할을 수행.
• 목적별 활용: 시스템 사용자, 설계자, 개발자, 통합자, 테스터 등 역할에 따라 뷰를 활용.

---

모듈화(Modularity)

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

 

특징:

• 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공통 모듈로 구성하여 프로젝트의 재사용성을 향상.
• 모듈의 크기를 적절히 나눠야 통합 비용과 개발 비용을 균형 있게 관리 가능.

부가설명 - 모듈(Module):
모듈은 특정 기능을 수행하는 독립적인 프로그램 단위로, 유지보수성과 재사용성을 높이기 위해 설계됩니다.

---

추상화(Abstraction)

문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화해 나가는 것을 의미합니다.

 

특징:

• 복잡한 문제를 해결하기 위한 기본적인 방법으로, 완전한 시스템 구축 전 유사한 모델을 만들어 테스트 가능.
• 최소 비용으로 실제 상황에 대비할 수 있으며, 시스템의 구조와 구성을 대략적으로 파악 가능.

추상화의 유형

 

과정 추상화 (Process Abstraction):

• 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있도록 설계하는 방법.

데이터 추상화 (Data Abstraction):

• 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터를 대표할 수 있는 단순한 표현으로 대체.

제어 추상화 (Control Abstraction):

• 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 이를 대표할 수 있는 표현으로 대체.

---

단계적 분해(Stepwise Refinement)

Niklaus Wirth가 제안한 하향식 설계 전략으로, 문제를 상위의 중요한 개념으로부터 하위의 구체적인 개념으로 점진적으로 구체화하는 분할 기법입니다.

 

특징

• 추상화의 반복: 문제를 해결하기 위해 큰 개념에서 시작하여 점차적으로 구체화해 나감.
• 점진적 구체화: 소프트웨어의 주요 기능부터 설계하고, 세부적인 알고리즘과 자료 구조는 설계 후반부에 다룸.
• 체계적 설계: 문제를 계층적으로 분해함으로써 복잡성을 줄이고 설계 과정을 명확히 표현.

---

정보 은닉(Information Hiding)

한 모듈 내부의 절차와 자료를 감추어 다른 모듈이 접근하거나 변경하지 못하도록 하는 소프트웨어 설계 기법입니다.

 

특징

• 필요한 정보만 공개: 모듈 간의 의사소통이 필요할 경우, 반드시 필요한 정보만 인터페이스를 통해 주고받도록 제한.
• 모듈의 독립성 보장: 정보 은닉된 모듈은 독립적으로 수행될 수 있으며, 다른 모듈의 변경에 영향을 받지 않음.
• 유지보수성 향상: 하나의 모듈을 수정하더라도 다른 모듈에 영향을 주지 않아 시스템의 수정, 테스트, 유지보수가 용이.
• 복잡성 감소: 시스템의 복잡성을 줄이고 모듈 간 결합도를 낮춤으로써 효율적인 설계와 관리 가능.

---

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

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

 

시스템 측면

품질 속성	설명
성능(Performance)	시스템이 요구된 시간 내에 작업을 처리할 수 있는 능력. 응답 시간, 처리량 등을 포함.
보안성(Security)	시스템이 외부 및 내부 위협으로부터 보호되는 능력. 데이터 보호 및 접근 제어 포함.
가용성(Availability)	시스템이 일정 시간 동안 정상적으로 운영될 수 있는 능력. 다운타임 최소화 포함.
기능성(Functionality)	사용자가 기대하는 시스템의 기능적 요구를 정확하고 완벽하게 수행하는 능력.
사용성(Usability)	시스템이 사용하기 쉽고, 사용자 인터페이스가 직관적이며 효율적인 능력.
변경용이성(Maintainability)	시스템을 수정하거나 개선할 때 발생하는 노력과 비용의 최소화.
확장성(Scalability)	시스템이 증가하는 작업량이나 사용자 요구를 처리하기 위해 확장 가능한 능력.
기타 속성	테스트 용이성(Testability), 배치성(Deployability), 안정성(Stability) 등이 포함.

 

비즈니스 측면

품질 속성	설명
시장 적시성	시스템이 시장에 적시에 출시될 수 있는 능력.
비용과 혜택	시스템 개발 및 유지보수 비용 대비 얻을 수 있는 이익.
예상 시스템 수명	시스템이 유효하게 사용될 수 있는 예상 기간.
기타 속성	목표 시장,공개 일정,기존 시스템과의 통합등이 있다

 

아키텍처 측면

품질 속성	설명
개념적 무결성	아키텍처가 일관된 설계 원칙과 스타일을 유지하는 정도.
정확성, 완결성	시스템 요구사항을 충족시키고 모든 필요한 요소를 포함하는 정도.
구축 가능성	아키텍처가 실제로 구현 가능한지 여부.
기타 속성	변경성, 시험성, 적응성, 일치성, 대체성등이 있다

---

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

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

 

설계 과정

소프트웨어 아키텍처 설계는 다음과 같은 순서로 진행됩니다:

 

설계 목표 설정

• 시스템이 충족해야 할 품질 속성, 성능, 비용, 일정 등의 목표를 설정합니다.

시스템 타입 결정

• 시스템과 서브시스템의 타입을 결정하고, 설계 목표와 함께 고려하여 아키텍처 패턴을 선택

아키텍처 패턴 적용

• 시스템 설계에서 재사용 가능한 일반적인 솔루션을 적용합니다.
• 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처를 설계
• 부가설명: 아키텍처 패턴은 특정 설계 문제를 해결하기 위한 검증된 재사용 가능한 템플릿입니다. 예로 MVC(Model-View-Controller), 계층형 구조, 이벤트 기반 패턴 등이 있습니다.

서브 시스템 구체화

• 시스템을 구성하는 서브 시스템을 세부적으로 정의하고, 각 서브 시스템의 역할과 인터페이스를 명확히 합니다.

검토

• 설계된 아키텍처가 목표를 충족하는지 검토하고, 필요 시 수정합니다.

---

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

 

시스템 타입

 

 

대화형 시스템

• 설명: 사용자와의 상호작용을 기반으로 동작하는 시스템.
• 예시: 웹 브라우저, 데스크톱 애플리케이션의 GUI(그래픽 사용자 인터페이스).
• 상황: 사용자가 버튼을 클릭하면 파일이 업로드되는 기능 제공.

이벤트 중심 시스템

• 설명: 특정 이벤트가 발생하면 이에 따른 동작을 수행하는 시스템.
• 예시: 알림 시스템, IoT 장치의 센서 반응.
• 상황: 센서가 특정 온도를 감지하면 에어컨이 작동.

변화형 시스템

• 설명: 지속적으로 변화하는 데이터를 처리하거나 변화하는 환경에 적응하는 시스템.
• 예시: 주식 거래 시스템, 실시간 위치 추적 서비스.
• 상황: 주식 시장의 실시간 데이터를 받아 거래를 수행.

객체 영속형 시스템

• 설명: 객체 데이터를 저장하고 관리하는 시스템으로, 데이터의 영속성을 보장.
• 예시: ERP(Enterprise Resource Planning) 시스템, CRM(Customer Relationship Management) 시스템.
• 상황: 고객 정보와 거래 내역을 데이터베이스에 저장하고 검색.

 

협약(Contract)에 의한 설계

컴포넌트 설계 시 클래스에 대한 여러 가정을 공유하고 명확히 하기 위해 작성한 명세입니다. 이를 통해 소프트웨어 컴포넌트의 정확한 인터페이스를 정의합니다.

 

구성 요소:

선행조건(Precondition)

• 메소드나 함수가 실행되기 전에 반드시 충족되어야 할 조건.

결과조건(Postcondition)

• 메소드나 함수 실행 후 보장해야 할 결과 조건.

불변조건(Invariant)

• 클래스나 시스템이 항상 만족해야 할 조건.

부가설명:

• 협약에 의한 설계는 소프트웨어 컴포넌트 간의 명확한 계약을 통해 오류를 줄이고, 재사용성과 안정성을 향상시키는 데 기여합니다.

---

 

출저 및 참고

정보처리 산업기사 기본서(시나공)