중간 산출물: 캡슐
이 아티팩트는 시스템의 캡슐화된 제어 스레드를 나타내는 구체적인 디자인 패턴입니다.
관계
역할책임이 있음: 수정자:
입력 대상필수: 선택사항:
  • 없음
외부:
  • 없음
산출 지점
기본 설명

캡슐은 높은 수준의 동시성을 갖춘 시스템을 모델링하고 디자인하는 데 유용한 것으로 입증된 특정 패턴의 클래스 구조 및 컴포지션을 나타냅니다. 입증된 특정 디자인 패턴에 대한 간단한 표기법으로 캡슐을 사용하면 오류를 적게 내면서 쉽게 디자인할 수 있습니다.

캡슐은 클래스, 즉 스테레오타입화된 <<capsule>>로 표현됩니다. 캡슐은 아래 그림에 설명된 것처럼 컴포지트 요소입니다.

함께 표시된 텍스트에서 설명되는 다이어그램

캡슐 컴포지션

위에서 설명한 것처럼 캡슐에는 포트가 있을 수 있으며 수동 클래스 및/또는 하위 캡슐을 "포함"할 수 있습니다. 또한 캡슐의 동작을 완벽하게 설명하는 상태 머신도 포함되어 있을 수 있습니다. 캡슐의 구체적인 분류 및 캡슐을 사용하는 다양한 방법에 대해서는 가이드라인: 캡슐에서 자세히 설명합니다.

특성
선택사항
계획됨Yes
사용자 조정
표시 옵션UML 표시: <<capsule>>로 스테레오타입화된 클래스. 이 표시법은 UML 1.5 표기법을 기준으로 합니다. 대부분은 개념: 구조화된 클래스를 사용하여 UML 2.0으로 표시될 수 있습니다. 자세한 정보는 UML 1.x와 UML 2.0의 차이점을 참조하십시오.

캡슐은 아래 그림에 설명된 것처럼 컴포지트 요소입니다.

컴포지트 요소 다이어그램

캡슐 컴포지션

캡슐에는 포트가 있을 수 있으며 수동 클래스 및/또는 하위 캡슐을 "포함"할 수 있습니다. 또한 캡슐의 동작을 완벽하게 설명하는 상태 머신도 포함되어 있을 수 있습니다. 캡슐의 구체적인 분류 및 캡슐을 사용하는 다양한 방법에 대해서는 가이드라인: 캡슐에서 자세히 설명합니다.

특성

캡슐은 제어 스레드를 캡슐화합니다. 캡슐은 시스템의 독립적인 제어 스레드를 추상화한 것입니다. 이는 시스템 동시성의 기본 단위입니다. 추가로 제어 스레드를 고립시키려면 운영 체제 프로세스 및 스레드를 사용하여 캡슐을 특정 운영 체제 프로세스 및 스레드로 맵핑하면 됩니다. 캡슐로 가는 메시지는 포트를 통해 도착하며 연속적으로 처리됩니다. 캡슐 인스턴스가 사용 중이면 메시지는 대기열에 저장됩니다. 캡슐은 RTC(Run-to-completion) 시맨틱을 강제하므로 이벤트가 수신되면 도착된 다른 이벤트의 수나 우선순위에 상관없이 해당 이벤트가 완전하게 처리됩니다.

캡슐은 포트를 통해 주변 환경과 상호작용합니다. 포트는 신호 기반의 경계 오브젝트입니다. 즉, 외부 세계와 캡슐의 상호작용을 중재합니다. 포트는 특정 인터페이스를 구현하며 특정 인터페이스에 종속될 수 있습니다. 캡슐에는 포트 이외의 조작 또는 공용 부분이 없습니다. 따라서 포트는 외부 세계와 상호작용하기 위한 유일한 수단입니다.

각 포트는 협업 내에서 특정 역할을 수행합니다. 협업은 캡슐이 다른 오브젝트와 상호작용하는 방법을 설명합니다. 이러한 상호작용의 복잡한 시맨틱을 캡처하려면 캡슐의 연결된 포트 간의 유효한 정보(신호) 플로우를 정의하는 프로토콜과 포트가 연관되어 있어야 합니다. 프로토콜은 캡슐 간에 존재하는 계약상의 의무사항을 캡처합니다. 캡슐이 포트를 통해서만 통신하도록 함으로써 캡슐을 둘러싼 환경과 캡슐의 내부적 구현을 완전히 분리할 수 있습니다. 이를 통해 캡슐을 재사용할 수 있는 가능성이 커집니다.

