타스크: 디자인 요소 식별
이 타스크는 서브시스템, 클래스, 인터페이스, 이벤트 및 신호를 식별하는 방법을 설명합니다.
원칙: 분석 및 디자인
목적
  • 디자인 모델 요소를 식별하기 위해 분석 클래스의 상호작용을 분석합니다.
관계
기본 설명

타스크: 유스 케이스 분석의 결과는 분석 클래스이며, 이는 동작을 수행할 수 있는 개념적인 요소을 표시합니다. 디자인 시 분석 클래스는 다음 여러 가지 유형의 많은 디자인 요소로 발전합니다.

  • 더 세분화된 책임 세트를 표시하는 클래스
  • 덜 세분화된 책임 세트를 표시하는 서브시스템(차후 서브시스템 세트로 구성될 수 있지만 궁극적으로 클래스 세트로 구성됨)
  • 시스템의 스레드를 표시하는 활성 클래스
  • 클래스 또는 서브시스템이 제공하는 책임의 추상 선언을 표시하는 인터페이스.

또한 디자인 시 다음도 식별합니다.

  • 시간과 공간에서 관심있는 발생의 스펙인 이벤트(대개(주목할 만한 경우) 시스템에서 약간의 응답을 필요로 함).
  • 시스템 내에서 특정 유형의 이벤트를 통신하는 데 사용되는 비동기 메커니즘을 표시하는 신호.

이러한 자세한 구별을 통해 디자인의 여러 측면을 점검할 수 있습니다.

  • 이벤트 및 이벤트를 통신하는 데 사용되는 신호를 사용하여 시스템이 응답해야 하는 동작의 비동기 트리거를 설명할 수 있습니다.
  • 클래스와 서브시스템을 사용하여 관련된 책임을 상대적인 독립성을 갖고 개발할 수 있는 단위로 그룹화할 수 있습니다. 클래스는 관련 책임의 원자 세트를 이행하는 반면, 서브시스템은 다시 다른 서브시스템의 클래스로 구성되는 컴포지트 빌딩 블록입니다. 서브시스템은 개발 팀의 중간 산출물을 하나의 통합 기능성 단위로 표시하는 데 사용되며, 따라서 논리적 디자인 요소뿐 아니라 제어 및 형상 관리의 단위로 사용됩니다.
  • 활성 클래스는 시스템의 제어 스레드를 표시하는 데 사용되며 동시성의 모델링을 허용합니다. 활성 클래스는 대개(반드시 그렇지는 않음) 수동적인 다른 클래스와의 조합으로 종종 사용됩니다. 그런 조합을 (협업과 같은 방법으로) 사용하여 복잡한 동작을 모델링할 수 있습니다.

    실시간 시스템에서는 캡슐이 활성 클래스 대신 사용되어 디자인을 단순화하고 동시 응용프로그램의 신뢰성을 증가시키기 위한 더 강력한 시맨틱을 제공합니다. 캡슐은 클래스 및 서브시스템 모두의 일부 측면을 공유합니다. 이들은 사실 함께 시스템의 제어 스레드를 표시하는 클래스의 캡슐화된 협업입니다. 캡슐이 단일 디자이너의 책임인 반면 서브시스템은 개발자 팀의 책임(일반적으로)이라는 면에서 캡슐은 서브시스템과 다릅니다. 서브시스템이 캡슐을 포함할 수 있습니다. 

  • 인터페이스를 사용하면 시스템의 "접합부"를 점검하고 캡처하여 시스템의 구성 파트가 상호동작하는 방법을 정확하게 정의할 수 있습니다.
  • 실시간 시스템에서는 프로토콜을 사용하여 캡슐의 포트에서 송수신될 수 있는 메시지를 정확하게 정의해야 합니다.

관심사항을 구분하고 이러한 개념에 의해 표시되는 각 문제를 개별적으로 처리함으로써 디자인 프로세스를 단순화하고 솔루션을 명백하게 설명합니다.

