개념: 소프트웨어 구조
주제
소프트웨어 구조는 이해하기 쉽고 대부분의 엔지니어가 특히 적은 경험으로
직관적으로 느끼는 개념이지만 정확하게 정의하기 힘듭니다.
특히, 설계와 구조 간에 명확한 선을 긋는 것은 어려운 일입니다.
구조는 일부 특정 기능에 집중하는 설계의 한 측면입니다.
An Introduction to Software Architecture에서 David Garlan 및
Mary Shaw는 소프트웨어 구조가 문제와 관계되는 설계 레벨이라고 이야기합니다.
"계산의 알고리즘 및 데이터 구조를 넘어
전체 시스템 구조를 설계하고 지정하는 것이 문제점의 새로운 유형으로
떠오르고 있습니다.
구조적 문제에는 전체 구조 및 글로벌 제어 구조,
통신용 프로토콜, 동기화, 데이터 액세스, 기능을 설계 요소로 지정,
실제 분배, 설계 요소의 작성, 크기 지정 및 성능, 설계 대안 중 선택이 포함됩니다."[GAR93]
그러나 구조에는 단순한 구성 이상의 것이 있습니다.
구조에 대해 IEEE 작업 그룹은 "시스템 환경의
상위 레벨 시스템 개념"이라고 정의합니다[IEP1471].
또한 시스템 무결성, 경제적 제한조건, 미적 관심사 및 양식과의
"적응"을 포함하기도 합니다.
구조는 내부 초점에 제한되지 않지만 사용자 환경 및 개발 환경에서
전체적으로 시스템을 고려합니다(외부 초점).
RUP에서 소프트웨어 시스템의 구조(해당 시점)는
연속해서 더 작은 컴포넌트 및 인터페이스로 구성되는 컴포넌트와
인터페이스를 통해 상호 작용하는 중요한 시스템 컴포넌트의 조직 또는 구조입니다.
소프트웨어 구조에 대해 이야기하고 논하려면
먼저 구조적 표시(구조의 중요한 측면을 설명하는 방법)를 정의해야 합니다.
RUP에서 이 설명은 소프트웨어 구조 문서에 캡처됩니다.
다중 구조적 보기에서 소프트웨어 구조를 표시하기로 선택했습니다.
각 구조적 보기는 개발 프로세스의 스테이크홀더(일반 사용자, 설계자, 관리자, 시스템 엔지니어, 유지보수 담당자 등)에
특정한 일부 특정 관심사를 다룹니다.
보기는 소프트웨어 구조가 컴포넌트로 분해되는 방법과
컴포넌트가 커넥터에 의해 연결되어 유용한 양식을
생성하는 방법을 표시하여 주요 구조적 설계 결정을 캡처합니다[PW92].
이러한 설계 선택은 요구사항 및
기능적이고 보완적인 기타 제한조건과 연관되어야 합니다.
그러나 이러한 선택은 한층 더한 제한조건을 요구사항에 차례로 두고
on the requirements and on future
design decisions at a lower level.
구조는 본질적으로 "구조적으로 중요한" 모델 요소를 나타내는
추출인 여러 가지 구조적 보기로 표시됩니다.
RUP에서는 "4+1 보기 모델"이라는 전형적인 보기 세트에서 시작됩니다[KRU95].
이것은 다음으로 구성됩니다.
- 유스 케이스 보기 -
구조적으로 의미 있는 작동, 클래스 또는 기술 위험을 처리하는 유스 케이스 및 시나리오를
포함합니다. 이것은 유스 케이스 모델의 서브세트입니다.
- 논리적 보기 -
가장 중요한 설계 클래스 및
이러한 설계 클래스를 패키지 및
서브시스템으로 조직하는 것과
이러한 패키지 및 서브시스템을 계층으로
조직하는 것을 포함합니다. 또한 몇몇 유스 케이스
구현도 포함됩니다.
이것은 설계 모델의 서브세트입니다.
- 구현 보기 -
패키지 및 계층으로의 모듈에 의하여 구현 모델
및 구현 모델 구조의 개요을 포함합니다.
패키지 및 클래스(논리적 보기)를 구현 보기의 패키지 및 모듈에 할당하는 것도 설명됩니다.
이것은 구현 모델의 서브세트입니다.
- 프로세스 보기 -
연관된 타스크(프로세스 및 스레드), 이들의 상호 작용 및 형상,
객체 및 클래스를 타스크에 할당하는 것에 대한 설명을 포함합니다.
이 보기는 시스템에 상당한 정도의 동시성이 있는 경우에만 사용될 필요가 있습니다.
RUP에서 이것은 설계 모델의 서브세트입니다.
- 개발 보기 -
가장 전형적인 플랫폼 형상에 대한 다양한 실제 노드,
타스크(프로세스 보기)를 실제 노드로 할당하는 것에 대한 설명을 포함합니다.
이 보기는 시스템이 분산된 경우에만 사용될 필요가 있습니다.
이것은 전개 모델의 서브세트입니다.
구조적 보기는 소프트웨어
구조 문서에 문서화되어 있습니다.
여러 특수 관심사를 표시하기 위해 추가 보기를 계획할 수 있습니다(예:
사용자 인터페이스 보기, 보안 보기 및 데이터 보기 등).
단순 시스템의 경우, 4+1 보기 모델에 포함된 보기 중 일부를 생략할 수 있습니다.
위에 제시된 보기가 전체 시스템 설계를 표시할 수 있더라도
구조는 일부 특정 측면에만 관계합니다.
- 모델의 구조 - 구조적 패턴(예:계층화).
- 필수 요소 - 모델에 있는 모든 요소와 대립되는
중요한 유스 케이스, 기본 클래스, 공통 메커니즘 등.
- 시스템 전체의 기본 제어 플로우를 표시하는 몇몇 핵심 시나리오.
- 모듈성, 선택적 기능, 제품 라인 측면을 캡처하기 위한 서비스.
본질적으로, 구조적 보기는 전체 설계의 요약 또는 단순화입니다.
이 보기에서는 세부사항을 배제하여 중요한 특성을 잘 볼 수 있게 됩니다.
이러한 특성은 다음에 대해 논할 때 중요합니다.
- 시스템 전개(다음 개발 주기로 이동).
- 제품 라인의 컨텍스트에서 구조 또는 구조의 일부 재사용.
- 성능, 사용 가능성, 이식성 및 안전성과 같은 추가 품질 평가.
- 개발 작업을 팀 또는 하청 계약자에게 지정.
- 기존 컴포넌트 포함에 대한 결정.
- 보다 광범위한 시스템에 삽입.
구조적 패턴은
반복되는 구조적 문제점을 해결하는 준비된 양식입니다. 구조적 프레임워크 또는
구조적 인프라스트럭처(미들웨어)는 일정한 유형의 구조를 빌드할 수 있는
컴포넌트 세트입니다.
주요 구조적 어려움 대부분은 보통 특정 도메인(명령 및 제어, MIS, 제어 시스템 등)의 대상이 되는
프레임워크 또는 인프라스트럭처에서 해결되어야 합니다.
구조적 패턴의 예
[BUS96]은
보다 일반적인 구조화 문제를 처리하는 하나의 카테고리를 포함하는 가장 적용 가능한
시스템의 특성에 따라 구조적 패턴을 그룹화합니다.
테이블은 [BUS96]에 제시된
카테고리와 이 카테고리에 포함되는 패턴을 표시합니다.
카테고리 |
패턴 |
구조 |
계층 |
파이프 및 필터 |
블랙보드 |
분산 시스템 |
브로커 |
대화식 시스템 |
모델-보기-제어기 |
프리젠테이션-요약-제어 |
적응 시스템 |
반영 |
마이크로 커널 |
이러한 아이디어를 명확히 설명하기 위해
여기에 두 가지가 자세히 소개됩니다. 완전한 처리 방법은
[BUS96]을 참조하십시오.
다음과 같이 광범위하게 사용되는 양식으로 패턴이 제시됩니다.
- 패턴 이름
- 컨텍스트
- 문제점
- 고려되어야 할 여러 문제점 측면을 설명하는 실행
- 솔루션
패턴 이름
계층
컨텍스트
분해가 필요한 대형 시스템.
문제점
여러 추상화 레벨에서 문제를 처리해야 하는 시스템.
예: 하드웨어 제어 문제, 공통 서비스 문제 및 도메인 특정 문제.
모든 레벨에서 문제를 처리하는 수직 컴포넌트를 쓰는 것은 상당히 바람직하지 않을 수 있습니다.
동일한 문제가 다른 컴포넌트에서 여러 번 처리되어야 할 것입니다(아마도 일치되지 않게).
실행
- 시스템의 파트가 대체 가능해야 합니다.
- 컴포넌트의 변경이 파급을 일으켜서는 안됩니다.
- 유사한 책임이 함께 그룹화되어야 합니다.
- 컴포넌트 크기 - 복잡한 컴포넌트는 분해되어야 합니다.
솔루션
시스템을 각각의 맨 위에 계층을 형성하는 컴포넌트의 그룹으로 구조화시키십시오.
아래에 있는 계층의 서비스만 사용하는 계층(위에 있는 계층의 서비스는 절대 사용하지 않음)을 맨 위에 두십시오.
바로 아래에 있는 계층의 서비스 이외의 서비스는 사용하지 않도록 하십시오. (중간 계층이
pass-through 컴포넌트를 추가하지 않는 한 계층을 건너뛰지 마십시오.)
예:
1. 일반 계층