간단한 캡슐의 기능은 캡슐의 상태 머신을 통해 직접 구현됩니다. 복잡한 캡슐은 커넥터에 의해 결합된 협업하는 하위 캡슐내부 네트워크와 상태 머신을 결합합니다. 이러한 하위 캡슐은 자체 권한을 갖는 캡슐이며 다시 하위 캡슐로 분해할 수 있습니다. 이러한 유형의 분해는 필요한 수준만큼 이루어질 수 있으므로 이러한 기본적인 구조적 모델링 구조만으로도 복잡한 구조의 모델링이 가능합니다. 상태 머신(컴포지트 캡슐의 경우 선택적임), 하위 캡슐, 연결 네트워크는 캡슐 구현의 일부를 나타내며 외부 관찰자에게는 숨겨집니다.

캡슐은 컴포지트 요소일 수 있습니다. 캡슐은 다른 캡슐 및 수동 클래스로 구성됩니다. 캡슐 및 수동 클래스는 협업 내의 링크 또는 커넥터에 의해 함께 결합됩니다. 이 협업은 캡슐의 '구조'를 정의하며 '스펙 협업'이라고 합니다. 캡슐에는 캡슐의 종료 포트를 통해 신호를 송수신하고 내부 구조의 특정 요소를 제어하는 상태 머신이 있을 수 있습니다. 따라서 이 상태 머신은 반영 동작 즉, 캡슐 자체의 오퍼레이션이 제어하는 동작을 구현하는 것으로 간주될 수 있습니다.

포트 

포트는 캡슐 인스턴스의 경계 오브젝트 역할을 하는 것이 목적인 오브젝트입니다. 포트는 캡슐과 함께 작성되어 캡슐이 파기될 때 소실되는 점으로 보아 캡슐 인스턴스에 의해 "소유"된다고 할 수 있습니다. 파트가 컨테이너와 구분되는 정도와 동일하게 각 포트는 자신이 소유하는 캡슐 인스턴스의 ID 및 상태와 구분되는 ID와 상태를 갖습니다.

포트는 인터페이스 역할을 하는 경계 오브젝트이지만 직접 UML 인터페이스로 맵핑되지는 않습니다. UML 인터페이스는 순수하게 동작적입니다. 즉 이 인터페이스를 구현하는 구조가 없습니다. 하지만 포트는 구조 및 동작 모두를 포함합니다. 포트는 단순히 동작에 대한 제한조건이 아니라 캡슐 구조의 컴포지트 파트입니다. 포트는 "Manifest 인퍼페이스"라고 할 수 있는 아키텍처 패턴을 실현합니다.

UML에서 포트를 <<port>> 스테레오타입을 사용하여 클래스로 모델링할 수 있습니다. 앞에서 설명한 것처럼 포트의 유형은 해당 포트가 수행하는 프로토콜 역할에 의해 정의됩니다. 프로토콜 역할이 추상 클래스이므로 이 인스턴스에 대응하는 실제 클래스는 포트와 연관된 프로토콜 역할을 구현하는 클래스입니다. UML에서 포트와 프로토콜 역할 사이의 관계를 실현 관계라고 합니다. 이를 표기하는 방법은 스펙 끝에 점선으로 된 단색 삼각형 화살표를 그리면 됩니다. 이는 일반화 양식으로, 소스 요소(포트)가 대상(프로토콜 역할)의 구조가 아니라 동작 스펙만을 상속합니다.

캡슐은 포트와의 컴포지션 관계로 이루어져 있습니다. 이 관계 끝의 대상의 다중성이 하나보다 클 경우 이는 런타임에 포트의 다중 인스턴스가 존재함을 의미합니다. 각 인스턴스는 프로토콜의 별도 인스턴스에 참여합니다. 다중성이 일정 범위의 값인 경우 이는 포트의 수가 런타임에 달라질 수 있으며 포트가 동적으로 작성되고 제거될 수 있음(제한조건에 따를 가능성이 있음)을 의미합니다.