추적성이 시스템 모델 사이에 유지되어야 하는 경우 이 타스크 중에 문서화되어야 합니다. 디자인 모델과 기타 시스템 모델 사이의 추적성 문서화에 대한 자세한 정보는 가이드라인: 디자인 모델을 참조하십시오.

 UML 1.x 표시

UML 1.5에 따르면 서브시스템은 사실상 인터페이스만 공용 요소로 갖는 특별한 종류의 패키지입니다. 인터페이스는 캡슐화 계층을 제공함으로써 서브시스템의 내부 디자인이 다른 모델 요소로부터 숨겨지도록 합니다. 서브시스템 개념은 시맨틱과 무관한 모델 요소 컨테이너인 "일반" 패키지와 구별하는 데 사용됩니다. 즉 서브시스템은 클래스 유사(작동) 특성을 갖는 패키지의 특정 사용법을 표시합니다.

RUP에서 캡슐은 UML 1.5 표기법을 사용하여 표시됩니다. 대부분은 개념: 구조화된 클래스를 사용하여 UML 2.0으로 표시될 수 있습니다.

자세한 정보는 UML 1.x 및 UML 2.0의 차이점을 참조하십시오.

단계
이벤트 및 신호 식별
목적 시스템이 응답해야 하는 외부/내부 이벤트와 신호를 식별합니다. 

이벤트는 시스템 내에서 어떤 조치를 유발하는 외부 및 내부 발생입니다. 이벤트 및 해당 특성은 활성 클래스 같은 핵심 디자인 요소의 식별에 도움이 될 수 있습니다.

외부 이벤트의 초기 목록은 유스 케이스 모델, 유스 케이스와 액터의 상호작용으로부터 파생될 수 있습니다. 내부 이벤트는 유스 케이스 플로우로부터 파생되거나 디자인이 전개됨에 따라서 식별될 수 있습니다.

이벤트의 중요한 특성은 다음과 같습니다.

  • 내부 대 외부 - 이벤트가 외부적입니까 아니면 내부적입니까?
  • 우선순위 - 이 이벤트가 처리되기 위해서 다른 처리를 일시중단시켜야 합니까?
  • 빈도 - 이벤트가 얼마나 자주 발생합니까?
  • 빈도 분배 - 이벤트가 일정한 간격으로 발생합니까 아니면 급격한 상승이 있습니까?
  • 응답 요구사항 - 시스템이 얼마나 빨리 이벤트에 응답해야 합니까(평균적인 경우와 최악의 경우 사이를 구분해야 할 수 있음)
  • 유형 - 호출 이벤트, 시간 이벤트, 신호 이벤트 또는 변경 이벤트입니까(정의는 개념: 이벤트 및 신호 참조)?

이벤트의 특성은 이벤트를 처리하는 디자인 요소의 식별을 추진하기 위해 필요한 대로 캡처되어야 합니다. 이벤트 특성 캡처는 반응식(이벤트 기반) 시스템에서 가장 중요하지만, 동시성 및/또는 비동기 메시지 전달의 경우와 같은 다른 시스템에서도 유용할 수 있습니다.

비동기 통신 이벤트는 해당 이벤트가 전달하는 데이터를 표현하기 위해 또는 일반화와 같이 신호 사이의 관계를 표현하기 위해 신호로서 모델링될 수 있습니다. 일부 시스템, 특히 반응식 시스템에서는 외부 장치로부터 수신되는 신호를 인터럽트 또는 특정 폴링 메시지 같은 특정 메커니즘에 관련시켜야 합니다.

클래스, 활성 클래스 및 서브시스템 식별
목적 분석 클래스를 적절한 디자인 모델 요소로 정제합니다. 

클래스를 식별하십시오. 분석 클래스가 단순하고 이미 단일 논리 추상을 표시하는 경우 디자인 클래스에 직접 1:1 맵핑될 수 있습니다. 일반적으로 엔티티 클래스는 디자인에서 상대적으로 온전하게 남아 있습니다. 또한 엔티티 클래스는 일반적으로 지속적이므로, 디자인 클래스가 지속적이어야 하는지 판별하고 이를 클래스 설명에 적절히 기록하십시오.

