개념: 소프트웨어 아키텍처
소프트웨어 아키텍처는 시스템의 구조를 나타내며, 소프트웨어 컴포넌트, 컴포넌트의 외부 가시적 특성 및 컴포넌트 간의 관계로 구성됩니다.
관계
기본 설명

소개

소프트웨어 아키텍처는 이해하기 쉽고 대부분의(특히 경험이 부족한) 엔지니어가 직관적이라고 느끼는 개념이지만 정확히 정의하기는 어렵습니다. 특히 디자인과 아키텍처를 구별하기가 어렵습니다. 아키텍처는 특정 기능에 초점을 맞춘 디자인의 한 측면입니다.

An Introduction to Software Architecture(David Garlan 및 Mary Shaw 저)에서는 소프트웨어 아키텍처가 다음과 같은 문제와 관련된 디자인 레벨이라고 주장합니다. - "컴퓨터 조작과 관련된 알고리즘과 데이터 구조를 넘어서며, 전체 시스템 구조를 정의하고 지정하면 새로운 유형의 문제점으로 나타납니다. 구조적 문제에는 전체 조직과 글로벌 제어 구조, 통신 프로토콜, 동기화와 데이터 액세스, 디자인 요소에 기능 지정, 실제 분배, 디자인 요소 구성, 크기 조정과 성능, 디자인 대체 중의 선택 등이 포함됩니다."[GAR93].

그러나 아키텍처에는 단순한 구조 이상의 무엇이 있습니다. IEEE Working Group on Architecture에서는 아키텍처를 "해당 환경 시스템의 최상위 레벨 개념"으로 정의합니다[IEP1471]. 또한 아키텍처는 시스템 무결성, 경제적 제한조건, 미적 관심사항 및 스타일과의 "적합성"을 포함합니다. 이는 내부에만 집중하는 대신 시스템을 사용자 환경 및 개발 환경의 전체로 봅니다. 즉 외부로 초점을 맞춥니다.

RUP에서, 소프트웨어 시스템의 아키텍처(특정 시점)는 연속적으로 더 작은 컴포넌트로 구성된 컴포넌트 및 인터페이스와 인터페이스를 통해 상호작용하는 시스템의 중요 컴포넌트의 조직 또는 구조입니다.

아키텍처 설명

소프트웨어 아키텍처에 대해 논의하려면 우선 아키텍처 표시, 즉 아키텍처의 주요 측면을 설명하는 방법을 정의해야 합니다. RUP에서, 이 설명은 소프트웨어 아키텍처 문서에 캡처되어 있습니다.

아키텍처 보기

여러 아키텍처 보기로 소프트웨어 아키텍처를 나타내도록 선택했습니다. 각 아키텍처 보기에는 개발 프로세스의 이해 당사자(stakeholder)인 사용자, 디자이너, 관리자, 시스템 엔지니어, 유지보수자 등에 특정한 일부 관심사항 세트가 표시됩니다.

보기는 소프트웨어 아키텍처가 컴포넌트로 분해되는 방법 및 컴포넌트가 커넥터로 연결되어 유용한 양식을 생성하는 방법을 보여 줌으로써 주요 구조적 디자인 결정을 캡처합니다[PW92]. 이러한 디자인 선택사항은 기능 및 보충 요구사항 및 기타 제한조건에 연결되어야 합니다. 그러나 이러한 선택사항은 다시 요구사항 및 하위 레벨의 향후 디자인 결정에 추가 제한조건을 설정합니다.

일반 아키텍처 보기 세트

