주제

정의페이지 맨 위

UML([UML04])에 따르면, 클래스는 클래스에게 내부 구조 및 포트를 가질 수 있는 성능을 가져다 주는 EncapsulatedClassifier 및 metaclass 클래스의 서브유형입니다. 또한 컴포넌트는 UML에 의해 클래스의 서브유형으로 정의됩니다. 따라서 RUP 컨텍스트 내에서는 컴포넌트클래스를 모두 구조화된 클래스라고 부릅니다.

파트

구조화된 클래스의 인스턴스에는 각 파트에 대응되는 객체 또는 객체 세트가 포함됩니다. 모든 인스턴스는 포함되어 있는 구조화된 클래스 인스턴스가 소멸될 때 소멸됩니다.

아래 예에서는 가능한 두 개의 Car 클래스 보기를 표시합니다.

그림 (a)에서 Car는 역할 이름 rearWheel 클래스의 구성 연관, 역할 이름 eEngine 클래스의 구성 연관을 가진 것으로 표시됩니다. Engine 클래스의 모든 인스턴스는 Wheel클래스의 임의의 수의 인스턴스에 링크될 수 있습니다.

그림 (b)에서도 동일하게 지정됩니다. 그러나 추가로 그림 (b)에서는 다음이 지정됩니다.

  • Car 클래스의 내부 구조에 속한 reare. 이것은 Car 클래스의 컨텍스트 내에 있는 WheelEngine 클래스의 인스턴스에 대해서만 보유하고, 일반적으로 wheelsengines에 대해서는 보유하지 않는 세부사항 스펙을 허용합니다.

  • Car 클래스의 컨텍스트 내에서 e 역할을 수행하는 인스턴스는 rear 역할을 수행하는 두 개의 인스턴스에만 연결될 수 있습니다. 또한 erear 역할을 수행하는 인스턴스는 Car 클래스의 동일한 인스턴스 역할인 경우에만 링크될 수 있습니다.

  • 바꾸어 말하면, Car 클래스의 인스턴스 내에서 WheelEngine 클래스의 인스턴스가 각각의 역할을 수행하고 있을 때 추가 제한조건이 WheelEngine 클래스의 인스턴스에 적용됩니다. 일반적으로 이러한 제한조건은 WheelEngine의 인스턴스에 대해서는 참이 아닙니다. 다른 wheelsengines는 그림 (a)에 지정된 대로 임의로 링크될 수 있습니다.

첨부 텍스트에 설명된 다이어그램.

예: 구조화된 클래스 내부에서 해당 역할을 수행하는 파트

커넥터

커넥터는 구축된 클래스의 두 파트 간에 관계의 인스턴스입니다. 이것은 통신을 허용하기 위한 링크입니다. 커넥터는 보통 연관에 의해 구현되거나 프로시저 매개변수, 변수, 글로벌 값 또는 기타 메커니즘과 같은 일시적 관계에 의해 구현됩니다.

구축된 클래스의 내부 "배선"은 어셈블리 커넥터 및 위임 커넥터로 지정됩니다.

  • 구축된 클래스의 구현 내에서 어셈블리 커넥터는 다른 파트의 포트를 연결합니다. 구조화된 하나의 클래스의 포트에서 전송된 메시지는 또 다른 구조화된 클래스의 연결된 포트에서 수신됩니다. 파트 세트는 포트를 통해 함께 선으로 연결될 수 있습니다. 파트는 연결된 포트에 대한 제한조건이 있는지와 이를 충족하는지를 제외하고는 다른 파트에 대해 아무 것도 알 필요가 없습니다. 구조화된 클래스 사이의 통신은 각각의 포트를 통해 모델링됩니다.


  • 위임 커넥터는 내부 파트 중 하나의 포트에 구조화된 클래스의 외부 포트를 연결합니다. 외부 포트가 수신한 메시지는 내부 파트의 포트로 전달되고, 내부 포트가 전송한 메시지는 외부 포트로 전달된 후 외부 포트로 연결된 구조화된 클래스로 전달됩니다.

포트 페이지 맨 위