클래스를 식별할 때 클래스는 조직 및 형상 관리 목적을 위해 중간 산출물: 디자인 패키지로 그룹화되어야 합니다. 패키징을 결정하는 방법에 대한 자세한 정보는 중간 산출물 가이드라인: 디자인 패키지를 참조하십시오.

활성 클래스를 식별하십시오. 식별된 분석 오브젝트의 컨텍스트에서 시스템의 동시성 요구사항을 고려하십시오. 외부적으로 생성되는 이벤트에 시스템이 응답해야 합니까? 응답해야 하는 경우 이벤트가 발생할 때 어떤 분석 클래스가 '활성'입니까? 유스 케이스 모델의 외부 이벤트는 액터에서 오고 유스 케이스와 상호작용하는 자극(stimuli)에 의해 표시됩니다. 해당 유스 케이스 실현을 살펴보고 이벤트가 발생할 때 상호작용하는 오브젝트를 확인하십시오. 오브젝트를 협업 오브젝트의 자율 세트로 함께 그룹화하면서 시작하십시오. 이들 그룹은 컴포지트 활성 클래스를 형성할 수 있는 그룹의 초기 부분을 표시합니다.

이벤트에 캡처해야 하는 중요한 속성이 있는 경우 이들을 스테레오타입화된 <<signal>>인 클래스로 모델링하는 것을 고려하십시오. 실시간 시스템에서는 이들 식별된 오브젝트 세트가 강력한 캡슐화 시맨틱을 갖는 캡슐로 그룹화되어야 합니다.

활성 클래스의 인스턴스는 독립된 '논리' 실행 스레드를 표시합니다. 이러한 '논리' 실행 스레드는 운영 체제의 실행 스레드와 혼동하거나 글자 그대로 맵핑되어서는 안됩니다(그러나 어느 시점에서 운영 체제 실행 스레드에 이를 맵핑함). 대신 솔루션 공간의 독립된 개념적 실행 스레드를 표시합니다. 디자인의 이 시점에서 이들을 식별하는 목적은 시스템의 자연적인 '동시성 접합부'를 기반으로 솔루션을 독립 단위로 파티션하기 위한 것입니다. 이런 식으로 작업을 나누면 기반 수동 클래스를 공유하는 범위를 제외하고 독립 실행 스레드를 개별적으로 다룰 수 있으므로 동시성 처리 문제점이 개념적으로 더 단순하게 됩니다.

일반적으로 문제점 도메인에 동시성 및 동시성 충돌이 있을 때마다 활성 클래스를 고려해야 합니다. 일부 외부 동시 오브젝트 또는 컴퓨터 내의 동시 활동을 표시하는 데 활성 클래스를 사용해야 합니다. 이는 동시 활동을 모니터하고 제어하는 능력을 제공합니다.

실제 엔티티는 원래 동시이므로 컴퓨터에 연결되는 외부 실제 장치의 내부 표시로 활성 클래스를 사용하는 것이 또 다른 자연스런 선택이 됩니다. 이러한 "장치 드라이버" 클래스는 해당 실제 장치를 모니터하고 제어하는 서비스를 제공할 뿐 아니라 장치의 특정사항에서 시스템의 나머지를 분리합니다. 이는 장치 이면의 기술이 발달하는 경우에도 시스템의 나머지가 영향을 받지 않을 수 있음을 의미합니다.