포트를 나타내는 캡슐 다이어그램

포트, 프로토콜 및 프로토콜 역할

위의 그림에서는 CapsuleClassA 캡슐 클래스에 속하는 b라는 단일 포트의 예를 보여줍니다. 이 포트는 ProtocolA 프로토콜 클래스에 의해 정의된 프로토콜의 마스터 역할을 실현합니다. 실제 포트 클래스, PortClassX는 구현별로 달라지는 구현 클래스이므로 구현 단계 전까지는 모델러가 이 구현 클래스에 관심을 기울이지 않습니다. 모델러가 관심을 갖는 정보는 이 포트가 구현하는 프로토콜 역할입니다. 이 이유 및 표기법 규약때문에 그림 1에 나타난 표기법은 일반적으로 사용되지 않으며 다음 절에서 설명하는 더욱 압축된 양식을 대신 사용합니다.

표기법

클래스 다이어그램에서 볼 수 있는 것처럼 캡슐 포트는 특수 레이블이 붙은 목록 컴파트먼트로 열거됩니다. 포트 목록 컴파트먼트는 일반적으로 속성 및 연산자 목록 컴파트먼트 뒤에 나타납니다. 이 표기법은 특별한 이름이 붙은 컴파트먼트를 추가하도록 허용하는 UML 기능의 장점을 활용합니다.

포트의 클래스 다이어그램

포트 표기법 - 클래스 다이어그램 표시

내부 포트는 보호된 가시성이라는 특징을 갖지만(예: 포트 b2) 모든 외부 포트(릴레이 포트 및 공용 종료 포트)는 공용 가시성이라는 특징을 가집니다. 프로토콜 역할 이름은 주어진 프로토콜의 범위 내에서만 고유하지만 포트의 프로토콜 역할(유형)은 일반적으로 경로 이름으로 식별됩니다. 예를 들어 포트 b는 ProtocolA라는 프로토콜 클래스에서 정의된 마스터 역할을 합니다. 가장 흔한 이진 프로토콜의 경우 더 간단한 표기법 규약이 사용됩니다. 접미부 틸데 기호("~")를 사용하여 변경된 프로토콜 역할(예: 포트 b2)을 식별하며 기본 역할 이름은 특별한 표기법 없이 표시됩니다(예: 포트 b1). 1 이외의 다중성을 갖는 포트는 대괄호 사이에 다중성 요인이 포함되어 있습니다. 예를 들어 포트 b1[3]의 다중성 요인은 정확히 3이며 b5[0..2] 포트는 2를 넘지 않는 다양한 수의 인스턴스를 가집니다.

커넥터

커넥터는 특별한 신호 기반 프로토콜을 지원하기 위한 전송 기능을 제공하는 통신 채널을 나타냅니다. 커넥터의 주요 기능은 커넥터와 연관된 프로토콜에서 보완적인 역할을 하는 포트와만 상호 연결하는 것입니다. 원칙적으로 프로토콜 역할은 동일한 프로토콜에 속하지 않아도 되지만 이 경우 커넥터의 프로토콜과 호환되어야만 합니다.

커넥터는 둘 이상의 포트를 상호 연결하는 신호 기반 통신 채널을 추상적인 관점에서 본 것입니다. 연결에 의해 바인드되는 포트는 한 프로토콜에서 상호 보완적이면서 호환되는 역할을 해야 합니다. 협업 다이어그램에서 이들 포트는 적절한 포트를 상호 연결하는 연관된 역할에 의해 표시됩니다. 이 그림에서 포트를 추상화해 버리면 커넥터는 캡슐 간의 핵심 통신 관계를 실제로 캡처합니다. 이 관계는 직접 통신을 통해 서로 영향을 줄 수 있는 캡슐을 식별하므로 구조적으로 의미를 가집니다. 포트는 정보 은닉 및 관심 분리라는 원칙에 따라 캡슐의 캡슐화를 허용하기 위해 포함됩니다.

