[CS BASIC] 소프트웨어 아키텍처 (Software Architecture)

소프트웨어 아키텍처란?

• 요구사항을 기반으로 개발 대상 소프트웨어의 기본 틀(뼈대)를 만드는 것이다.
• 다수의 이해관계자가 참여하는 복잡한 개발에서 상호이해, 타협, 의사소통을 체계적으로 접근하기 위한 것이다.
• 전체 시스템의 전반적인 구조를 체계적으로 설계 하는 것이다.
• 소프트웨어를 구성하는 컴포넌트들의 상호작용 및 관계, 각각의 특성을 기반으로 컴포넌트들이 상호 유기적으로 결합하는 소프트웨어의 여러 가지 원칙들의 집합이다.
• 설계 및 구현을 위한 구조적/비구조적인 틀(Frame)을 제공한다.

 

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

① 성능, ② 사용 운용성, ③ 보안성, ④ 시험 용이성, ⑤ 가용성, ⑥ 변경 용이성, ⑦ 사용성

 

소프트웨어 아키텍처 특징

① 간략성 : 이해하고 추론할 수 있을 정도 간결해야 한다.

② 추상화 : 시스템의 추상적인 표현을 사용한다.

③ 가시성 : 시스템이 포함해야 하는 것들을 가시화해야 한다.

④ 복잡도의 관리 : 과정 추상화, 데이터 추상화, 제어 추상화

 

추상화(Abstraction)란?

• 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것

 

추상화 기법의 종류 | 소프트웨어 설계에 사용되는 대표적인 3가지 기법

① 제어 추상화: 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법

② 기능 추상화: 입력 자료를 출력자료로 변환하는 과정을 추상화하는 방법

③ 자료 추상화: 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법

 

소프트웨어 아키텍처 평가 기준

① 시스템은 어떻게 모듈로 구성되는가?

② 시스템은 실행 시에 어떻게 행동하고, 연결되는가?

③ 시스템은 어떻게 비 소프트웨어 구조(CPU, 파일 시스템, 네트워크, 개발팀 등)와 관계하고 있는가?

 

 

바람직한 소프트웨어 설계 지침

• 모듈의 기능을 예측할 수 있도록 정의한다.
• 이식성을 고려한다.
• 적당한 모듈의 크기를 유지한다.
• 가능한 모듈을 독립적으로 생성하고 결합도를 최소화한다.
• 모듈 간의 접속 관계를 분석하여 복잡도와 중복을 줄인다.
• 모듈 간의 결합도는 약할수록 바람직하다.
• 모듈 간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 한다.

 

설계 명세서에 포함되어야 할 조건 (설계의 세 가지 타입)

① 선행조건(precondition): 오퍼레이션이 호출되기 전에 참이 되어야 할 조건

② 결과조건(postcondition): 오퍼레이션이 수행된 후 만족하여야 하는 조건

③ 불변조건(invariant): 클래스 내부가 실행되는 동안 항상 만족하여야 하는 조건

 

아키텍처 프레임워크 구성요소

프레임워크(Framework)란?

• 복잡한 소프트웨어 문제를 해결하거나 기술하는데 필요한 기본 구조를 제공함으로써 재사용이 가능하게 한다.

 

프레임워크의 구성요소

① Architecture Description(AD)

• 아키텍처를 기록하기 위한 산출물이다.
• 하나의 AD는 하나 이상의 View로 구성한다.

 

② 이해관계자(Stakeholder)

• 소프트웨어 시스템 개발에 관련된 모든 사람과 조작을 의미하며, 고객, 개발자, 프로젝트 관리자 등을 포함한다.

 

③ 관심사(Concerns)

• 같은 시스템에 대해 서로 다른 이해관계자의 의견이다.

 

④ 관점(Viewport)

• 서로 다른 역할이나 책임으로 시스템이나 산출물에 대한 서로 다른 관점이다.

 

⑤ 뷰(View)