아키텍처는 다양한 아키텍처 보기로 표시되며, 이 보기는 기본적으로 모델 중 "구조적으로 중요한" 요소를 표시하는 내용입니다. RUP에서는 "4+1 보기 모델이라고 하는 일반 보기 세트에서 시작합니다[KRU95]. 이는 다음과 같이 구성됩니다.

  • 유스 케이스 보기 - 구조적으로 중요한 동작, 클래스 또는 기술적 위험성을 포함하는 유스 케이스 및 시나리오가 포함되어 있습니다. 이 보기는 유스 케이스 모델의 서브세트입니다.
  • 논리 보기 - 가장 중요한 디자인 클래스 및 해당 조직이 패키지서브시스템에 포함되고 이러한 패키지 및 서브시스템의 조직이 계층에 포함됩니다. 이 보기에도 일부 유스 케이스 실현이 포함되어 있습니다. 이 보기는 디자인 모델의 서브세트입니다.
  • 구현 보기 - 구현 모델 및 모듈의 관점에서 패키지와 계층에 속한 해당 조직이 포함되어 있습니다. 논리 보기의 패키지 및 클래스를 구현 보기의 패키지 및 모듈에 할당하는 것도 설명되어 있습니다. 이 보기는 구현 모델의 서브세트입니다.
  • 프로세스 보기 - 관련 타스크(프로세스 및 스레드), 상호작용, 구성에 대한 설명 및 타스크에 할당된 디자인 오브젝트, 클래스가 포함되어 있습니다. 이 보기는 시스템에 상당한 정도의 동시성이 있는 경우에만 사용해야 합니다. RUP에서 이 보기는 디자인 모델의 서브세트입니다.
  • 배치 보기 - 가장 일반적인 플랫폼 구성의 다양한 실제 노드에 대한 설명 및 프로세스 보기에서 실제 노드로의 타스크 할당이 포함되어 있습니다. 이 보기는 시스템이 분산된 경우에만 사용해야 합니다. 이 보기는 배치 모델의 서브세트입니다.

아키텍처 보기는 소프트웨어 아키텍처 문서를 참조하십시오. 추가 보기를 사용자 정의하여 사용자 인터페이스 보기, 보안 보기, 데이터 보기 등의 다양한 특수 관심사항을 표현할 수 있습니다. 단순 시스템의 경우 4+1 보기 모델에 포함된 일부 보기를 생략할 수도 있습니다.

아키텍처 초점

위 보기는 시스템의 전체 디자인을 나타낼 수 있지만 아키텍처 관심사항 자체는 일부 특정 측면에만 관련됩니다.

  • 모델의 구조 - 조직 패턴(예: 계층화)
  • 기본 요소 - 핵심 유스 케이스, 기본 클래스, 공통 메커니즘 등이며 모델에 있는 모든 요소와는 반대됩니다.
  • 시스템에 걸친 기본 제어 플로우를 표시하는 일부 핵심 시나리오
  • 모듈화, 선택적 기능, 제품 라인 측면을 캡처하는 서비스

기본적으로 아키텍처 보기는 세부사항을 고려하지 않고 중요 특성을 더 잘 표시하도록 한 전체 디자인의 추상 또는 단순화입니다. 이들 특성은 다음을 추론할 때 중요합니다.

  • 다음 개발 주기로 발전하는 시스템
  • 제품 라인의 컨텍스트에서 아키텍처 또는 아키텍처 파트의 재사용
  • 성능, 가용성, 이식성 및 안전과 같은 보충 품질의 평가
  • 팀 또는 하청업체에게 개발 작업 배정
  • 상용 컴포넌트 포함에 대한 결정
  • 보다 대규모 시스템에 삽입

아키텍처 패턴

아키텍처 패턴은 재발하는 아키텍처 문제점을 해결하기 위해 미리 작성된 양식입니다. 아키텍처 프레임워크 또는 아키텍처 하부 구조(미들웨어)는 특정 유형의 아키텍처를 빌드할 수 있는 컴포넌트 세트입니다. 주요 아키텍처 문제는 대개 특정 도메인(명령 및 제어, MIS, 제어 시스템 등)을 대상으로 하는 프레임워크 또는 하부 구조에서 해결해야 합니다.

