[소프트웨어공학] 아키텍처 설계

아키텍처 설계

아키텍처 설계는 어떻게 소프트웨어 시스템이 구성되어야 하는지와 시스템의 전체 구조 설계를 이해하는 것과 연관되어있다.

아키텍처 설계는 주요 구조 컴포넌트들과 그들 간의 관계를 식별하므로 설계와 요구공학 사이의 중요한 연결이다.

에자링 프로세스 아키텍처

아키텍처를 설계하기에 가장 좋은 시기는 언제일까?

• 애자일 프로세스에서는 일반적으로 애자일 개발 프로세스의 초기 단계가 전체 시스템 아키텍처 설계에 초점을 맞추어야 한다는 것을 받아들인다.

이 아키텍처가 유지되는 방법

• 변화에 대응하여 컴포넌트를 리팩토링하는 것은 비교적 쉽다. 그러나 시스템 아키텍처를 리팩토링하는 것은 대부분의 시스템 컴포넌트들을 아키텍처 변화에 따라 수정해야 할 수 있기 때문에 비용이 많이 든다.

다음 그림을 보면 시스템 아키텍처가 의미하는 바를 이해하는데 도움이 된다.

포장로봇 시스템 아키텍처의 추상적 모델

아키텍처 추상화

소규모 수준의 아키텍처

• 개별 프로그램의 아키텍처와 연관되어 있다.
• 이 수준에서는 개별 프로그램을 컴포넌트들로 분해하는 방법과 관련되어 있다.

대규모 수준의 아키텍처

• 다른 시스템들과 프로그램 컴포넌트를 포함하는 복잡한 기업 시스템과 연관되어 있다.
• 이와 같은 기업 시스템은 서로 다른 회사에서 소유하고 관리하는 컴퓨터들에 분산되어 있을 수도 있다.

아키텍처 장점

이해당사자 간의 의사소통

• 아키텍처는 상위 수준의 시스템 표현으로 다양한 범위의 이해당사자들 간 토론의 중심으로 사용될 수 있다.

시스템 분석

• 시스템이 비기능적 요구사항(성능)을 만족시킬 수 있는지 여부에 대한 분석이 가능함을 의미한다.

대규모 재사용

• 아키텍처는 다양한 시스템에서 재사용 가능할 수 있다.
• 제품 라인 아키텍처가 개발될 수 있다.

아키텍처 표현

단순함

• 엔터티와 관계를 보여주는 비공식 블록 다이어그램은 소프트웨어 아키텍처를 문서화하는 데 가장 자주 사용되는 방법이다.

의미론 부족

• 엔터티 간의 관계 유형이나 아키텍처에서 엔터티의 가시적 속성을 표시하지 않음

아키텍처 모델의 사용에 따라 다르다.

박스 및 라인 다이어그램

매우 추상적이다

• 구성요소 관계의 특성이나 하위 시스템의 외부에서 볼 수 있는 속성을 표시하지 않는다.

• 그러나 이해당사자 외의 의사소통 및 프로젝트 계획에 유용하다.

아키텍처 설계 결정

아키텍처 디자인은 창의적인 프로세스이므로 개발 중인 시스템 유형에 따라 과정이 다르다.

• 다른 이해 관계자, 다른 도메인 등

그러나 많은 일반적인 결정은 모든 설계 프로세스에 걸쳐 있으며 이러한 결정은 시스템의 비기능적 특성에 영향을 미친다.

아키텍처 재사용

• 동일한 응용 도메인의 시스템들은 종종 도메인의 근본적인 개념을 반영하는 유사한 아키텍처를 가진다.

• 응용 제품 라인은 핵심 아키텍처에 특정 고객 요구사항을 만족시키는 변형을 추가해 만들어진 애플리케이션들이다.

• 소프트웨어 시스템의 아키텍처는 특정 아키텍처 패턴 또는 스타일에 기반을 둘 수 있다.

• 이들은 아키텍처의 본질을 포착하고 다양한 방식으로 인스턴스화할 수 있다.

