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

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

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

이는 UML을 사용하여 모델링되는 구조적 또는 정적 보기를 표시합니다.
매개변수로 표시된 협업의 파트일 수 있으며, 실제 매개변수로 바인드되어 패턴을 인스턴트화합니다.
소프트웨어 구조 또는 구조적 보기만
구조적 양식 속성을 가짐으로써 선택 가능한 양식 세트를 줄이고
구조의 균일성을 특정 정도까지 강요합니다. 양식은 패턴 세트에 의해 정의되거나
특정 컴포넌트 또는 커넥터를 기본 빌드 블록을 선택하여 정의될 수 있습니다.
제공된 시스템에서 일부 양식은 구조 양식 안내서의 구조적 설명 파트로 캡처될 수 있습니다.
양식은 구조의 이해도 및 무결성에서 중요한 파트를 수행합니다.
구조 스타일의 새로 나타나는 중요한 예는 SOA(Service-Oriented
Architecture)입니다. SOA는 예를 들어 비즈니스 유스 케이스에
캡처된 비즈니스 프로세스의 일부 또는 전부를 수행하는 비즈니스 기능과
유사한 서비스를 서비스 계층을 통해 제공하기 위해 객체 지향 및 컴포넌트 기반 개발을 빌드하는
전개적 단계입니다. 컴포넌트를 통해 서비스를 제공할 수 있지만 서비스는 컴포넌트 세트의 협업을
관리하여(하위 레벨 비즈니스 엔티티에 맵핑) 정제되지 않은 고가치 비즈니스 기능을
제공한다는 점에서 복합적 측면을 갖고 있습니다. 이런 개념은
계속 발전하고 있으며 SOA의 필수 특성에 대한 정밀성 또는 용어에 대해 보편적인 동의는 아직 없지만
일반적으로 다음과 같이 받아들여지고 있습니다.
- 서비스는 사용자와 제공자 간의 느슨한 결합을 허용해야 합니다. 사용자는 동적으로 서비스를
발견하고(예: 레지스트리나 브로커를 통해), 서비스 호출 기간 동안 서비스 인터페이스 계약을
맺어야 합니다.
- 어플리케이션 및 기타 서비스와의 상호 작용은 메시지 기반 의사소통 모델을 통해 흔히 비동기로 발생합니다.
- 서비스는 자원 세트를 관리하며, 서비스 자체가 stateless인 경우가 많고 값 객체를 요청자에게 전달합니다.
SOA에 대해 자세히 알아보려면 IBM Rational Software 백서
"SOA(Service-Oriented Architecture) 및 컴포넌트
기반 개발을 사용하여 웹 서비스 어플리케이션 빌드"를 참조하십시오.
구조적 보기를 그래픽으로 묘사한 것을 구조적 청사진이라고 합니다. 위에 설명한 여러 보기에 대해,
청사진은 다음과 같은 UMF(Unified Modeling Language)의
다이어그램으로 구성됩니다[UML01].
- 논리적 보기. 클래스 다이어그램,
상태 시스템 및 객체 다이어그램
- 프로세스 보기. 클래스 다이어그램 및 객체
다이어그램(타스크(프로세스 및 스레드) 처리)
- 구현 보기.
컴포넌트 다이어그램
- 전개 보기. 전개 다이어그램
- 유스 케이스 보기.
유스 케이스, 액터 및 보통 설계 클래스를 서술하는 유스 케이스 다이어그램,
설계 객체 및 이들의 협업을 서술하는 순서 다이어그램
RUP에서 구조는 기본적으로 분석 및 설계 워크플로우의
결과물입니다. 반복이 거듭됨에 따라 프로젝트가 이 워크플로우를 다시 규정하므로
구조가 전개되어 정제됩니다. 각 반복마다 통합 및 테스트가 포함되므로 제품이 인도될 때 구조는 아주 견고해집니다.
이 구조는 보통 기준선이 정해지는 마지막 단계인
구현 단계의 반복에서
주요한 초점이 됩니다.
|