활성 클래스의 또 다른 공통적인 사용 방법은 논리적 동시 활동을 표시하는 것입니다. 논리 활동은 개념적 동시 "오브젝트"를 표시합니다(예: 금융 거래 또는 전화 통화_. 이들이 실제 엔티티로서 직접 증명되지 않는다는 사실에도 불구하고(현실 세계에서 발생하는 경우에도) 종종 이와 같이 취급하는 이유가 있습니다. 예를 들어, 동시성 충돌을 막기 위해 특정 금융 거래를 일시적으로 보류해야 하거나 시스템 내부 장애로 인해 중단해야 할 수 있습니다. 이러한 개념적 오브젝트는 하나의 단위로 조작되어야 하므로 적절한 기능적 성능을 제공하는 고유한 인터페이스를 갖는 오브젝트로 표시하는 것이 편리합니다.

이 유형의 개념 오브젝트의 특별한 예제로 활성 오브젝트 제어기가 있습니다. 목적은 하나 이상의 다른 활성 오브젝트를 지속적으로 관리하는 것입니다. 여기에는 일반적으로 각 오브젝트를 원하는 작동 상태로 만들고, 부분 장애와 같은 다양한 혼란에 맞서 해당 상태로 유지하는 작업을 포함합니다. 이러한 활성 오브젝트 제어기는 보통 타스크: 유스 케이스 분석 중에 식별되는 제어 오브젝트로부터 전개됩니다.

단순하고 우수하게 동시성 충돌을 해결하는 능력을 가지는 활성 클래스는 공유 자원의 감시자로서도 유용합니다. 이 경우 다중 동시 활동에서 필요한 하나 이상의 자원이 활성 클래스 내에 캡슐화됩니다. 내장된 상호 배타적 시맨틱을 통해 감시자가 이들 자원을 동시성 충돌로부터 자동으로 보호합니다.

실시간 시스템의 경우 활성 클래스 대신 캡슐이 사용되어야 합니다. 위에서 설명한 방법에 따라서 활성 클래스에 대한 필요가 식별될 때마다 캡슐로 대체해야 합니다.

서브시스템을 식별하십시오. 분석 클래스가 복잡할 경우(예: 따로 동작하는 단일 클래스의 책임이 될 수 없는 동작을 구현하는 것처럼 보임), 분석 클래스는 디자인 서브시스템에 맵핑되어야 합니다. 서브시스템에서 제공하는 서비스를 사용하는 경우에도, 서브시스템의 클라이언트가 서브시스템의 내부 디자인을 전혀 몰라도 되는 방식으로 이 협업을 캡슐화하는 데 디자인 서브시스템이 사용됩니다.

서브시스템은 인터페이스만 공용 요소로 갖는 UML 컴포넌트로서 모델링됩니다. 인터페이스는 캡슐화 계층을 제공함으로써 서브시스템의 내부 디자인이 다른 모델 요소로부터 숨겨지도록 합니다. 서브시스템 개념은 시맨틱과 무관한 모델 요소 컨테이너인 패키지와 구별하는 데 사용됩니다.

협업 분석 클래스 세트로부터 서브시스템을 작성하는 결정은 협업이 개별 디자인팀에 의해 독립적으로 개발될 수 있거나 개발될 지 여부에 크게 의존합니다. 협업이 해당 협업 클래스와 함께 패키지에 완전히 포함될 수 있으면, 서브시스템은 단일 패키지에서 제공하는 것보다 더 강력한 양식의 캡슐화를 제공할 수 있습니다. 서브시스템의 컨텐츠 및 협업은 하나 이상의 인터페이스 이면에서 완전히 분리되므로 서브시스템의 클라이언트는 인터페이스에만 종속됩니다. 그러면 서브시스템의 디자이너가 외부 종속성에서 완전히 분리됩니다. 디자이너(또는 디자인 팀)는 인터페이스를 실현하는 방법을 지정해야 합니다. 하지만 외부 종속성에 영향을 주지 않고 내부 서브시스템 디자인을 자유롭게 변경할 수 있습니다. 거의 독립적인 팀으로 구성되는 대규모 시스템에서는, 정규 인터페이스가 제공하는 아키텍처 실행과 함께 이 분리 정도가 단순한 패키지 대신 서브시스템을 선택하는 데 매우 중요한 인수가 됩니다. 서브시스템을 디자인 요소로 사용하도록 선택하는 데 영향을 주는 요소에 대한 자세한 정보는 중간 산출물 가이드라인: 디자인 서브시스템을 참조하십시오.

서브시스템 인터페이스 식별
목적 시스템의 접합부의 형식을 만드는 디자인 요소를 식별합니다. 

인터페이스는 일부 클래스류에 의해 실현되는 오퍼레이션 세트를 정의합니다. 디자인 모델에서 인터페이스는 주로 서브시스템의 인터페이스를 정의하는 데 사용됩니다. 이는 인터페이스를 클래스에 사용할 수 없음을 의미하지는 않지만, 대개 단일 클래스의 경우 사실상 해당 '인터페이스'를 정의하는 클래스에 대한 공용 오퍼레이션을 정의하는 것으로 충분합니다. 동작(인터페이스를 실현하는 서브시스템 내의 특정 클래스)으로부터 동작(인터페이스)의 선언 분리를 허용하기 때문에 서브시스템에서는 인터페이스가 중요합니다. 이 분리는 시스템의 여러 파트에 대해 작업하는 개발 팀의 독립성을 증가시키면서 이러한 여러 파트 사이의 '계약'의 정확한 정의를 유지하는 방법을 제공합니다.

각 서브시스템에 대해 후보 인터페이스의 세트를 식별하십시오. 이전 단계에서 식별되는 그룹화된 협업을 사용하여 협업이 시작될 때 '활성화'되는 책임을 식별하십시오. 그런 다음 '클라이언트'가 제공해야 하는 정보와 협업이 완료될 때 리턴되는 정보를 판별하여 이 책임을 정제해야 합니다. 이러한 정보 세트가 서브시스템이 실현할 오퍼레이션에 대한 프로토타입 입력 및 출력 매개변수와 리턴값이 됩니다. 중간 산출물: 프로젝트 가이드라인에서 정의되는 이름 지정 규칙을 사용하여 이 오퍼레이션에 대한 이름을 정의하십시오. 서브시스템이 실현할 오퍼레이션이 모두 정의될 때까지 이를 반복하십시오.

다음으로, 관련 특성에 따라서 오퍼레이션을 함께 그룹화하십시오. 그룹에 적은 수의 오퍼레이션이 있을 때 응집력있는 공통 책임 세트가 존재할 가능성이 크므로 큰 그룹보다 작은 그룹이 바람직합니다. 재사용도 염두에 두십시오. 관련 재사용가능 기능성을 더 쉽게 식별할 수 있게 해주는 유사성을 찾으십시오. 그렇지만 이상적인 책임 그룹을 찾는 데 많은 시간을 소비하지는 마십시오. 이는 단순히 첫 번째 결과이며 정제(Elaboration) 단계 전체에서 반복적으로 정제가 진행됨을 기억하십시오.

인터페이스 사이의 유사성을 찾으십시오. 인터페이스의 후보 세트에서 비슷한 이름, 비슷한 책임 및 비슷한 오퍼레이션을 찾으십시오. 여러 인터페이스에 동일한 오퍼레이션이 존재하는 경우 인터페이스를 다시 분해하여 공통 오퍼레이션을 새 인터페이스로 추출하십시오. 기존 인터페이스도 살펴보고 가능하면 재사용하십시오. 목적은 인터페이스 사이의 중복 오퍼레이션을 제거하면서 인터페이스의 응집성을 유지하는 것입니다. 이는 인터페이스를 이해하기 쉽고 시간이 흐름에 따라서 전개하기 쉽게 만듭니다.

인터페이스 종속성을 정의하십시오. 각 인터페이스 오퍼레이션의 매개변수와 리턴값은 각각 특정 유형을 갖습니다. 이들은 특정 인터페이스를 실현해야 하거나 단순 데이터 유형의 인스턴스여야 합니다. 매개변수가 특정 인터페이스를 실현하는 오브젝트인 경우 인터페이스와 해당 인터페이스가 의존하는 인터페이스 사이의 종속성 관계를 정의하십시오. 종속성 인터페이스가 디자인 모델의 요소 사이의 기본 종속성을 정의하므로, 인터페이스 사이의 종속성을 정의하면 소프트웨어 설계자에게 유용한 결합 정보가 제공됩니다.

인터페이스를 서브시스템에 맵핑하십시오. 인터페이스가 식별된 후, 서브시스템과 서브시스템이 실현하는 인터페이스 사이의 실현(realization) 연관을 작성하십시오. 서브시스템에서 인터페이스로의 실현은 인터페이스의 오퍼레이션을 실현하는 하나 이상의 요소가 서브시스템 내에 있음을 표시합니다. 나중에 서브시스템이 디자인될 때 서브시스템 디자이너가 인터페이스의 오퍼레이션을 실현하는 서브시스템 내의 특정 요소를 지정하면서 이러한 서브시스템-인터페이스 실현도 정제됩니다. 이렇게 정제된 실현은 서브시스템 디자이너에게만 보입니다. 서브시스템 클라이언트의 관점에서는 서브시스템-인터페이스 실현만이 보입니다.

인터페이스에 의해 지정되는 동작을 정의하십시오. 인터페이스는 종종 인터페이스를 실현하는 요소에 대해 내재적 상태 머신을 정의합니다. 인터페이스에 대한 오퍼레이션이 특정 순서로 호출되어야 하는 경우(예: 데이터베이스를 사용하려면 먼저 데이터베이스 연결을 열어야 함), 인터페이스를 실현하는 모든 디자인 요소가 지원해야 하는, 공개적으로 보이는(또는 추론된) 상태를 표시하는 상태 머신이 정의되어야 합니다. 이 상태 머신은 인터페이스 사용자가 인터페이스를 보다 잘 이해하도록 도와주며 인터페이스를 실현하는 요소의 디자이너가 해당 요소에 대해 올바른 동작을 제공하도록 도와줍니다.

인터페이스를 패키징하십시오. 인터페이스는 소프트웨어 설계자의 소유이며, 인터페이스에 대한 변경은 항상 구조적으로 중요합니다. 이를 관리하기 위해 소프트웨어 설계자가 소유하는 하나 이상의 패키지로 인터페이스를 그룹화해야 합니다. 각 인터페이스가 단일 서브시스템에 의해 실현되는 경우 인터페이스가 서브시스템과 함께 동일한 패키지에 배치될 수 있습니다. 인터페이스가 둘 이상의 서브시스템에 의해 실현되는 경우 소프트웨어 설계자가 소유하는 개별 패키지 내에 위치해야 합니다. 이를 통해 인터페이스가 서브시스템 자체와 독립적으로 관리 및 제어될 수 있습니다.

캡슐 프로토콜 식별

목적

시스템의 접합부의 형식을 만드는 디자인 요소를 식별합니다(RT 디자인 전용).

프로토콜은 이벤트 기반 시스템의 인터페이스와 비슷합니다. 즉, 독립된 제어 스레드 사이에서 통신하는 데 사용되는 해당 신호 세트를 정의하여 캡슐 사이의 '계약'을 식별합니다. 인터페이스가 주로 호출의 함수 호출 모델을 사용하여 동기 메시지 전달을 정의하는 데 사용되는 반면, 프로토콜은 주로 신호 기반 메시지 전달을 사용하여 비동기 통신을 정의하는 데 사용됩니다. 프로토콜은 동작 실현(인터페이스를 실현하는 서브시스템 내의 요소)에서 동작의 선언(신호 세트)의 분리를 허용합니다. 이 분리는 시스템의 여러 파트에 대해 작업하는 개발 팀의 독립성을 증가시키면서 이러한 여러 파트 사이의 '계약'의 정확한 정의를 유지하는 방법을 제공합니다.

각 캡슐에 대해 입력 및 출력 신호 세트를 식별하십시오. 이전 단계에서 식별되는 그룹화된 협업을 사용하여 협업이 시작될 때 '활성화'되는 책임을 식별하십시오. 그런 다음 '클라이언트'가 제공해야 하는 정보와 협업이 완료될 때 리턴되는 정보를 판별하여 이 책임이 정제됩니다. 이러한 정보 세트가 캡슐이 포트 중 하나를 통해 실현할 신호에 대한 프로토타입 입력 매개변수가 됩니다. 중간 산출물: 프로젝트 가이드라인에서 정의되는 이름 지정 규칙을 사용하여 이 신호에 대한 이름을 정의하십시오. 캡슐이 실현할 신호가 모두 정의될 때까지 이를 반복하십시오.

다음으로, 관련 책임에 따라서 신호를 함께 그룹화하십시오. 그룹에 적은 수의 오퍼레이션이 있을 때 응집력있는 공통 책임 세트가 존재할 가능성이 크므로 큰 그룹보다 작은 그룹이 바람직합니다. 재사용도 염두에 두십시오. 관련 재사용가능 기능성을 더 쉽게 식별할 수 있게 해주는 유사성을 찾으십시오. 그렇지만 이상적인 책임 그룹을 찾는 데 많은 시간을 소비하지는 마십시오. 이는 단순히 첫 번째 결과이며 정제(Elaboration) 단계 전체에서 반복적으로 정제가 진행됨을 기억하십시오. 프로토콜이 캡슐 협업에서 수행하는 역할을 설명하는 의미있는 이름을 프로토콜에 부여하십시오.

프로토콜 사이의 유사성을 찾으십시오. 프로토콜의 후보 세트에서 비슷한 이름, 비슷한 책임 및 비슷한 신호를 찾으십시오. 여러 프로토콜에 동일한 신호가 존재하는 경우 프로토콜을 다시 분해하여 공통 신호를 새 인터페이스로 추출하십시오. 기존 프로토콜도 살펴보고 가능하면 재사용하십시오. 목적은 프로토콜 사이의 중복 신호를 제거하면서 프로토콜의 응집성을 유지하는 것입니다. 이는 인터페이스를 이해하기 쉽고 시간이 흐름에 따라서 전개하기 쉽게 만듭니다.

프로토콜을 캡슐에 맵핑하십시오. 프로토콜이 식별되면 프로토콜을 실현하는 캡슐에 포트를 작성하십시오. 캡슐의 포트는 캡슐에서 요청될 수 있는 동작인 해당 '인터페이스'를 정의합니다. 나중에 캡슐이 디자인될 때 포트에 의해 지정되는 동작은 캡슐에 대한 상태 머신에 의해 설명됩니다.

프로토콜에 의해 지정되는 동작을 정의하십시오. 프로토콜은 종종 인터페이스를 실현하는 요소에 대한 내재적 상태 머신을 정의합니다. 인터페이스의 입력 신호가 특정한 순서로 수신되어야 하는 경우(예: '시스템 준비' 신호가 수신된 후에야 특정 오류 신호가 수신될 수 있음), 프로토콜을 실현하는 모든 디자인 요소가 지원해야 하는 공개적으로 보이는(또는 추론된) 상태를 표시하는 상태 머신이 정의되어야 합니다. 이 상태 머신은 프로토콜을 실현하는 캡슐의 사용자가 해당 동작을 보다 잘 이해하도록 도와주며 캡슐 디자이너가 해당 요소에 대해 올바른 동작을 제공하도록 도와줍니다.

프로토콜을 패키징하십시오. 프로토콜은 소프트웨어 설계자의 소유이며, 프로토콜에 대한 변경은 항상 구조적으로 중요합니다. 이를 관리하기 위해 소프트웨어 설계자가 소유하는 하나 이상의 패키지로 프로토콜을 그룹화해야 합니다. 이를 통해 해당 프로토콜을 실현하는 캡슐과 독립적으로 프로토콜을 관리 및 제어할 수 있습니다.


자세한 정보