포트는 구조화된 클래스의 구조적 피처입니다. 캡슐화는 선언된 인터페이스를 준수하는 포트를 통해 전달되도록 구조화된 클래스 외부로부터 의사소통을 시행하여 증가시킬 수 있습니다. 이로써, 해당 구조화된 클래스의 스펙 및 상호 연결에 정밀도가 추가됩니다.

포트의 필수 인터페이스와 제공된 인터페이스는 상호작용 지점을 통해 상호작용에 필요한 모든 것을 지정합니다. 환경을 포함한 구조화된 클래스의 모든 상호작용이 포트를 통해 이루어지면 구조화된 클래스 내부는 환경에서 완전히 분리됩니다. 이것은 구조화된 클래스를 포트에서 지정된 제한조건을 충족하는 모든 컨텍스트에 사용할 수 있게 합니다.

포트가 구현되는 방법에 대한 가정은 없습니다. 포트는 명시적 객체로 구현되거나 단순히 구현에 명시적으로 표시되지 않는 가상 개념일 수 있습니다.

다음은 포트의 예입니다.

예 1

첨부 텍스트에 설명된 다이어그램.

차 및 배에서 사용되는 엔진의 포트

위의 그림은 p 포트를 포함한 Engine 클래스와 다음 두 가지 인터페이스를 표시합니다.

  • 제공되는 인터페이스 powertrain - 엔진이 이 포트에서 제공하는 서비스를 지정합니다(예" 이 포트에 도달하는 통신을 통해 액세스할 수 있는 조작 및 수신).
  • 필수 인터페이스 power - 엔진이 환경에서 제공되기를 기대하는 서비스를 지정합니다.

p 포트에서 Engine 클래스는 완전하게 캡슐화됩니다. 이것은 엔진이 임베드될 환경에 대한 지식 없이도 지정될 수 있습니다. 환경이 엔진의 제공된 인터페이스와 필수 인터페이스로 표현되는 제한조건에 따르는 한, 엔진은 잘 작동합니다.

이 예에서는 이를 설명하기 위해 두 가지 Engine 클래스 사용이 표시됩니다.

  • Car 클래스는 axle을 통해 엔진의 p 포트를 바퀴 세트에 연결합니다.
  • Boat 클래스는 shaft를 통해 엔진의 p 포트를 프로펠러에 연결합니다.

Enginep 포트에 연결된 부분 사이의 상호작용이 제공된 인터페이스와 필수 인터페이스에서 지정된 제한조건을 따르는 한, 차 엔진이든 배 엔진이든 간에 엔진이 지정된 대로 작동합니다.

더욱이, Engine에 다른 포트(예: Fuel Consumptionf 포트)가 선언되어 있더라도 자동차의 바퀴와 보트의 프로펠러는 여전히 p 포트를 통해 Engine에 액세스합니다. f 포트는 어떤 종류의 연료가 사용되는지 및 차와 보트에 어떤 종류의 연료계가 있는지에 관계 없이 연료계에 있어서 중요할 수 있습니다.

예 2

이 포트 예제는 Java 로깅 API([JAV03])를 기반으로 하고 특히 다음과 같은 Java 2 플랫폼 핵심 로깅 기능의 클래스 및 인터페이스를 제공하는 패키지입니다.

  • 로거는 어플리케이션에서 로깅 호출을 작성하는 기본 엔티티입니다. 로거는 특정 시스템 또는 어플리케이션 컴포넌트에 대한 메시지를 로그하는 데 사용됩니다.
  • 레벨은 로그 메시지의 중요성과 긴급성에 대한 안내를 제공합니다.
  • 필터는 로그 레벨에서 제공되는 제어를 벗어나서 로그된 내용에 대한 세부적인 제어를 제공합니다.
  • 핸들러는 로거에서 메시지를 받아 다른 대상(메모리, 출력 스트림, 콘솔, 파일 및 소켓)에 내보내기합니다.
  • 포맷터는 로그 레코드 포맷에 대한 지원을 제공합니다.

이들 클래스와 인터페이스는 두 가지 중요한 유형의 협업에 관련됩니다. 일부 클래스 및 인터페이스는 로그에 작성하는 데 사용되고 다른 클래스 및 인터페이스는 로그를 관리하는 데 사용됩니다. 아래 그림은 클라이언트 및 관리자가 로그와 함께 가지는 UML 협업으로 모델링된 두 가지 다른 협업을 표시합니다.

  • 쓰기 협업: 로그에 쓰기 위해 LogClient 역할이 LogWriter 역할에 연결됨.
  • 관리 협업: 로그에 액세스하고 로그 설정을 변경하기 위해 LogAdministrator 역할이 LogController 역할에 연결됨.

첨부 텍스트에 설명된 다이어그램.

클라이언트와 관리자가 로그와 함께 가지는 여러 협업

로깅 서비스 및 이의 협업을 모델링하는 데 적절한 하나의 UML 2.0 표시는 아래 그림에 표시된 대로 포트를 포함한 컴포넌트 및 선언된 인터페이스를 사용하는 것입니다.

첨부 텍스트에 설명된 다이어그램.

포트로 그룹화되는 제공된 인터페이스를 통해 컴포넌트로 구현되고 있는 Java 로깅 API 패키지

Java Logging API 스펙에서 일부 로깅 서비스는 클래스로 구현되고 일부는 인터페이스로 구현됩니다. 이 예에서는 이들 각 서비스를 제공된 인터페이스로 모델링하며, 이들 인터페이스는 컴포넌트 내부의 파트에 의해 구현될 수 있습니다. 위에서 언급된 쓰기관리 협업에 관계된 두 가지 다른 종류의 작동이 논리적으로 포트에 그룹화된 인터페이스를 통해 표시될 수 있습니다. 따라서 다음을 가집니다.

  • LogWriter 포트로 그룹화된 로거레벨 인터페이스. 이러한 인터페이스는 로그를 작성하기 위해 로그 클라이언트가 액세스합니다.
  • LogController 포트로 그룹화되는 핸들러, 필터포맷터 인터페이스. 이러한 인터페이스는 로그에 액세스하고 로그 설정을 변경하기 위해 로그 관리자가 액세스합니다.

이 모델링 대안은 인터페이스를 논리적으로 다른 포트로 그룹화하여 관심사를 분리합니다. 컴포넌트 스펙에 대한 추가 정밀도와 외부 세계와 함께 할 수 있는 상호 연결을 가집니다.

모델링페이지 맨 위

설계 중에 클래스 및 컴포넌트는 차례로 더욱 분해될 수도 있는 연결된 파트의 콜렉션으로 분해될 수도 있습니다.

합성 구조 다이어그램은 구조화된 클래스의 분해를 표시하는 데 사용될 수 있습니다. 예를 들어, 아래 그램은 티켓팅 시스템의 매표소에 대한 합성 주고 다이어그램을 표시합니다. 이 클래스는 세 가지 파트로 분해됩니다.

  • 티켓 판매원 인터페이스
  • 날짜 및 다른 기준에 따라 공연을 검색하는 공연 안내서
  • 공연 및 티켓에 대한 데이터가 들어 있는 데이터베이스 세트

각 파트는 포트에서 지정되는 잘 정의된 인터페이스를 통해 상호작용합니다. 전체 매표소는 포트를 통해 외부와 상호작용합니다. 이 포트의 메시지가 티켓 판매원 클래스에 디스패치되지만 매표소 클래스의 내부 구조는 외부 클라이언트로부터 숩겨집니다.

첨부 텍스트에 설명된 다이어그램.

예: 티켓팅 시스템에 대한 합성 구조 다이어그램.

UML 1.x 표시페이지 맨 위

구조화된 클래스는 UML 2.0의 새 개념임에 주의하십시오.

툴이 UML 1.5만 지원하는 경우, ../../artifact/ar_cpsl.htm -- This hyperlink in not present in this generated website결과물: 캡슐../../modguide/md_cpsl.htm -- This hyperlink in not present in this generated website가이드라인: 캡슐에 대체 표현이 설명되어 있습니다.

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

Rational Unified Process   2003.06.15