엄격하게 계층화된 구조는
설계 요소(클래스, 패키지, 서브시스템)가 그 아래 계층의 서비스만 사용한다는 것은
나타냅니다. 서비스에는 이벤트 처리, 오류 처리, 데이터베이스 액세스 등이 포함될 수
있습니다. 최하위 계층에 문서화된
원시 운영 체제 레벨 호출과 대립되는 명백한 메커니즘이 포함됩니다.
2. 비즈니스 시스템 계층

위의 다이어그램은 세로에는 어플리케이션 특정 계층이 있고
가로에는 인프라스트럭처 계층이 있는 다른 계층화 예를 표시합니다.
목표는 매우 짧은 비즈니스 "스토브파이프"를 가지고
어플리케이션에 걸쳐 공통성을 활성화시키는 것입니다. 그렇지 않으면,
여러 사람이 별도로 동일한 문제점을 해결하게 될 수도 있습니다.
이 패턴에 대한 자세한 정보는
가이드라인: 계층화를 참조하십시오.
패턴 이름
블랙보드
컨텍스트
문제점을 해결하는 완성된(알고리즘식의) 방법이 알려져 있지 않거나
가능성이 없는 도메인(예: Al 시스템, 음성 인식 및 감시 시스템).
문제점
여러 문제점 해결 에이전트(지식 에이전트)가 각 에이전트에서 해결할 수 없는
문제점을 해결하기 위해 협업해야 합니다.
각 에이전트의 작업 결과가 솔루션을 찾는 데 도움을 줄 수 있는지
평가하고 작업 결과를 게시할 수 있도록
기타 모든 에이전트에서 각 에이전트의 작업 결과에 액세스할 수 있어야 합니다.
실행
-
지식 에이전트가 문제점 해결에 기여할 수 있는 순서는
결정된 것이 아니라 문제점 해결 전략에 따라 다를 수 있습니다.
-
다른 에이전트(결과 또는 부분적 솔루션)로부터의 입력은
다르게 표시될 수 있습니다.
-
에이전트는 직접적으로 서로의 존재를 알지는 못하지만
서로의 게시된 기사를 평가할 수 있습니다.
솔루션
많은 지식 에이전트는 블랙보드라는 공유 데이터 저장에 액세스할 수 있습니다.
블랙보드는 컨텐츠를 검사하고 갱신하기 위한 인터페이스를 제공합니다.
제어 모듈/객체는 몇 가지 전략에 따르는 에이전트를 활성화합니다.
활성화 직후 에이전트는 블랙보드가 문제점 해결에 기여할 수 있는지를 알아보기 위해
블랙보드를 검사합니다.
에이전트에서 블랙보드가 기여할 수 있다고 판별하면
제어 객체는 에이전트가 보드에 부분적인(또는 최종) 솔루션을 놓을 수 있도록 합니다.
예:

이것은 UML을 사용하여 모델링되는 구조적 또는 정적 보기를 표시합니다.
이것은 실제 매개변수가 패턴을 인스턴스화하기 위해 바인드된
매개변수로 표시된 협업의 파트일 수 있습니다.
소프트웨어 구조 또는 구조적 보기만이
구조적 양식이라는 속성을 가짐으로써
선택 가능한 양식 세트를 줄이고
구조의 균일성을 일정 정도까지 강요합니다.
양식은 패턴 세트에 의해 정의될 수 있거나
특정 컴포넌트 또는 커넥터를 기본 빌딩 블록을 선택하여
정의될 수 있습니다.
제공된 시스템에서 일부 양식은 구조 양식 안내서의 구조적 설명 파트로 캡처될 수 있습니다.
. 양식은 구조의 이해도 및 무결성에서 중요한 파트를 수행합니다.
구조적 보기의 그래픽적 서술을 구조적 청사진이라고 합니다.
위에서 설명된 다양한 보기에 대해,
청사진은 UMF(Unified Modeling Language)[UML01]로 된
다음과 같은 다이어그램으로 구성됩니다.
- 논리적 보기. 클래스 다이어그램,
상태 시스템 및 객체 다이어그램
- 프로세스 보기. 클래스 다이어그램 및 객체
다이어그램(타스크(프로세스 및 스레드) 처리)
- 구현 보기.
컴포넌트 다이어그램
- 전개 보기. 전개 다이어그램
- 유스 케이스 보기.
유스 케이스, 액터 및 정규 설계 클래스를 서술하는 유스 케이스 다이어그램,
설계 객체 및 이들의 협업을 서술하는 순서 다이어그램.
RUP에서 구조는 근본적으로 분석 및 설계 워크플로우의
결과물입니다. 반복이 거듭됨에 따라 프로젝트가 이 워크플로우를 다시 규정하므로
구조가 전개되어 정제됩니다.
각 반복에 통합 및 테스트가 포함되므로 제품이 인도될 때 구조는 아주 견고합니다.
이 구조는 통상적으로 구조의 기준선이 정해지는 마지막 단계인
구현화 단계의 반복에서
주요한 초점이 됩니다.
|