아키텍처 및 시스템 특성

1. 성능
   • 작고 세분화된 컴포넌트보다는 상대적으로 큰 몇 개의 컴포넌트를 사용하 는 것을 의미한다.

1. 보안성
   • 가장 중요한 자산이 가장 안쪽 계층에서 보호되고 높은 수준의 보안 검증이 이 계층에 적용

1. 안전성
   • 장애가 일어났을 때 안전하게 시스템을 종료시킬 수 있는 관련된 보호 시스템을 제공

1. 가용성
   • 중복 컴포넌트를 포함하여 시스템의 중단없이 컴포넌트를 교체하고 갱신하는 것이 가능하게 아키텍처가 설계

1. 유지보수성
   • 변경이 용이한 세분화되고 독립적인 컴포넌트를 사용하도록 시스템 아키텍처가 설계

아키텍처 뷰

이 파트에서는 다음 두가지 모두와 관련된 이슈를 논의한다.

1. 시스템이 아키텍처를 설계하거나 문서화할 때 어떤 뷰나 관점이 유용한가?
2. 아키텍처 모델을 기술하기 위해 어떤 표기법이 사용되어야 하는가?

그래픽 모델은 시스템의 한 가지 뷰나 관점만 보여줄 수 있기 때문에 시스템의 아키텍처와 관련된 모든 정보를 하나의 다이어그램에 표현하는 것은 불가능하다.

기본적인 4+1 아키텍처 뷰

논리적 뷰

• 객체 또는 객체 클래스로 시스템의 핵심 추상화를 보여주며 시스템 요구사항을 논리적 뷰의 개체들에 연관 짓는 것이 가능하여야 한다.

프로세스 뷰

• 런타임에 시스템이 어떻게 상호 작용하는 프로세스들로 구성되는지 보여준다.

개발 뷰

• 소프트웨어가 개발을 위해 어떻게 분해되는지를 보여준다.

물리적 뷰

• 시스템 하드웨어와 소프트웨어 컴포넌트들이 시스템의 프로세서에 어떻게 분산되는지를 보여준다.

공통적인 유스케이스나 시나리오를 통해 연결될 수 있는 네가지 기본적인 아키텍처 뷰다.

아키텍처 패턴

아키텍처 패턴은 소프트웨어 시스템에 대한 지식을 표현하고 공유하고 재사용하는 방법이다.

• 아키텍처 패턴은 서로 다른 시스템과 환경에서 시도되고 시험된 바람직한 사례를 양식화하고 추상화한 기술이라고 생각할 수 있다.

• 해당 패턴을 언제 사용하기에 적절하고 적절하지 않은지에 대한 정보와 패턴의 강점과 약점에 대한 상세한 내용이 포함되어야 한다.

• 패턴은 표 및 그래픽 설명을 사용하여 나타낼 수 있다.

MVC(모델 뷰 제어기)

시스템 데이터로부터 표현과 상호 작용을 분리시킨다. 시스템은 서로 상호 작용하는 세 개의 논리적 컴포넌트로 구조화된다.

• 모델 컴포넌트는 시스템 데이터와 데이터에 대한 오퍼레이션을 관리한다.

• 뷰 컴포넌트는 사용자에게 데이터가 어떻게 표현되는지를 정의하고 관리한다.

• 제어기 컴포넌트는 사용자 상호 작용(키 누름, 마우스 클릭)을 관리하고 이를 뷰와 모델에 전달한다.

장점 : 데이터 표현과 무관하게 데이터 변경, 동일한 데이터를 서로 다른 방법으로 표현하는 것을 지원하며, 한 표현에 가해진 변경이 다른 표현에도 반영된다.

단점 : 데이터 모델과 상호 작용이 단순한 경우에는 추가 코딩과 코드의 복잡도가 단점이 될 수 있다.

다음은 MVC 패턴을 이용한 애플리케이션 아키텍처

계층 아키텍처