주제
포트는 캡슐의 경계이므로 캡슐 외부 및 내부 모두에서 보일 수 있습니다. 외부에서 보는 경우 모든 포트는 침투할 수 없는 동일한 오브젝트 인터페이스를 표시하며 프로토콜에서 수행하는 역할 및 ID를 제외하고 구별할
수 없습니다. 그러나 캡슐 내부에서 보는 경우 포트는 릴레이 포트 및 종료 포트와 같은 두 종류 중 하나임을 확인할 수 있습니다. 내부 연결에서 차이가 납니다. 릴레이 포트는 서브캡슐에
연결된 반면, 종료 포트는 캡슐의 상태 머신에 연결되어 있습니다. 일반적으로 릴레이 포트는 내부 서브캡슐의 "인터페이스"를 선택적으로 내보내는 역할을 수행하는 반면, 종료 포트는 캡슐의 상태 머신에 대한 경계
오브젝트에 해당합니다. 릴레이 및 종료 포트 모두 캡슐의 경계에 나타날 수 있으며 알려진 대로, 외부와 구별할 수 없습니다.
릴레이 포트는 단순히 모든 신호가 통과하는 포트입니다. 해당 서브캡슐에서 실제로 외부 세계에 노출시키지 않고 외부 세계와 커뮤니케이션(및 이와 반대로)하기 위해 사용할 수 있는 캡슐의 캡슐화 쉘에
"입구"를 제공합니다. 릴레이 포트는 커넥터를 통해 서브캡슐에 연결되어 있으며 보통 외부에서 일부 다른 "피어" 캡슐로 연결되어 있습니다. 한 쪽 포트에서 들어오는 신호를 수신하여 단순히 다른 쪽 포트로 해당
신호를 릴레이하여 신호 플로우의 방향을 유지합니다. 다른 쪽 포트에 커넥터가 접속되어 있는 한, 정보가 유실되거나 지연되지 않고 이를 달성할 수 있습니다. 그렇지 않으면 신호가 유실됩니다.
릴레이 포트를 사용하면 캡슐의 상태 머신이 개입하지 않아도 캡슐에서 서브캡슐로 지정된 신호의 직접(오버헤드 0) 위임이 허용됩니다. 릴레이 포트는 캡슐의 경계에만 나타날 수 있으므로 항상 public
가시성을 가지고 있습니다.
도움이 되려면 마지막으로 상태 머신과 커뮤니케이션하는 종료 포트에서 커넥터 체인을 종료해야 합니다. 종료 포트는 캡슐의 상태 머신에 대한 경계 오브젝트입니다. (확인한 대로, 종료 포트 중 일부는 캡슐의 경계
오브젝트로도 제공됩니다.) 종료 포트는 기본 소스이자 캡슐이 송신하는 모든 신호가 처리되는 위치입니다. 이 신호는 캡슐의 상태 머신에서 생성됩니다. 상태 머신은 신호를 보내기 위해 해당 종료 포트 중 하나에서 송신
또는 호출 조작을 호출합니다. 그러면 신호는 접속된 커넥트를 통해 릴레이되어 다른 종료 포트(일반적으로 다른 캡슐에 있음)를 마지막으로 만날 때까지 하나 이상의 릴레이 포트 및 체인 커넥터를 통과합니다. 신호 기반
커뮤니케이션은 비동기일 수 있으므로 종료 포트에는 수신되었지만 아직 상태 머신에서 처리되지 않은 메시지를 보유하는 대기열이 있습니다. 즉, 편지함과 같은 역할을 수행합니다. 신호 수신 및 수신 상태 머신의
디스패치는 표준 UML 시맨틱에 따라 상태 머신에서 수행됩니다.
릴레이 포트와 같이 종료 포트는 public 가시성의 특징을 지닌 캡슐의 경계에 나타날 수 있습니다. 이 포트를 public 종료 포트라고 합니다. 이 포트는 상태 머신 및 포함 캡슐 모두의 경계
오브젝트입니다. 그러나 종료 포트는 내부 구현 구조의 파트로 캡슐 내부에 전체가 나타날 수도 있습니다. 상태 머신에서 외부 구현-지원 계층 또는 해당 서브캡슐과 커뮤니케이션하는 경우 이 포트를
사용합니다. 이 내부 종료 포트는 가시성이 보호되므로 protected 종료 포트라고 합니다.
포트 종류는 모두 캡슐 외부에서의 가시성 및 내부 연결성으로 판별됨에 유의하십시오. 다양한 용어(릴레이 포트, public 종료 포트, private 종료 포트)는 단순히 쓰기에 편리한 용어로 표현한 것입니다.
내부적으로 연결되지 않은 public 포트는 나중에 연결되었는지 또는 연결되지 않은 상태로 수신 신호를 처리하는 위치가 되었는지에 따라 릴레이 포트 또는 종료 포트가 될 수 있습니다.
외부 시점에서 포트는 포트입니다. 포트가 릴레이 포트인지 또는 종료 포트인지를 판별할 수 없거나 이러한 판별이 바람직하지도 않습니다. 그러나 캡슐을 분해하여 표시하면 캡슐 내부를 볼 수 있습니다. 종료 포트/릴레이
포트는 아래와 같이 그래픽으로 구별하여 표시합니다.
포트 표기법 - 커뮤니케이션 다이어그램(내부 보기)
실제로 동일한 캡슐에서 두 개 이상의 포트가 동일한 프로토콜을 사용하지만 시맨틱 측면에서는 서로 다른 경우가 종종 있습니다. 또한 동일한 신호가 다른 캡슐 포트에서 지원하는 둘 이상의 프로토콜 역할로 나타날 수
있습니다. 이 두 경우에서는 현재 신호를 수신하는 특정 종료 포트를 구별해야 할 수도 있습니다. 그러면 응용프로그램에서 상태 및 해당 신호의 소스에 따라 동일한 신호를 서로 다르게 처리할 수 있습니다. 여기에서는
이 트리거 유형을 포트 기반 트리거라고 합니다. 포트 기반 트리거는 특정 소스 포트에서 확인한 보호 조건을 사용하여 UML에서 모델링됩니다.
캡슐의 상태 머신 파트에 대한 스펙 및 올바른 프로토콜 시퀀스의 스펙은 표준 UML 상태 머신을 사용하여 완료되었습니다.
예상한 대로, 대부분의 실시간 시스템에서 첫 번째 관심사항은 바로 시간입니다. 일반적으로 시간에 기반한 상황의 두 가지 양식을 모델링해야 합니다. 특정 시간에 타스크를 트리거하는 기능 및 지정된
시점부터 특정 간격이 만기된 이후에 타스크를 트리거하는 기능이 이에 해당합니다.
대부분의 실시간 시스템에서는 시간 서비스라는, 타이밍 기능에 명시적으로 직접 액세스할 수 있어야 합니다(제어 가능). 표준 포트(서비스 액세스 지점)를 통해 액세스할 수 있는 이 서비스는 시간을
이벤트로 변환하여 기타 신호 기반 이벤트와 마찬가지 방식으로 처리될 수 있습니다. 예를 들어 이 서비스를 사용하는 경우 상태 머신은 특정 시간에 도달하거나 특정 간격이 만기된 경우 "제한시간" 이벤트를 통해 이
상황을 알리도록 요청할 수 있습니다.
개념적으로 캡슐은 다양한 방식으로 사용될 수 있습니다. 다양한 사용법을 위해 공통 캡슐 사용법을 다루도록 캡슐 계층 구조 및 분류법을 설명할 수 있습니다.
일반 계층 구조를 표시하는 캡슐 분류법
기본 캡슐 분류법은 다음과 같습니다.
-
캡슐
기본 캡슐, 부족한 포트, 내부 구조 또는 동작은 큰 관심사항이 아니며 많이 중요하지는 않습니다. 이 캡슐은 다른 캡슐이 파생되는 추상 캡슐을 정의할 때 사용할 수 있습니다. 포트, 구조 또는 동작을
정의하지 않으면 이 캡슐 유형은 나중에 정제되는 "플레이스홀더"를 정의하는 경우에만 유용합니다.
-
역할 유형
"역할 유형" 캡슐은 포트가 하나 이상인 추상 캡슐을 정의하는 캡슐 정의로 구성됩니다. 구조 또는 동작은 정의하지 않습니다. 이 캡슐 유형은 캡슐 세트의 "인터페이스"(포트)를 한 번 정의해야 하는
경우 사용됩니다. 이때 '역할 유형' 캡슐의 하위 유형에서 정의하는 인터페이스를 구체적으로 실현합니다.
-
역할 모델
"역할 모델" 캡슐은 잠재적으로 하나 이상의 포트 및 중첩되어 잠재적으로 상호 연결된 캡슐의 내부 구조(스펙 협업에서 정의함)를 통해 캡슐 정의로 구성됩니다.이 캡슐 유형은 시스템 구조의
"템플리트"를 정의할 때 사용됩니다. '세부사항'은 포함된 캡슐에 위임됩니다. 역할 모델 캡슐에 포트가 있으면 이 포트는 캡슐의 '인터페이스'를 정의합니다.
'역할 모델'의 동작은 지정되지 않습니다(정의된 상태 머신이 없음). 동작은 캡슐의 하위 유형에서 정의해야 합니다.
-
역할 실현(realization)
'역할 실현(realization)' 캡슐은 상태 머신을 통해 캡슐의 동작을 정의하지만 내부 구조나 인터페이스는 정의하지 않습니다. 본래 모든 파생 캡슐에 대한 동작의 추상 정의를 제공합니다. 그
다음 내부 구조 및 인터페이스를 차례대로 정의해야 합니다. 동작 정의는 '역할 실현(realization)' 캡슐에서 파생된 모든 캡슐이 만족해야 하는 '디자인 검증'으로 표시될 수 있습니다.
이러한 기본 유형을 혼합한 세 가지 유용한 합성물이 있습니다. 여기에서는 기본 정의가 혼합되어 표시됩니다.
-
유형화된 역할 실현(realization)
이 캡슐 유형은 캡슐 세트의 동작 및 인터페이스 모두를 정의하지만 파생 캡슐의 내부 구조는 제한하지 않습니다. 본래 '역할 실현(realization)' 캡슐이고 추가로 인터페이스를 정의합니다.
-
유형화된 역할 모델
이 캡슐 유형은 캡슐 세트의 동작 및 인터페이스를 정의하지만 해당 캡슐의 동작은 제한하지 않습니다. 이때 이점은 구조 및 인터페이스의 템플리트를 정의한다는 점입니다. 그러면 파생 캡슐에 필요한 대로
전문화될 수 있습니다.
-
역할 모델 실현(realization)
이 캡슐 유형은 캡슐의 내부 구조 및 해당 추상 동작을 정의하지만 인터페이스는 정의하지 않습니다. 이 캡슐 유형은 많은 캡슐에서 상당한 크기의 내부 구조 및 동작을 공유할 수는 있지만 인터페이스가
서로 다른 경우에 유용합니다.
나머지 캡슐 유형, '유형화된 역할 모델 실현(realization)'은 구조 및 인터페이스는 물론 구체적(내부 구조용) 및 추상(인터페이스용)인 경우에 동작을 정의합니다. 이 유형은 복잡하기 때문에 이해가 어려울
수 있습니다. 단독으로 올바르게 구현하십시오. 캡슐의 유닛 테스트를 캡슐 파트로 정의해야 하는 경우(따라서 별도의 상태 머신 두 개)를 위해 설명합니다. 대부분의 경우 이 구조는 사용하지 않는 것이 가장 좋습니다.
현재 캡슐의 RUP 표시는 UML 1.5 표기법에 기반함에 유의하십시오. 대부분은 개념: 구조화된
클래스를 사용하여 UML 2.0에 표시될 수 있습니다.
자세한 정보는 UML 1.x 및 UML 2.0의 차이점을 참조하십시오.
|