개념: 컴포넌트
주제
소프트웨어 산업 및 문헌에서는 "컴포넌트"라는 용어를 사용하여
여러 가지를 나타냅니다.
이것은 종종 "구성 파트"를 뜻하는
광범위한 의미로 사용됩니다.
보다 큰 시스템에서 대체 가능성 및 어셈블리를 가능하게 하는
특정 특성을 나타내는 좁은 의미로도 자주 사용됩니다.
RUP에서는 캡슐화된 시스템 파트, 잘 정의된 구조의 컨텍스트에서 명확한 기능을
수행하는 이상적으로 사소하지 않고 거의 독립적이며
대체 가능한 시스템 파트를 나타내기 위해 "컴포넌트"라는 용어를 사용합니다.
여기에는 다음이 포함됩니다.
- 설계 컴포넌트 - 캡슐화된 중요한 설계 파트,
설계 서브시스템이 포함되며 때때로 중요한 설계 클래스 및
설계 패키지가 포함됩니다.
- 구현 컴포넌트 - 캡슐화된 중요한 구현 파트,
일반적으로 설계 컴포넌트를 구현하는 코드.
이상적으로 설계는 구현을 반영합니다. 따라서
단지 컴포넌트, 설계 및 구현을 가진 각 컴포넌트를 참조할 수 있습니다.
UML([UML04])은 컴포넌트를 다음과 같이 정의합니다.
컨텐츠를 캡슐화하고 환경 내에서 선언을 바꿀 수 있는 모듈로 된 시스템 파트.
컴포넌트는 제공된 인터페이스와 필수 인터페이스에 따라 작동을 정의합니다.
이와 같이, 컴포넌트는 제공된 인터페이스와 필수 인터페이스에 따라
적합성이 정의되는 유형 역할을 합니다(동적 의미론뿐 아니라 정적 의미론도 포함).
컴포넌트는 속성 및 조작을 가지고 연관 및 일반화에 관계될 수 있으며
내부 구조 및 포트를 가지는 컴포넌트를 제공하는 구조화된 클래스의 서브유형으로 정의됩니다.
세부사항은 개념: 구조화된 클래스를 참조하십시오.
컴포넌트에 적용되는 많은 UML 표준 스테레오타입이 존재합니다.
예를 들어, 대규모 컴포넌트를 모델링하기 위한 <<서브시스템>>,
하나의 스펙이 여러 구현을 가질 수 있는 곳에서
별개의 스펙 및 구현 정의를 포함하는 컴포넌트를 모델링하기 위한
<<스펙>> 및 <<구현>>이 있습니다.
용어 컴포넌트의 RUP 사용은 UML 정의보다 더 광범위합니다.
컴포넌트를 모듈성, 전개 가능성 및 대체 가능성과 같은 특성을 가지는 것으로 정의하는 대신
바람직한 컴포넌트 특성으로 정의하도록 권장합니다.
컴포넌트 대체 가능성 아래의 섹션을 참조하십시오.
RUP 및 UML 용어에서 컴포넌트는 대체 가능해야 합니다.
그러나 이것은 컴포넌트가 기반이 되는 구현을 숨기는 인터페이스
세트를 드러낸다는 것만을 의미할 수 있습니다.
보다 강력한 다른 종류의 대체 가능성이 있습니다. 이러한 대체 가능성이 아래에 나열되어 있습니다.
소스 파일 대체 가능성
두 개의 클래스가 단일 소스 코드 파일에서 구현되는 경우
일반적으로 각 클래스는 별도로 버전이 지정되거나 제어될 수 없습니다.
그러나 파일 세트가 단일 컴포넌트를 완전히 구현하고 다른 컴포넌트가 없는 경우
그 컴포넌트는 대체 가능한 소스 파일입니다.
이 특성은 컴포넌트 소스 코드가 더 쉽게 버전 제어되고 기준선이 지정되며 재사용될 수 있게 합니다.
전개 대체 가능성
두 개의 클래스가 단일 실행 파일에 전개되는 경우
각 클래스는 전개된 시스템에서 독립적으로 대체 가능합니다.
보다 큰 세분성 컴포넌트의 바람직한 특성은
새 버전의 컴포넌트가 다른 컴포넌트를 다시 빌드할 필요 없이 전개될 수 있게 하는
"대체 가능한 전개"가 되는 것입니다.
일반적으로 이것은 다른 컴포넌트가 아닌 해당 컴포넌트를 전개하는 하나의 파일 또는
하나의 파일 세트가 있음을 의미합니다.
런타임 대체 가능성
컴포넌트가 실행 중인 시스템으로 다시 전개될 수 있는 경우
"런타임 대체 가능"이라고 합니다.
이를 통해 사용 가능성의 감소 없이 소프트웨어를 업그레이드할 수 있습니다.
위치 투명성
네트워크 주소를 지정할 수 있는 인터페이스가 포함된 컴포넌트를 가리켜
"위치 투명성"을 가지고 있다고 합니다.
이것은 결함 허용, 로드 밸런싱 등을 지원하기 위해 컴포넌트가 다른 서버에 재배치되거나
여러 서버에 복제될 수 있도록 합니다. 종종 이러한 유형의 컴포넌트를 "분배된" 또는 "분배 가능한" 컴포넌트라고 합니다.
UML 컴포넌트는 다음과 같은 성능을 제공하는 모델링 구성체입니다.
- 보다 큰 단위의 시스템 파트를 정의하기 위해 클래스를 그룹화할 수 있습니다.
- 내부 구현에서 가시적인 인터페이스를 분리할 수 있습니다.
- 런타임에 실행되는 인스턴스를 가질 수 있습니다.
컴포넌트는 다수의 제공되는 인터페이스 및 필수 인터페이스를 가집니다.
이러한 인터페이스는 컴포넌트를 함께 선으로 연결하는 데 대한 기초를 형성합니다.
제공되는 인터페이스는 컴포넌트 또는 구현 중인 클래스나
서브컴포넌트 중 하나에서 직접 구현되는 인터페이스입니다.
또는 제공되는 컴포넌트 포트의 유형입니다.
필수 인터페이스는 컴포넌트 또는 구현 중인 클래스나 서브컴포넌트 중 하나에서
사용 종속성에 의해 지정되거나 필수 포트의 유형입니다.
컴포넌트에는 공개적으로 가시적인 등록 정보 및 조작에 의한
외부 보기(또는 "블랙박스" 보기)가 있습니다.
선택적으로, 일련의 명시된 조작 호출에 동적 제한조건을 작성하여
외부 보기를 더 자세히 정의하기 위해
프로토콜 상태 시스템과 같은 작동이 인터페이스, 포트 및
컴포넌트 자체에 첨부될 수 있습니다.
시스템 또는 기타 컨텍스트의 컴포넌트 간 배선은
컴포넌트 인터페이스 사이의 종속성을 사용하여 구조적으로
정의될 수 있습니다(일반적으로 컴포넌트 다이어그램).
선택적으로, 자세한 구조적 협업 스펙은
합성 구조에서 컴포넌트 간 역할 또는 인스턴스 레벨 협업을 지정하기 위해
파트 및 커넥터를 사용하여 작성될 수 있습니다.
이것은 개인용 등록 정보와
클래스 또는 서브컴포넌트 구현에 의한
컴포넌트의 내부 보기(또는 "화이트 박스" 보기)입니다.
이 보기는 외부 작동이 내부적으로 구현되는 방법을 표시합니다.
외부 및 내부 보기 간 맵핑은
종속성(컴포넌트 다이어그램) 또는 내부 파트에 대한
위임 커넥터(합성 구조 다이어그램)에 의한 것입니다.
RUP는 설계 서브시스템 표시로 컴포넌트를 사용하도록 권장합니다.
세부사항은 결과물: 서브시스템 설계,
활동: 서브시스템 설계 및
가이드라인: 서브시스템 설계를 참조하십시오.
또한 개념: 구조화된 클래스의 정의도 참조하십시오.
컴포넌트는 런타임에 직접 인스턴스화될 수도 있고 그렇지 않을 수도 있습니다.
간접적으로 인스턴스화된 컴포넌트는 클래스, 서브컴포넌트 또는 파트의 세트에 의해
구현됩니다. 컴포넌트 자체가 구현이 표시되지는 않습니다.
컴포넌트는 구현이 지켜야 하는 설계 역할을 합니다.
구현 클래스, 서브컴포넌트 또는 파트의 세트는
제공되는 컴포넌트 인터페이스에 지정된 전체 조작 세트를
다루어야 합니다.
컴포넌트 구현 방법은 구현자의 책임입니다.
직접적으로 인스턴스화된 컴포넌트는 자체 캡슐화된 구현을 지정합니다.
이것은 지정 가능한 객체로 인스턴스화됩니다.
이것은 설계 컴포넌트가 구현 언어에서 대응되는 구성체를 가지고 있어서
명시적으로 참조될 수 있음을 의미합니다.
UML 1.5에서는 컴포넌트를 다음과 같이 정의합니다.
구현을 캡슐화하고 인터페이스 세트를 드러내는
모듈로 된 전개 가능하고 대체 가능한 시스템 파트.
컴포넌트는 일반적으로 컴포넌트에 있는 하나 이상의 클래스로 지정되며
하나 이상의 결과물(예: 2진, 실행 파일 또는 스크립트 파일)로 구현될 수 있습니다.
UML 1.3 및 이전 버전의 UML의 경우
구현에서 파일을 표시하는 데 "컴포넌트" 표기법이 사용됨에 주의하십시오.
파일은 더 이상 최신 UML 정의에서 고려되는 "컴포넌트"가 아닙니다.
그러나 많은 툴 및 UML 프로파일은 여전히 컴포넌트 표기법을 사용하여
파일을 표시합니다.
UML에서 파일을 표시하는 것에 관한 자세한 정보는
가이드라인: 구현 요소를 참조하십시오.
모델링 Perspective에서 컴포넌트는 런타임시 실행할 수 있는 모듈성,
캡슐화 및 인스턴스를 제공했으므로 UML 1.5의 UML 서브시스템과 비교되었습니다.
RUP는 UML 1.5 컴포넌트 모델링이 설계 서브시스템을
나타내기 위한 대체 표기를 구축하는 것으로 간주합니다.
세부사항은 결과물:
서브시스템 설계 및 가이드라인: 서브시스템
설계를 참조하십시오.
자세한 정보는 UML
1.x 및 UML 2.0 간 차이를 참조하십시오.
|