UML 클래스 다이어그램 표기법 : 연관, 집계 및 구성의 차이점


39

UML 클래스 다이어그램의 일부 표기법에 대해 혼란스러워합니다.

여기에 이미지 설명을 입력하십시오

협회 가 무엇을 의미 하는지 잘 알고 있습니다. 한 클래스의 인스턴스가 작업을 수행하기 위해 두 번째 클래스의 인스턴스에 대해 알아야하는 두 클래스의 인스턴스 간 관계는 연관 관계입니다. 연관은 종종 클래스 A에 클래스 B의 인스턴스에 대한 참조 (필드)가 있음을 의미합니다.

그러나 Aggregation and Composition 화살표의 의미를 이해하는 데 어려움을 겪고 있습니다. 혼란의 일부는 이러한 표기법의 다른 정의에 직면하여 발생했습니다.

집계 표기법 의 두 가지 정의 :

정의 1 : 두 클래스 사이의 집계 표기법은 클래스 A 의 인스턴스가 클래스 B의 인스턴스 컬렉션보유 할 때마다 적합합니다 (예 : List, Array 등).

정의 2 : 클래스 A의 인스턴스가 클래스 B의 인스턴스에 대한 참조를 보유하고 B 인스턴스가 A 인스턴스의 수명주기에 종속되는 경우 두 클래스 간의 집계 링크가 적합 합니다. 의미 : 클래스 A GET의 인스턴스가 삭제됩니다 때, 그래서 클래스 B의 인스턴스가 클래스 B의 인스턴스가되는 것입니다 완전히 포함 된 단지의 인스턴스에 대한 참조를 소유 클래스 A의 인스턴스는 달리, 클래스 A의 인스턴스 클래스 B (정규 협회)

컴포지션 표기법의 의미와 그것이 집계 표기법과 어떻게 다른지에 대해서는 확실하지 않습니다.

정의를 명확히하고 이해하도록 도와주세요. 구체적인 예를 환영합니다.


정의 2는 집계보다는 컴포지션에 대한 정의와 비슷합니다. 정의 1은 아주 잘 들립니다.
jbx

답변:


32

3 개의 연결, 집계 및 구성 링크는 두 클래스가 서로 얼마나 밀접하게 관련되어 있는지에 대한 일종의 척도를 형성합니다.

규모의 한쪽 끝에는 두 클래스의 객체가 서로에 대해 알 수 있지만 서로의 수명에 영향을 미치지 않는 Association이 있습니다. 개체는 독립적으로 존재할 수 있으며 어떤 클래스 A 개체는 어떤 클래스 B 개체가 시간에 따라 변할 수 있는지 알고 있습니다.

스케일의 다른 쪽 끝에는 컴포지션이 있습니다. 컴포지션은 클래스 B가 클래스 A의 필수 부분이되도록 전체 관계를 나타냅니다.이 관계는 일반적으로 클래스 B 개체가 없어도 클래스 A의 개체가 논리적으로 존재할 수없는 경우에 사용됩니다.

집계 관계는이 두 끝 사이의 어딘가에 있지만 정확히 어디에서 동의하는 것 같지 않으므로 집계가 의미하는 바에 대해 보편적으로 합의 된 정의도 없습니다. 그런 의미에서 발견 한 두 가지 정의는 모두 정확하며 10 명에게 물어 보면 11 가지 다른 정의를 얻을 위험이 있습니다.


1
답변 주셔서 감사합니다. 다음은 내가 이해하는 방법입니다. 이것이 합리적인 정의인지 말해주십시오. 1- 연관은 A 오브젝트가 기능을 수행하기 위해 B 오브젝트에 대해 알아야 할 때마다입니다. 2- Aggregation과 Composition은 '소유권'관계를 정의합니다. 클래스 A 의 인스턴스는 개념적 으로 클래스 B의 인스턴스를 소유합니다. 그러나 B 인스턴스의 수명은 A 인스턴스의 수명과 무관합니다. 예를 들어 직원이있는 부서 부서는 직원 인스턴스를 '소유'하지만 부서없이 계속 살게됩니다. 구성은 집계와 유사하지만
Aviv Cohn