커넥터와 프로토콜이 유사하기 때문에 이 두 개념이 동일하다고 생각할 수도 있습니다. 그러나 프로토콜은 원하는 동작의 추상 스펙인 반면, 커넥터는 한 포트에서 다른 포트로 신호를 전송하기만 하는 물리적 오브젝트이므로 둘은 다릅니다. 일반적으로 커넥터는 수동 콘딧입니다. 실제로 실제 커넥터는 지정된 동작에서 벗어난 경우도 있습니다. 예를 들어 내부 오류로 인해 커넥터에서 메시지가 손실, 재정렬 또는 중복될 수 있습니다. 이러한 유형의 실패는 분산된 통신 채널에서는 흔한 일입니다.

커넥터는 대응하는 캡슐 클래스의 둘 이상의 포트 사이에 존재하는 연관에 의해 모델링됩니다. 커넥터가 물리적 특성을 갖는 고급 응용프로그램의 경우 커넥터가 실제로는 상태 및 ID를 갖는 오브젝트이므로 연관 클래스가 사용될 수 있습니다. 포트와 마찬가지로, 커넥터를 실현하는 데 사용된 실제 클래스는 구현과 관련된 문제입니다. 지원된 프로토콜과의 관계는 연결된 포트를 통해 암시적으로 표현됩니다. 결과적으로 커넥터를 나타내기 위해 UML 확장은 필요하지 않습니다.

스펙 협업

캡슐의 완벽한 내부 구조는 스펙 협업으로 표현됩니다. 이 협업에는 포트, 하위 캡슐 및 커넥터 모두의 스펙이 포함됩니다. 포트와 마찬가지로 하위 캡슐 및 커넥터는 캡슐에 의해 소유되며 캡슐과 별개로 존재할 수 없습니다. 따라서 캡슐이 작성될 때 작성되고 캡슐이 제거될 때 제거됩니다.

구조의 일부 하위 캡슐은 이를 포함하는 캡슐과 동시에 작성될 수 없습니다. 대신 캡슐의 상태 머신에 의해 필요한 경우 나중에 작성될 수 있습니다. 상태 머신도 캡슐처럼 아무 때나 제거될 수 있습니다. 이 경우 컴포지션에 대한 UML 규칙을 따릅니다.

캡슐 구조에는 플러그인 역할이 포함될 수 있습니다. 이는 실제로는, 동적으로 채워지는 하위 캡슐에 대한 플레이스홀더입니다. 런타인에 해당 역할을 하는 구체적인 오브젝트를 항상 미리 알 수 있는 것은 아니므로 이러한 플레이스홀더가 필요합니다. 이 정보가 일단 제공되면 적절한 캡슐 인스턴스(일부 다른 컴포지트 캡슐에 의해 소유됨)를 슬롯에 "꽂을" 수 있으며 포트가 협업 내의 다른 하위 캡슐과 결합된 커넥터가 자동으로 설정됩니다. 더 이상 동적 관계가 필요 없는 경우 캡슐은 플러그인 슬롯에서 "제거되며" 커넥터가 분해됩니다.

동적으로 작성된 하위 캡슐 및 플러그인을 사용하면 캡슐 사이의 유효한 모든 통신 및 포함 관계를 명시적으로 지정하면서, 동적으로 변하는 구조를 모델링할 수 있습니다. 이는 복잡한 실시간 시스템에서 아키텍처 무결성을 보장하기 위해 반드시 필요합니다.

포트도 스펙 협업 다이어그램에 나타날 수 있습니다. 이 다이어그램에서 오브젝트는 적절한 클래스류 역할 즉, 캡슐 역할로 분류된 하위 캡슐 및 포트 역할로 분류된 포트로 표현됩니다. 시각적인 혼란을 없애기 위해 포트 역할은 일반적으로 아이콘화되어 작은 검은색 또는 흰색 사각형으로 표시됩니다. 앞의 그림처럼, 공용 포트는 대응하는 캡슐 역할의 경계 사이에 있는 포트 역할 아이콘으로 표시됩니다. 이렇게 간단히 표시함으로써 불필요하게 선을 교차할 필요 없이 캡슐 내부 및 외부 양쪽에서 연결될 수 있으며 경계 오브젝트로 명확하게 식별할 수 있습니다.

