개념: 컴포넌트
컴포넌트는 시스템의 캡슐화된 파트로, 이론상으로는 제대로 정의된 아키텍처 컨텍스트에서 명확한 기능을 이행하는 시스템의 평범하지 않고 거의 독립적이며 대체 가능한 파트입니다.
관계
기본 설명

정의

소프트웨어 업계와 서적에서 "컴포넌트" 용어는 다양한 의미로 사용됩니다. 광범위하게는 "구성 파트"를 의미하기 위해 종종 사용됩니다. 또한 좁은 의미로 대규모 시스템에서 대체 및 어셈블리가 가능하도록 하는 특정의 특성을 가리키기 위해서도 사용됩니다.

RUP에서 "컴포넌트"라는 용어는 시스템의 캡슐화된 파트를 의미합니다. 이는 이론상으로는 제대로 정의된 아키텍처 컨텍스트에서 명확한 기능을 이행하는 중요하고 거의 독립적이며 대체 가능한 시스템 파트를 의미합니다. 이는 다음과 같습니다.

  • 디자인 컴포넌트 - 디자인의 중요한 캡슐화 파트로, 디자인 서브시스템을 포함하며 간혹 중요한 디자인 클래스와 디자인 패키지도 포함합니다.
  • 구현 컴포넌트 - 구현의 중요한 캡슐화 파트로, 일반적으로는 디자인 컴포넌트를 구현하는 코드입니다.

이론상으로, 디자인은 구현을 반영하므로 단지 컴포넌트만 가리킬 수도 있습니다. 이 때 각 컴포넌트는 디자인 및 구현을 수반합니다.

UML([UML04])은 "컴포넌트"를 다음과 같이 정의합니다.

해당 환경 내에서 Manifestation을 대체 가능하고 컨텐츠를 캡슐화하는 시스템의 모듈식 파트. 컴포넌트는 제공 및 필수 인터페이스 측면으로 동작을 정의합니다. 컴포넌트는 그 자체로 하나의 유형 역할을 하므로, 컴포넌트 준수는 제공 및 필수 인터페이스(정적 뿐만 아니라 동적 시맨틱도 포함)에 의해 정의됩니다.

컴포넌트는 속성 및 오퍼레이션을 가지고 있고 연관 및 일반화에 참여할 수 있으며 내부 구조와 포트를 갖는 컴포넌트에 대해 제공되는 구조화된 클래스의 하위 유형으로 정의됩니다. 자세한 내용은 개념: 구조화된 클래스를 참조하십시오.

컴포넌트에 적용되는 많은 UML 표준 스테레오타입이 존재합니다. 예를 들어, 대규모 컴포넌트를 모델링하기 위한 <<subsystem>>과 명확한 스펙 및 실현(realization) 정의로 컴포넌트를 모델링하기 위한 <<specification>> 및 <<realization>>이 있습니다(하나의 스펙에 여러 개의 실현이 포함될 수 있음).

RUP에서의 컴포넌트 용어 사용은 UML 정의보다 광범위합니다. 컴포넌트를 모듈화, 배치 가능성 및 대체 가능성과 같은 특성을 가지고 있는 것으로 정의하는 대신 원하는 컴포넌트 특성으로 정의할 것을 권장합니다. 아래에서 컴포넌트 대체 가능성에 관한 섹션을 참조하십시오.

컴포넌트 대체 가능성

RUP 및 UML 용어에서, 컴포넌트는 대체 가능해야 합니다. 그러나 이는 단지 컴포넌트가 근본적인 구현을 숨기는 인터페이스 세트를 노출함을 의미할 수 있습니다.

다른 종류의 더 강한 대체 가능성이 있습니다. 이 대체 가능성은 아래에 나열되어 있습니다.

소스 파일 대체 가능성

두 개의 클래스가 단일 소스 코드 파일에서 구현될 경우, 각 클래스는 보통 별도로 버전화하여 제어할 수 없습니다.

그러나 파일 세트가 완전히 단일 컴포넌트를 구현하고 다른 컴포넌트는 구현하지 않을 경우, 컴포넌트는 소스 파일 대체 가능 컴포넌트입니다. 이 특성으로 컴포넌트 소스 코드를 더 쉽게 버전화하여 제어하고 기준선에 맞추며 재사용할 수 있습니다.

배치 대체 가능성

두 개의 클래스가 단일 실행 파일로 배치될 경우, 각 클래스는 배치된 시스템에서 독립적으로 대체할 수 없습니다.

세분성이 높은 컴포넌트의 바람직한 특성은 "배치 대체 가능"으로, 이 특성이 있으면 다른 컴포넌트를 재빌드하지 않고도 컴포넌트의 새 버전을 배치할 수 있습니다. 이는 보통 해당 컴포넌트는 배치하고 다른 컴포넌트는 배치하지 않는 하나의 파일 또는 하나의 파일 세트가 있음을 의미합니다.

런타임 대체 가능성

실행 중인 시스템에 컴포넌트를 다시 배치할 수 있을 경우 "런타임 대체 가능"이라고 합니다. 이 경우 소프트웨어를 사용하면서 소프트웨어를 업그레이드할 수 있습니다.

위치 투명성

네트워크 주소 지정 가능 인터페이스가 있는 컴포넌트는 "위치 투명성"을 갖는다고 합니다. 이 경우 컴포넌트를 다른 서버에 재배치하거나 여러 서버에서 복제하여 결함 허용, 로드 밸런스 등을 지원할 수 있습니다. 이와 같은 종류의 컴포넌트는 종종 "분배된" 또는 "분배 가능" 컴포넌트라고 합니다.