1
B 인스턴스의 수명은 A 인스턴스의 수명에 따라 다릅니다. 더 강한 '소유권'관계. 예를 들어 : 자동차와 바퀴. 차는 바퀴를 완전히 포함한다. Car 인스턴스에 Car 인스턴스가 없으면 Wheel 인스턴스가 계속 작동하지 않습니다. 이것이 합리적인 차별화인가?
Aviv Cohn

@Prog : 그렇습니다. 그것은 합리적인 정의입니다. 다른 사람들이 그 정의를 공유하지 않을 수도 있고 집계 사용에 대해 설명해야 할 수도 있습니다.
Bart van Ingen Schenau

집계 표기법에 대한 가장 일반적인 정의는 무엇입니까? 내가 사용하는 정의? '집합'정의? 다른 것?
Aviv Cohn

아래 OMG 표준에 대한 참조가 도움이됩니다. 연결과 구성은 매우 간단합니다. 집계는 흔들리는 것입니다. 실제로, 나는 '부분'테스트가 잘 작동한다는 것을 알았습니다 ( '소유권'은 그것에 대해 생각하기에 차선책입니다). 사람은 클럽의 일부가 될 수 있으므로 클럽은 사람들을 모으게됩니다. 클럽이 파괴되면 사람들은 계속 존재합니다.
Huliax

10

컴포지션은 object A포함 object B하고 object A를 생성 할 책임이 있습니다 object B.

구성 관계

우리는 클래스 A가 사용할 클래스 A를 가지고 있습니다.

final class A
{
}

컴포지션 모양에 따라 여러 옵션이 있습니다.

직접 초기화 구성 :

final class B
{
    private $a = new A();
}

생성자 초기화 구성

final class B
{
    private $a;

    public function __construct()
    {
        $this->a = new A();
    }
}

지연 초기화 구성

final class B
{
    private $a = null;

    public function useA()
    {
        if ($this->a === null) {
            $this->a = new A();
        }

        /* Use $this->a */
    }
}

이 클래스 A와와 의 밀접한 관계를 만듭니다 B. 클래스는 B단순히 없이는 존재할 수 없습니다 A. 이것은 의존성 주입 원칙을 크게 위반 하는 것입니다.

종속성은 사용할 수있는 개체 (서비스)입니다. 주입이란 의존성을 종속 오브젝트 (클라이언트)에 전달하는 것입니다. 서비스는 클라이언트 상태의 일부입니다. 클라이언트가 서비스를 구축하거나 찾도록 허용하는 대신 서비스를 클라이언트에 전달하는 것이 패턴의 기본 요구 사항입니다.

new DateTimePHP 나 new std::vector<int>C ++에서 호출하는 것과 같은 구성은 때때로 의미가 있습니다. 그러나 코드 디자인이 잘못되었다는 경고가 더 자주 발생합니다.

(가) 사건에서 class A캐싱에 사용되는 특수 객체가 될 것이다는이 class B항상의 구현을 사용하여 캐시 될 것입니다 class A, 당신은 동적 불량 인을 변경할 제어 할 수 없을 것입니다.

또한, 게으른 초기화 구성 을 사용했다면 즉 object B, useA()메소드 라고 불리는 작업이 있고 작성 object A이 실패한다는 object B것은 갑자기 쓸모가 없습니다.


반면 집계는 DI 원칙 을 따르는 관계 방식입니다 . object B사용할 필요는 object A, 당신은 이미 생성 된 인스턴스를 전달해야 object A하는 object B, 그리고 창조한다 object A실패는 아무것도 처음에 전달되지 것입니다.