아키텍처 패턴 예제

[BUS96]은 보다 일반적인 구조 문제를 다루는 한 카테고리를 사용하여 가장 적용 가능한 시스템의 특성에 따라 아키텍처 패턴을 그룹화합니다. 이 표에는 BUS96]에 제공된 카테고리 및 카테고리에 포함된 패턴이 표시됩니다.

카테고리 패턴
구조 계층
파이프 및 필터
블랙보드
분산 시스템 브로커
대화식 시스템 모델-보기-제어기
표시-추상-제어
적응 시스템 반영
마이크로 커널

이 중 두 항목은 여기서 자세히 설명합니다. 전체에 대해서는 [BUS96]을 참조하십시오. 패턴은 다음과 같이 널리 사용되는 양식으로 제공됩니다.

  • 패턴 이름
  • 컨텍스트
  • 문제점
    • 고려해야 하는 다양한 문제점 측면을 설명하는 요소
  • 솔루션
    • 근거
    • 결과 컨텍스트
    • 예제
패턴 이름

계층

컨텍스트

분할이 필요한 대규모 시스템

문제점

서로 다른 추상 레벨에서 문제를 처리해야 하는 시스템.  예: 하드웨어 제어 문제, 공통 서비스 문제 및 도메인 관련 문제. 모든 레벨의 문제를 처리하는 수직 컴포넌트는 작성하지 마십시오. 동일한 문제를 여러 컴포넌트에서 여러 번(일관되지 않을 수 있음) 처리해야 하기 때문입니다.

요소

  • 시스템 파트는 대체 가능해야 합니다.
  • 컴포넌트의 변경은 주변에 영향을 주지 않아야 합니다.
  • 비슷한 책임을 함께 그룹화해야 합니다.
  • 컴포넌트 복합 컴포넌트의 크기는 분해해야 할 수도 있습니다. .
솔루션

시스템을 각각의 위에 계층을 형성하는 컴포넌트 그룹으로 구조화하십시오. 위쪽 계층에서 아래 계층의 서비스만 사용하도록 하십시오(위쪽은 사용 안함). 바로 아래 계층의 서비스 외에는 사용하지 마십시오(중간 계층이 통과 컴포넌트만 추가하지 않는 한 계층을 건너뛰지 않음).

예제:

1. 일반 계층

다이어그램은 컨텐츠에 설명되어 있습니다.

엄격하게 계층화된 아키텍처에서는 디자인 요소(클래스, 패키지, 서브시스템)가 디자인 요소 아래 계층의 서비스만 사용함을 나타냅니다. 서비스는 이벤트 처리, 오류 처리, 데이터베이스 액세스 등을 포함할 수 있습니다. 맨 아래 계층에 설명된 원시 운영 체제 레벨 호출과는 달리 보다 명확한 메커니즘을 포함합니다.

2. 비즈니스 시스템 계층

다이어그램은 컨텐츠에 설명되어 있습니다.

위 다이어그램에서는 수직 응용프로그램 특정 계층 및 수평 하부 구조 계층이 있는 다른 계층화 예제를 보여 줍니다. 비즈니스 "스토브파이프(stovepipe)"를 최소화하고 응용프로그램 전체에서 공통성을 높이는 것이 목적임을 명심하십시오. 이렇게 하지 않으면 동일한 문제를 여러 사람이 서로 다르게 해결하게 될 수 있습니다.

이 패턴에 대한 자세한 정보는 가이드라인: 계층화를 참조하십시오.

패턴 이름

블랙보드

컨텍스트

알려진 폐쇄(알고리즘식) 문제 해결 접근 방식이 없거나 실현 가능하지 않은 도메인. 예로는 AI 시스템, 음성 인식 및 감시 시스템이 있습니다.

문제점