컴포넌트의 모델링

UML 컴포넌트는 다음 기능을 제공하는 모델링 구조입니다.

  • 클래스를 그룹화하여 시스템의 더 세분화된 파트를 정의할 수 있습니다.
  • 내부 구현에서 가시적 인터페이스를 분리할 수 있습니다.
  • 런타임 시 실행되는 인스턴스를 가질 수 있습니다.

컴포넌트는 함께 연결(wiring) 컴포넌트 기반을 형성하는 많은 제공 및 필수 인터페이스를 가지고 있습니다. 제공 인터페이스는 컴포넌트나 컴포넌트의 실현 클래스 또는 서브컴포넌트 중 하나가 직접 구현하는 인터페이스입니다. 그렇지 않으면 제공 컴포넌트 포트 유형입니다. 필수 인터페이스는 컴포넌트나 컴포넌트의 실현 클래스 또는 서브컴포넌트 중 하나에서 사용 종속성으로 지정됩니다. 그렇지 않으면 필수 포트 유형입니다.

컴포넌트에는 공개적으로 볼 수 있는 특성 및 오퍼레이션에 의한 외부 보기(또는 "블랙 박스")가 있습니다. 선택사항으로, 프로토콜 상태 머신과 같은 동작을 인터페이스, 포트 및 컴포넌트 자체에 첨부하고 오퍼레이션 호출 시퀀스에서 동적 제한조건을 명시적으로 만들어서 더 명확하게 외부 보기를 정의할 수 있습니다. 시스템 또는 다른 환경에서 컴포넌트 사이의 연결(wiring)은 컴포넌트 인터페이스 사이의 종속성을 사용하여 구조적으로 정의할 수 있습니다(일반적으로 컴포넌트 다이어그램에서 정의).

선택사항으로, 컴포지트 구조의 파트 및 커넥터를 통해 더 자세한 구조적 협업 스펙을 작성하여 컴포넌트 사이의 역할 또는 인스턴스 레벨 협업을 지정할 수 있습니다. 이는 개인용 특성과 클래스 또는 서브컴포넌트 실현에 의한 컴포넌트의 내부 보기(또는 "화이트 박스" 보기)입니다. 이 보기는 외부 동작을 내부적으로 실현하는 방법을 보여줍니다. 외부 및 내부 보기 사이의 맵핑은 종속성(컴포넌트 다이어그램)이나 내부 파트의 위임 커넥터(컴포지트 구조 다이어그램)에 의한 것입니다.

RUP는 디자인 서브시스템의 표시로 컴포넌트를 사용할 것을 권장합니다. 자세한 내용은 중간 산출물: 디자인 서브시스템, 타스크: 서브시스템 디자인가이드라인: 디자인 서브시스템을 참조하십시오. 또한 개념: 구조화된 클래스를 참조하십시오.

컴포넌트 인스턴스화

컴포넌트는 런타임 시 직접 인스턴스화되거나 그렇지 않을 수 있습니다.

간접적으로 인스턴스화된 컴포넌트는 클래스, 서브컴포넌트 또는 파트 세트별로 구현 또는 실현됩니다. 컴포넌트 자체는 구현에 표시되지 않습니다. 컴포넌트는 구현의 기반이 되는 디자인으로 제공됩니다. 실현 클래스, 서브컴포넌트 또는 파트 세트는 컴포넌트의 제공 인터페이스에 지정된 전체 오퍼레이션 세트를 다루어야 합니다. 컴포넌트 구현 방식은 구현자 책임입니다.

직접 인스턴스화된 컴포넌트는 컴포넌트 자체의 캡슐화된 구현을 지정합니다. 이 컴포넌트는 주소 지정 가능 오브젝트로 인스턴스화됩니다. 즉, 디자인 컴포넌트에는 구현 언어로 된 해당 구조가 있으므로 명확하게 참조할 수 있습니다.

UML 1.x 표시

UML 1.5는 "컴포넌트"를 다음과 같이 정의했습니다.

구현을 캡슐화하고 인터페이스 세트를 노출하는 시스템의 모듈식, 배치 가능 및 대체 가능 파트. 컴포넌트는 일반적으로 컴포넌트에 상주하는 하나 이상의 클래스나 서브컴포넌트로 지정되므로, 하나 이상의 아티팩트(예: 2진, 실행 파일 또는 스크립트 파일)로 구현할 수 있습니다.

UML 1.3과 UML의 이전 버전에서는 구현에서 파일을 표시하는 데 "컴포넌트" 표기를 사용했습니다. 파일은 더 이상 최근 UML 정의에서 "컴포넌트"로 간주되지 않습니다. 그러나 많은 도구 및 UML 프로파일에서는 여전히 파일을 표시하는 데 컴포넌트 표기를 사용합니다. UML에서의 파일 표시에 더 많은 논의는  가이드라인: 구현 요소를 참조하십시오.

모델링 측면에서, 컴포넌트는 UML 1.5의 UML 서브시스템과 비교되었습니다. 컴포넌트가 모듈화, 캡슐화, 런타임 시 인스턴스 실행 가능성을 제공했기 때문입니다. RUP는 UML 1.5 컴포넌트 모델링 구조를 디자인 서브시스템을 표시하기 위한 대체 표기로 간주합니다. 자세한 내용은 중간 산출물: 디자인 서브시스템가이드라인: 디자인 서브시스템을 참조하십시오.

자세한 내용은 UML 1.x 및 UML 2.0의 차이점을 참조하십시오.