간단히 말해 집계는 생성자 주입, 세터 주입 또는 공용 속성 주입 등 종속성 주입 원칙에 대한 UML 표현입니다 .

이들은 모두 집계입니다

가장 엄격한 생성자 주입 ( object B없이는 존재할 수 없음 object A).

final class B
{
    private $a;

    public function __construct(A $a)
    {
        $this->a = $a;
    }
}

Looser ( object Ainside를 사용하거나 사용하지 않을 수 있지만 사용하는 object B경우 먼저 설정해야합니다).

세터를 통해 :

final class B
{
    private $a;

    public function setA(A $a)
    {
        $this->a = $a;
    }
}

공공 재산을 통해 :

final class B
{
    public $a;
}

사용하는 모든 클래스의 구체적인 구현 인 경우 컴포지션보다 집계의 사용법을 정당화하는 좋은 방법은 없지만 인터페이스를 주입하기 시작하거나 C ++ 추상 클래스의 경우 갑자기 집계가 유일한 방법이 될 것입니다 계약을 이행하십시오.


1
코드 예제를 보면 정말 도움이됩니다! 코드가없는 영어로 된 설명은 모두 모호하고 주관적으로 보입니다.
Niko Bellic 2016 년

1

또한 현재 UML 표준의 발췌 내용 :

11.5.4 협회 – 의미 – 표기법

[...] 이진 연관은 집계 = AggregationKind :: shared 또는 집계 = AggregationKind :: composite 인 한쪽 끝을 가질 수 있습니다. 한쪽 끝이 집계 = AggregationKind :: shared를 갖는 경우, 집합 = AggregationKind :: shared 로 표시된 끝의 반대쪽 연결 라인 끝에 끝 장식으로 중공 다이아몬드 가 추가됩니다. 다이아몬드는 협회의 다이아몬드 표기법보다 눈에 띄게 작아야합니다. 집계 = AggregationKind :: composite 와의 연관 도 마찬가지로 해당 끝에 다이아몬드가 있지만 다이아몬드가 채워지 는 방식이 다릅니다 . […]

9.5.4 분류 – 속성 – 표기법

[…] 때로는 하나의 인스턴스가 일련의 인스턴스를 그룹화하는 데 사용되는 환경을 모델링하기 위해 속성이 사용됩니다. 이것을 집계라고합니다. 이러한 상황을 나타 내기 위해 속성에는 AggregationKind 유형의 집계 속성이 있습니다. 전체 그룹을 나타내는 인스턴스는 속성의 소유자에 의해 분류되고 그룹화 된 개인을 나타내는 인스턴스는 속성의 유형에 따라 분류됩니다. AggregationKind는 다음 리터럴 값을 가진 열거입니다.

  • none : 속성에 집계 의미가 없음을 나타냅니다.
  • 공유 : 속성에 공유 집계 의미가 있음을 나타냅니다. 공유 집계의 정확한 의미는 응용 프로그램 영역 및 모델러에 따라 다릅니다.
  • 복합 : 속성이 복합적으로 집계됨을 나타냅니다. 즉, 복합 객체는 작성된 객체의 존재 및 저장에 대한 책임이 있습니다 (11.2.3의 부품 정의 ​​참조). 복합 집계는 한 번에 최대 하나의 복합 객체에 부품 객체를 포함해야하는 강력한 형태의 집계입니다. 복합 객체가 삭제되면 객체 인 모든 해당 부품 인스턴스가 삭제됩니다.

[…]


0

이미 Stackoverflow 에 대한 답변을 게시했습니다 .

기본적으로 집계는 단순한 연결보다 강력하지만 집계 된 개체는 간단한 연결과 같이 서로 "살아"있을 수 있습니다.

집계 된 클래스는 다른 클래스에 의해 집계 될 수 없으므로 컴포지션은 집계보다 훨씬 강합니다. "수명"은 컨테이너에 따라 다릅니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.