• 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현(4+1 View) 한다.

 

소프트웨어 아키텍처 4+1 View Model

• Kruchten에 의해 Object 표기법을 사용하다가 1995년 Booch의 UML이 정의되면서 Booch 표기법을 포함하여 4+1이 되었다.
• 다양하고 동시적인 View를 기반으로 소프트웨 위주 시스템의 아켁처를 묘사하는 View 모델이다.
• 복잡한 소프트웨어 아키텍처를 다양한 이해관계자들이 바라보는 관점으로, 다양한 측면을 고려하기 위하여 다양한 관점을 바탕으로 정의한 모델이다.
• Logical View(분석 및 설계), Implementation View(프로그래머), Process View(시스템 통합자), Deployment View(시스템 엔지니어), Use Case View(사용자)의 5계층으로 분류한 모델이다.

 

소프트웨어 아키텍처 설계 원리

① 단순성 : 다양한 요소를 단순화하여 복잡성을 최소화한다.

② 효율성 : 활용 자원의 적절성과 효율성을 높인다.

③ 분할, 계층화 : 다루기 쉬운 단위로 묶어서 계층화한다.

④ 추상화 : 부가적인 기능이 아닌 핵심 기능 위주로 컴포넌트를 정의한다.

⑤ 모듈화 : 내부 요소의 응집도를 높이고, 각 모듈의 외부 결합도를 낮춘다.

 

소프트웨 어카텍처 설계 과정

① 설계 목표 설정 → ② 시스템 타입 결정 → ③ 스타일 적용 및 커스터마이즈 → ④ 서브 시스템의 기능, 인터페이스의 동작 작성 → ⑤ 아키텍처 설계 검토

 

 

SW 아키텍처 평가 방법론 유형

① Scenario Based → 예측평가

• 품질 요소를 위해 미리 정의된 프로필에 의존하여 평가하는 방식이다.
• 시나리오의 정밀함에 따라 평가 결과도 정밀해질 수 있다.

ex) ATAM, SAAM

 

② Simulation Based → 실무 평가

• BMT(BenchMarking Test) 시뮬레이션 기반으로 평가한다.

 

③ Experience Based → 사례 평가

• 정량적인 분석이 어려운 경우 적용하는 경험 기반으로 평가한다.

 

④ Mathmatical Model Based → 정량적 평가

• 기준 모델을 수치화하고 이를 기초로 평가하는 수학적 모델이다.

 

소프트웨어 아키텍처 평가 방법론의 종류

① SAAM, Software Architecture Analysis Method

• 다양한 수정 가능성 관점에서 아키텍처를 평가하고 분석하는 방법
• 수정/변경에 필요한 자원을 가정하고 이를 기반으로 평가함
• ATAM에 비하여 상세하지는 않지만 보다 많은 영역에 적용할 수 있다.

 

② ATAM, Architecture Trade off Analysis Method

• 아키텍처가 품질 속성을 만족하는지 판단하고, 어떻게 절충하며 상호작용하는지 분석 평가하는 방법
• 모든 품질 속성을 평가하고, 관심 있는 모든 관련 당사자가 참여
• 정량적/정성적 분석과 평가를 수행하며 민감점과 절충점을 찾는데 중점을 둔다.

 

③ CBAM, Cost Benefit Analysis Method

• 소프트웨어 아키텍처를 ROI 관점에서 평가하며 시스템이 제공하는 품질에서 경제적 이득 측면을 고려한다.
• 비용, 이익을 기반으로 ROI를 계산하여 수익이 최대화 되는 소프트웨어 아키텍처를 선정한다.

 

④ ARID, Active Review for Intermediate Desgin (ATAM+ADR)

• 전체 아키텍처가 아닌 한 부분에 대한 품질 요소에 집중하여 평가를 진행

 

⑤ ADR, Active Design Review

• 아키텍처 구성요소 간 응집도를 평가한다.