공용 포트 및 캡슐 역할 다이어그램

포트 표기법 - 스펙 협업 다이어그램

레이블은 포트 역할을 설명하는 것뿐이므로 커넥터의 연관 종료점 이름과 혼동해서는 안 됩니다. 또한 포트는 이름으로 고유하게 식별되므로 그림을 쉽게 그리기 위해 공용 포트 역할을 하위 캡슐 상자 경계선 주변에 순서 없이 배열할 수 있습니다. 되도록 커넥터 선과 겹치지 않도록 하기 위해 이 방법을 사용할 수 있습니다.

2진 프로토콜의 경우 추가 스테레오타입 아이콘을 사용할 수 있습니다. 활용 역할을 하는 포트는 흰색(대 검은색) 사각형으로 표시됩니다. 이 경우 프로토콜 이름 및 틸데 접미부만으로 프로토콜 역할을 활용 역할로 식별할 수 있습니다. 프로토콜 역할 이름은 중복되며 생략되어야 합니다. 마찬가지로 검은색 사각형에 프로토콜 이름만을 사용하면 이는 프로토콜의 기본 역할을 나타냅니다. 예를 들어, ProtQ 프로토콜의 "마스터" 역할이 기본으로 선언되면 아래 그림 및 위의 그림의 다이어그램은 같은 그림이 됩니다. 이러한 규약에 의해 보완 프로토콜 역할이 연결되는 시기를 쉽게 알 수 있습니다.

프로토콜 역할 다이어그램

2진 프로토콜의 표기법 규약

다중성 요인이 1보다 큰 포트는 다음 그림에 표시된 것처럼 표준 UML 다중 오브젝트 표기법으로도 나타낼 수 있습니다. 이는 의무 사항은 아니지만(다중성 문자열만으로 충분함) 포트의 다중 인스턴스가 가능하다는 것을 강조합니다.

다중 오브젝트의 UML 다이어그램

다중성 요인이 1보다 큰 포트

상태 머신

캡슐과 연관된 선택적인 상태 머신은 캡슐 구현의 다른 부분일 뿐입니다. 그러나 여기에는 캡슐의 다른 구성 요소와 구분되는 특별한 특성이 있습니다.

  • 더 이상 하위 캡슐로 분해할 수 없습니다. 상태 머신은 직접 동작을 지정합니다. 그러나 상태 머신은 표준 UML 기능을 사용하여 더 단순한 상태 머신의 계층 구조로 분해할 수 있습니다.
  • 캡슐당 최소한 하나의 상태 머신이 있을 수 있습니다. 그러나 하위 캡슐은 자체 상태 머신만을 가질 수 있습니다. 상태 머신이 없는 캡슐은 하위 캡슐의 단순 컨테이너입니다.
  • 상태 머신은 캡슐의 종료 포트에 도착하는 신호를 처리하며 이들 포트를 통해 신호를 송신할 수 있습니다.
  • 상태 머신은 캡슐 내의 보호된 내부 파트에 액세스할 수 있는 유일한 엔티티입니다. 이는 상태 머신이 다른 모든 하위 캡슐의 제어기 역할을 한다는 것을 의미합니다. 따라서 동적으로 식별되는 하위 캡슐을 작성하고 제거할 수 있으며 해당되는 외부 하위 캡슐을 꽂거나 제거할 수 있습니다.

동적으로 작성된 하위 캡슐은 변수 다중성 요인으로 단순하게 표시됩니다. 플러그인 슬롯과 마찬가지로 순수한 인터페이스 유형으로 지정될 수 있습니다. 이는 인스턴스화되는 시기에 해당 인터페이스를 지원하는 구현 클래스가 인스턴스화될 수 있다는 것을 의미합니다. 이 특징은 구조적 스펙에 대한 보편성을 위해 제공됩니다.

이러한 추가적인 제한사항에도 불구하고 캡슐과 연관된 상태 머신은 UML 클래스류와 상태 머신 사이의 표준 링크에 의해 모델링됩니다. 캡슐의 구현/분해는 클래스류와 연관될 수 있는 표준 UML 협업에 의해 모델링됩니다.  

자세한 정보
체크리스트
가이드라인