시스템이 다른 시스템과 통신하는 경우, 통신 프로토콜을 설명하기 위해 활동: 유스 케이스 분석에서 식별되는 하나 이상의 경계 클래스가 제공됩니다. 다른 시스템은 프린터, 터미널, 알람 장치 및 센서와 같이 현재 시스템이 사용할 소프트웨어 및 하드웨어 장치 중의 하나가 될 수 있습니다. 각각의 경우에, 경계 클래스의 목적은 다른 시스템과의 통신을 중재하는 것으로 나타납니다.

ATM(Automated Teller Machine)은 고객의 은행 계좌 번호와 PIN이 올바른지 확인하고 예금을 인출할 수 있을 만큼 계좌에 잔고가 남아 있는지 확인하기 위해 ATM 네트워크와 통신해야 합니다. ATM 네트워크는 외부 시스템(ATM의 Perspective에서)이므로 유스 케이스 분석에서 이를 표시하려면 경계 클래스를 사용해야 합니다.

시스템에 대한 인터페이스가 단순하고 잘 정의되어 있는 경우 단일 클래스만으로 외부 시스템을 충분히 표시할 수 있습니다. 그러나 종종 이러한 인터페이스는 너무 복잡하므로 단일 클래스를 사용하여 표시할 수 없습니다. 종종 여러 클래스의 복합적인 협업이 필요합니다. 더욱이 시스템 간 인터페이스는 어플리케이션 전체에서 매우 자주 재사용될 수 있습니다. 따라서, 대부분의 경우 서브시스템은 시스템 인터페이스를 더욱 적절히 모델링합니다.

서브시스템을 사용하면 정의가 전개되는 동안 시스템 인터페이스의 설계 세부사항을 숨겨진 채로 두고, 외부 시스템에 대한 인터페이스를 정의하고 안정시킬 수 있습니다.

설계 정제

다른 시스템 또는 장치에 대한 인터페이스의 요구사항은 (UML) 인터페이스의 구현 및 스펙에서 공식화되도록 요구합니다. 이러한 경우, 이것은 시스템이 운영되는 컨텍스트 및 시스템의 경계를 아주 정밀하게 나타낼 때 유용합니다. 유스 케이스 모델이 시스템에 대해 작동 컨텍스트를 표시하는 반면, 이 환경에 있는 시스템의 논리 모델은 다음을 표시합니다.

  • 시스템이 구현하고 제공할 인터페이스(서비스 측면에서 시스템은 지원되는 연관 프로토콜, 교환된 정보를 조작 또는 신호 수신으로 제공)
  • 올바른 성능을 위해 시스템에 필요한 인터페이스(시스템과 상호 작용하는 외부 시스템에 의해 구현됨). 간혹, 외부 시스템이 이미 존재하는 경우 해당 시스템의 작동을 변경할 수 없기 때문에 이러한 필수 및 제공된 인터페이스는 다른 해당 시스템이 강요하는 제한조건만 반영합니다.

컨텍스트 다이어그램을 작성하여 시스템과 다른 시스템 또는 장치 간의 최상위 레벨의 협업을 표시할 수 있습니다. 이는 시스템의 유스 케이스 모델과 구조적으로 유사합니다. 시스템 서비스는 유스 케이스를 지원합니다. 예를 들면, 사용자는 외부 시스템과 구축 중인 시스템 간 상호 작용을 표시하는 순서 다이어그램 세트를 구축하여 유스 케이스 실행시 교환되는 메시지를 표시하고 메시지를 조작(또는 수신)에 맵핑할 수 있습니다. 시스템 내부를 표시하지 않기 때문에 이 다이어그램은 유스 케이스 구현을 표시하는 순서 다이어그램과 동일하지 않음을 참고하십시오. 유스 케이스 시나리오의 성능에는 일반적으로 여러 번의 시스템 호출과 응답이 관련됩니다.

서비스 및 시스템 내 서비스 구현의 식별은 반드시 엄격히 하향식으로 진행될 필요는 없습니다. 설계자가 수행한 유스 케이스 분석에서 구현 클래스(경계 클래스 포함) 및 협업의 초기 모델은 활동: 구조 분석에서 소프트웨어 아키텍트가 수행한 작업을 고려하여 구축됩니다. 이런 분석은 반복될 수 있으며, 나중에 경계 클래스 및 시스템 경계 전체에 흐르는 메시지를 정제할 수 있습니다(이를 수행할 수 있다고 가정함). 변경하기 어렵거나 변경이 불가능한 기존 외부 시스템과의 인터페이스인 경우, 인터페이스 세부사항(따라서 인터페이스를 지원하기 위한 서비스)은 본질적으로 처음부터 고정되어 있으며, 인터페이스의 구현만 정제할 수 있습니다.

이 최상위 레벨에서 시스템은 외부 시스템 또는 장치를 지원하여 UML로 공식 정의된 인터페이스를 구현하는 (UML) 컴포넌트로(또는 UML 2.0에서는 구조화된 클래스) 표시될 수 있습니다. 또한 UML 2.0에서는 이들 인터페이스를 정의된 상호 작용 지점 또는 시스템 경계에 있는 포트에 지정할 수 있습니다. 소프트웨어 아키텍트 및 설계자는 포트를 사용하여 시스템의 내부 컴포넌트 또는 클래스가 인터페이스를 지원할 수 있도록 '연결'되는 방법을 표시할 수 있습니다. 이는 분석에서 식별된 경계 클래스에 대한 자연적인 브릿지를 형성합니다. 단순한 경우 시스템 경계의 포트를 통해 클래스가 구현하는 인터페이스에 클래스를 연결할 수 있습니다. UML 2.0에서는 프로토콜 상태 시스템을 통해 더 높은 레벨의 정밀도를 사용할 수 있습니다. 프로토콜 상태 시스템은 인터페이스 또는 포트와 연관될 수 있으며, 인터페이스가 지정하거나 포트가 지원하는 적법한 작동 기능 호출 순서를 지정합니다.

위에서 설명했듯이 복잡한 인터페이스를 지원하기 위해 협업이 필요한 경우, 해당 협업(원래 식별된 경계 클래스에서 전개되는) 자체를 제1 섹션에서 설명한 서브시스템의 역할을 하는 시스템 내부 컴포넌트(또는 구조화된 클래스)로 캡슐화하여 필수 인터페이스를 지원하는 포트에 연결할 수 있습니다.

SOA에서 인터페이스를 제공하고 구현하는 방법에 대한 자세한 설명은 "SOA 및 컴포넌트 기반 개발을 사용하여 웹 서비스 어플리케이션 빌드" 백서를 참조하십시오.

Rational Unified Process   2003.06.15