개별 에이전트가 해결할 수 없는 문제점을 해결하려면 여러 문제점 해결 에이전트(지식 에이전트)가 협력해야 합니다. 개별 에이전트의 작업 결과에 다른 모든 에이전트가 액세스하여 솔루션 찾기 및 작업 결과 게시에 기여할 수 있는지 여부를 평가할 수 있어야 합니다.

요소

  • 지식 에이전트가 문제 해결에 기여할 수 있는 시퀀스는 결정적이 아니며 문제점 해결 전략에 따라 다를 수 있습니다.

  • 여러 에이전트의 입력(결과 또는 부분 솔루션)으로 인해 표시가 달라질 수 있습니다.

  • 에이전트는 서로의 존재를 직접 인식하지는 않지만 서로의 게시 결과를 평가할 수 있습니다.

솔루션

여러 지식 에이전트는 블랙보드라는 공유 데이터 스토어에 액세스할 수 있습니다. 블랙보드는 컨텐츠를 점검 및 갱신하는 인터페이스를 제공합니다. 제어 모듈/오브젝트는 특정 전략에 따라 에이전트를 활성화합니다. 활성화 시 에이전트는 해당 블랙보드를 검사하여 문제 해결에 기여할 수 있는지 확인합니다. 에이전트가 기여할 수 있다고 판단하면 제어 오브젝트를 사용하여 에이전트가 해당 부분 또는 최종 솔루션을 게시할 수 있습니다.

예제:

다이어그램은 컨텐츠에 설명되어 있습니다.

이 다이어그램은 UML을 사용하여 모델링한 구조적 또는 정적 보기를 표시합니다. 이 다이어그램은 매개변수화된 협업의 일부이며 실제 매개변수에 연결되어 패턴을 인스턴스화합니다.

아키텍처 스타일

소프트웨어 아키텍처 또는 아키텍처 보기에만 아키텍처 스타일이라는 속성이 있을 수 있으며, 이 속성은 선택할 수 있는 양식 세트를 줄이고 아키텍처에 특정 정도의 균일성을 제공합니다. 스타일은 패턴 세트 또는 기본 빌딩 블록으로서의 특정 컴포넌트 또는 커넥터 선택으로 정의할 수 있습니다. 특정 시스템에 대해, 일부 스타일을 아키텍처 스타일 안내서(RUP의 프로젝트 가이드라인 중간 산출물을 통해 제공)에 아키텍처 설명의 일부로 캡처할 수 있습니다. 스타일은 아키텍처의 이해도 및 무결성에 중요한 역할을 합니다.

아키텍처 청사진

아키텍처 보기의 그래픽 표현을 아키텍처 청사진이라고 합니다. 위에서 설명한 다양한 보기의 경우 청사진은 UML(Unified Modeling Language)[UML01]의 다음 다이어그램으로 구성됩니다.

  • 논리 보기. 클래스 다이어그램, 상태 머신 및 오브젝트 다이어그램
  • 프로세스 보기. 클래스 다이어그램 및 오브젝트 다이어그램(타스크 프로세스 및 스레드 포함)
  • 구현 보기. 컴포넌트 다이어그램
  • 배치 보기. 배치 다이어그램
  • 유스 케이스 보기. 유스 케이스, 액터 및 디자인 클래스를 표현한 유스 케이스 다이어그램, 디자인 오브젝트 및 해당 협업을 표현한 시퀀스 다이어그램

설계 프로세스

RUP에서 아키텍처는 주로 분석 및 디자인 워크플로우의 결과물입니다. 프로젝트에서 반복하여 이 워크플로우를 다시 규정함으로써 아키텍처는 발전하여 정제되고 다듬어집니다. 각 반복에는 통합 및 테스트가 포함되므로 아키텍처는 제품이 전달될 때가 되면 보다 강력해집니다. 이 아키텍처는 정제(Elaboration) 단계 반복의 기본 초점이며, 이 단계의 마지막에 일반적으로 아키텍처가 기준선 작성됩니다.