목적
|
시스템의 접합부의 형식을 만드는 디자인 요소를 식별합니다.
|
인터페이스는 일부 클래스류에 의해 실현되는 오퍼레이션 세트를 정의합니다. 디자인 모델에서 인터페이스는 주로 서브시스템의 인터페이스를 정의하는 데 사용됩니다. 이는 인터페이스를 클래스에 사용할 수 없음을 의미하지는
않지만, 대개 단일 클래스의 경우 사실상 해당 '인터페이스'를 정의하는 클래스에 대한 공용 오퍼레이션을 정의하는 것으로 충분합니다. 동작(인터페이스를 실현하는 서브시스템 내의 특정 클래스)으로부터
동작(인터페이스)의 선언 분리를 허용하기 때문에 서브시스템에서는 인터페이스가 중요합니다. 이 분리는 시스템의 여러 파트에 대해 작업하는 개발 팀의 독립성을 증가시키면서 이러한 여러 파트 사이의 '계약'의 정확한
정의를 유지하는 방법을 제공합니다.
각 서브시스템에 대해 후보 인터페이스의 세트를 식별하십시오. 이전 단계에서 식별되는 그룹화된 협업을 사용하여 협업이 시작될 때 '활성화'되는 책임을 식별하십시오. 그런 다음 '클라이언트'가 제공해야
하는 정보와 협업이 완료될 때 리턴되는 정보를 판별하여 이 책임을 정제해야 합니다. 이러한 정보 세트가 서브시스템이 실현할 오퍼레이션에 대한 프로토타입 입력 및 출력 매개변수와 리턴값이 됩니다. 중간 산출물: 프로젝트 가이드라인에서 정의되는 이름 지정 규칙을 사용하여 이 오퍼레이션에 대한 이름을 정의하십시오.
서브시스템이 실현할 오퍼레이션이 모두 정의될 때까지 이를 반복하십시오.
다음으로, 관련 특성에 따라서 오퍼레이션을 함께 그룹화하십시오. 그룹에 적은 수의 오퍼레이션이 있을 때 응집력있는 공통 책임 세트가 존재할 가능성이 크므로 큰 그룹보다 작은 그룹이 바람직합니다. 재사용도 염두에
두십시오. 관련 재사용가능 기능성을 더 쉽게 식별할 수 있게 해주는 유사성을 찾으십시오. 그렇지만 이상적인 책임 그룹을 찾는 데 많은 시간을 소비하지는 마십시오. 이는 단순히 첫 번째 결과이며
정제(Elaboration) 단계 전체에서 반복적으로 정제가 진행됨을 기억하십시오.
인터페이스 사이의 유사성을 찾으십시오. 인터페이스의 후보 세트에서 비슷한 이름, 비슷한 책임 및 비슷한 오퍼레이션을 찾으십시오. 여러 인터페이스에 동일한 오퍼레이션이 존재하는 경우 인터페이스를 다시
분해하여 공통 오퍼레이션을 새 인터페이스로 추출하십시오. 기존 인터페이스도 살펴보고 가능하면 재사용하십시오. 목적은 인터페이스 사이의 중복 오퍼레이션을 제거하면서 인터페이스의 응집성을 유지하는 것입니다. 이는
인터페이스를 이해하기 쉽고 시간이 흐름에 따라서 전개하기 쉽게 만듭니다.
인터페이스 종속성을 정의하십시오. 각 인터페이스 오퍼레이션의 매개변수와 리턴값은 각각 특정 유형을 갖습니다. 이들은 특정 인터페이스를 실현해야 하거나 단순 데이터 유형의 인스턴스여야 합니다. 매개변수가
특정 인터페이스를 실현하는 오브젝트인 경우 인터페이스와 해당 인터페이스가 의존하는 인터페이스 사이의 종속성 관계를 정의하십시오. 종속성 인터페이스가 디자인 모델의 요소 사이의 기본 종속성을 정의하므로, 인터페이스
사이의 종속성을 정의하면 소프트웨어 설계자에게 유용한 결합 정보가 제공됩니다.
인터페이스를 서브시스템에 맵핑하십시오. 인터페이스가 식별된 후, 서브시스템과 서브시스템이 실현하는 인터페이스 사이의 실현(realization) 연관을 작성하십시오. 서브시스템에서
인터페이스로의 실현은 인터페이스의 오퍼레이션을 실현하는 하나 이상의 요소가 서브시스템 내에 있음을 표시합니다. 나중에 서브시스템이 디자인될 때 서브시스템 디자이너가 인터페이스의 오퍼레이션을 실현하는 서브시스템 내의
특정 요소를 지정하면서 이러한 서브시스템-인터페이스 실현도 정제됩니다. 이렇게 정제된 실현은 서브시스템 디자이너에게만 보입니다. 서브시스템 클라이언트의 관점에서는 서브시스템-인터페이스 실현만이 보입니다.
인터페이스에 의해 지정되는 동작을 정의하십시오. 인터페이스는 종종 인터페이스를 실현하는 요소에 대해 내재적 상태 머신을 정의합니다. 인터페이스에 대한 오퍼레이션이 특정 순서로 호출되어야 하는 경우(예:
데이터베이스를 사용하려면 먼저 데이터베이스 연결을 열어야 함), 인터페이스를 실현하는 모든 디자인 요소가 지원해야 하는, 공개적으로 보이는(또는 추론된) 상태를 표시하는 상태 머신이 정의되어야 합니다. 이 상태
머신은 인터페이스 사용자가 인터페이스를 보다 잘 이해하도록 도와주며 인터페이스를 실현하는 요소의 디자이너가 해당 요소에 대해 올바른 동작을 제공하도록 도와줍니다.
인터페이스를 패키징하십시오. 인터페이스는 소프트웨어 설계자의 소유이며, 인터페이스에 대한 변경은 항상 구조적으로 중요합니다. 이를 관리하기 위해 소프트웨어 설계자가 소유하는 하나 이상의 패키지로
인터페이스를 그룹화해야 합니다. 각 인터페이스가 단일 서브시스템에 의해 실현되는 경우 인터페이스가 서브시스템과 함께 동일한 패키지에 배치될 수 있습니다. 인터페이스가 둘 이상의 서브시스템에 의해 실현되는 경우
소프트웨어 설계자가 소유하는 개별 패키지 내에 위치해야 합니다. 이를 통해 인터페이스가 서브시스템 자체와 독립적으로 관리 및 제어될 수 있습니다.
목적
|
시스템의 접합부의 형식을 만드는 디자인 요소를 식별합니다(RT 디자인 전용).
|
프로토콜은 이벤트 기반 시스템의 인터페이스와 비슷합니다. 즉, 독립된 제어 스레드 사이에서 통신하는 데 사용되는 해당 신호 세트를 정의하여 캡슐 사이의 '계약'을 식별합니다. 인터페이스가 주로 호출의 함수 호출
모델을 사용하여 동기 메시지 전달을 정의하는 데 사용되는 반면, 프로토콜은 주로 신호 기반 메시지 전달을 사용하여 비동기 통신을 정의하는 데 사용됩니다. 프로토콜은 동작 실현(인터페이스를 실현하는 서브시스템 내의
요소)에서 동작의 선언(신호 세트)의 분리를 허용합니다. 이 분리는 시스템의 여러 파트에 대해 작업하는 개발 팀의 독립성을 증가시키면서 이러한 여러 파트 사이의 '계약'의 정확한 정의를 유지하는 방법을 제공합니다.
각 캡슐에 대해 입력 및 출력 신호 세트를 식별하십시오. 이전 단계에서 식별되는 그룹화된 협업을 사용하여 협업이 시작될 때 '활성화'되는 책임을 식별하십시오. 그런 다음 '클라이언트'가 제공해야 하는
정보와 협업이 완료될 때 리턴되는 정보를 판별하여 이 책임이 정제됩니다. 이러한 정보 세트가 캡슐이 포트 중 하나를 통해 실현할 신호에 대한 프로토타입 입력 매개변수가 됩니다. 중간 산출물: 프로젝트 가이드라인에서 정의되는 이름 지정 규칙을 사용하여 이 신호에 대한 이름을 정의하십시오. 캡슐이 실현할
신호가 모두 정의될 때까지 이를 반복하십시오.
다음으로, 관련 책임에 따라서 신호를 함께 그룹화하십시오. 그룹에 적은 수의 오퍼레이션이 있을 때 응집력있는 공통 책임 세트가 존재할 가능성이 크므로 큰 그룹보다 작은 그룹이 바람직합니다. 재사용도 염두에
두십시오. 관련 재사용가능 기능성을 더 쉽게 식별할 수 있게 해주는 유사성을 찾으십시오. 그렇지만 이상적인 책임 그룹을 찾는 데 많은 시간을 소비하지는 마십시오. 이는 단순히 첫 번째 결과이며
정제(Elaboration) 단계 전체에서 반복적으로 정제가 진행됨을 기억하십시오. 프로토콜이 캡슐 협업에서 수행하는 역할을 설명하는 의미있는 이름을 프로토콜에 부여하십시오.
프로토콜 사이의 유사성을 찾으십시오. 프로토콜의 후보 세트에서 비슷한 이름, 비슷한 책임 및 비슷한 신호를 찾으십시오. 여러 프로토콜에 동일한 신호가 존재하는 경우 프로토콜을 다시 분해하여 공통 신호를
새 인터페이스로 추출하십시오. 기존 프로토콜도 살펴보고 가능하면 재사용하십시오. 목적은 프로토콜 사이의 중복 신호를 제거하면서 프로토콜의 응집성을 유지하는 것입니다. 이는 인터페이스를 이해하기 쉽고 시간이 흐름에
따라서 전개하기 쉽게 만듭니다.
프로토콜을 캡슐에 맵핑하십시오. 프로토콜이 식별되면 프로토콜을 실현하는 캡슐에 포트를 작성하십시오. 캡슐의 포트는 캡슐에서 요청될 수 있는 동작인 해당 '인터페이스'를 정의합니다. 나중에
캡슐이 디자인될 때 포트에 의해 지정되는 동작은 캡슐에 대한 상태 머신에 의해 설명됩니다.
프로토콜에 의해 지정되는 동작을 정의하십시오. 프로토콜은 종종 인터페이스를 실현하는 요소에 대한 내재적 상태 머신을 정의합니다. 인터페이스의 입력 신호가 특정한 순서로 수신되어야 하는 경우(예:
'시스템 준비' 신호가 수신된 후에야 특정 오류 신호가 수신될 수 있음), 프로토콜을 실현하는 모든 디자인 요소가 지원해야 하는 공개적으로 보이는(또는 추론된) 상태를 표시하는 상태 머신이 정의되어야 합니다. 이
상태 머신은 프로토콜을 실현하는 캡슐의 사용자가 해당 동작을 보다 잘 이해하도록 도와주며 캡슐 디자이너가 해당 요소에 대해 올바른 동작을 제공하도록 도와줍니다.
프로토콜을 패키징하십시오. 프로토콜은 소프트웨어 설계자의 소유이며, 프로토콜에 대한 변경은 항상 구조적으로 중요합니다. 이를 관리하기 위해 소프트웨어 설계자가 소유하는 하나 이상의 패키지로 프로토콜을
그룹화해야 합니다. 이를 통해 해당 프로토콜을 실현하는 캡슐과 독립적으로 프로토콜을 관리 및 제어할 수 있습니다.
|