Compreendendo melhor a composição UML

5

A diferença entre Composição e Agregação em UML (e às vezes também em programação) é que, com Composição, o tempo de vida dos objetos que compõem o composto (por exemplo, um mecanismo e um volante em um carro) depende do objeto composto. Enquanto com Agregação, o tempo de vida dos objetos que compõem o composto é independente do composto.

No entanto, não tenho certeza sobre algo relacionado à composição em UML.

Diga que ClassA é composto de um objeto de ClassB:

class ClassA{
    ClassB bInstance;
    public ClassA(){
        bInstance = new ClassB();
    }
}

Este é um exemplo de composição, porque bInstance depende da vida útil do objeto delimitador.

No entanto, em relação à notação UML - não tenho certeza se anoto a relação entre ClassA e ClassB com um diamante preenchido (composição) ou um diamante branco (agregação).

Isso ocorre porque, embora o tempo de vida de alguns ClassB instâncias dependa de ClassA instances - pode haver ClassB instâncias em qualquer outro lugar do programa - não apenas em ClassA instâncias .

A questão é: se alguns Objetos ClassB são compostos com objetos ClassA (e, portanto, são dependentes do tempo de vida dos objetos ClassA) , mas alguns não são - o relacionamento entre as duas classes na UML seria uma agregação ou uma relação de composição ??

    
por Aviv Cohn 26.05.2014 / 19:49
fonte

6 respostas

0

Resposta curta: a UML não se preocupa com classes internas. Classes internas são um recurso em Java e algumas outras linguagens, mas nem todas as suportam. Na verdade, as classes internas geralmente são um detalhe de implementação que muitas vezes não é mostrado nos diagramas UML.

Agora, se o código de exemplo for Java (mas poderia ser qualquer outra coisa), eu diria que ele poderia (1) ser agregação, ou nem ... ou talvez composição

Como exemplo de agregação, você pode ter uma classe de coleção, onde cada item é armazenado em uma classe interna. Um exemplo disso seria o HashMap.Entry em Java, mas é estático e protegido por pacotes, como é usado em outras classes em java.util.

E como um exemplo de nenhum dos dois seria se você quiser ter uma classe auxiliar, mas não quiser criar uma classe de nível superior ou uma classe interna anônima. Por exemplo, se você quiser instanciar um Comparador personalizado.

Por último, mas não menos importante, pode ser um exemplo de má composição.

(1) Eu digo que poderia ser, porque há muitos exemplos realmente ruins ou composição e agregação na maioria das bases de código em que trabalhei.

    
por 26.05.2014 / 23:59
fonte
0

Acredito que você respondeu à sua pergunta quando disse "a vida útil dos objetos que compõem o composto (por exemplo, um motor e um volante de um carro) depende do objeto composto". No seu exemplo de código, o objeto B deixaria de existir quando o objeto A desapareceu. Por outro lado,

class ClassA{
   ClassB bInstance;
  public ClassA(ClassB classB){
    bInstance = classB;
  }
}

se tornaria um agregado em sua UML, pois o objeto B pode existir independentemente do objeto A.

EDITAR (após sua atualização) Eu tentei imaginar uma instância em que a Classe B dependeria da Classe A e aqui está o que eu coloco:

class ClassA{
   bool bDependsOnA = // true or false based on some logic
   ClassB bInstance;
   public ClassA(){
     if(bDependsOnA){
        bInstance = new ClassB(this);
      }else{
        bInstance = new ClassB();
    }
  }
}

class ClassB{
   ClassA aInstance;
  public ClassB()
  { 
     aInstance = null;
  }
  public ClassB(ClassA classA ){
    aInstance = classA;
  }
}

A classe B é um composto da classe A, a classe B tem uma associação fraca com a classe A. Um artigo interessante que encontrei, enquanto pensava na sua pergunta ( link )

A propósito, por melhor que seja a UML, não é perfeita. Agregação vs composição está acontecendo há muito tempo. Às vezes, não está claro o que é o quê. Pessoalmente, descobri que quando estou preso tentando decidir qual é qual, isso significa que meu design é complexo demais e pode ser simplificado:)

    
por 27.05.2014 / 00:54
fonte
0

Aqui está outra maneira de ver:

Como @rommik apontou com seu exemplo, você também pode passar o objeto B como um argumento de construtor, desacoplando assim seu ciclo de vida de A . Agora esqueça o diagrama UML correspondente e pense primeiro nas suas classes. Você tem (pelo menos estas) duas opções:

class A { ... public A(B bInstance) { ...} }

ou

class A { B bInstance = new B(); ... }

Existem boas razões para que ambos sejam usados, dependendo das circunstâncias, e eles se encaixam naturalmente na semântica de agregação e composição da UML, respectivamente.

Por outro lado, sua edição propõe que a classe A tenha algumas instâncias , onde a vida útil do objeto B dependa da A instance e algumas outras instâncias , onde isso não acontece.

Deixe de lado a UML e veja isso simplesmente do ponto de vista do design geral. Sua classe A subitamente ficou muito mais complicada. Claro, não é de admirar que você esteja tendo problemas em descobrir como representá-lo em um diagrama UML. Heck, você até teria problemas para explicar a alguém mais o que o A faz: "Ele obtém B objetos e faz isto e aquilo com eles .. ah exceto quando cria seus próprios objetos B ..". Compare isso com as duas variantes claras acima.

Em resumo, o fato de você ter duas maneiras semanticamente diferentes de modelar seu design na UML não é um problema da própria UML nem sua compreensão dela. É apenas um ponteiro para lembrá-lo de que o design da sua própria classe é ambíguo em relação à sua semântica.

    
por 27.05.2014 / 07:15
fonte
0

Sua composição destina-se a modelar situações em que um objeto faz parte de outro objeto na forma como um determinado parafuso pode fazer parte de um caminhão? Nem todo parafuso faz parte de um caminhão. Nesse caso, você não deve usar o relacionamento de composição. A UML2 inclui outra noção de um objeto composto que tem partes formando um todo.

Se a classe A é uma agregação composta da classe B , então todas as instâncias de B devem ter um instância relacionada de A que a agrega. Não é o que você quer.

Na situação que você descreve, as instâncias da classe A são objetos compostos que contêm instâncias da classe B como partes. Isso não exclui a possibilidade de ocorrências de B que não fazem parte de A objetos. A relação entre A e B não é agregação nem composição. A terminologia (relação de composição vs estrutura composta / parte) é confusa, mas estamos presos a ela.

    
por 21.11.2014 / 02:11
fonte
0

A questão de saber se a relação entre ClassA e ClassB é composta não depende de haver também instâncias de ClassB que não fazem parte de ClassA . No seu exemplo, desde que nenhuma referência ao ClassB -instance interno (aquele contido em sua variável de instância bInstance ) possa escapar da instância contêiner de ClassA (o que poderia acontecer se você tivesse um getter público para bInstance , por exemplo), você está perfeitamente bem modelando isso como um relacionamento composto.

Em seu modelo UML, é a multiplicidade do container final que determina se todas as ClassB -instances devem ou não ser parte de ClassA . A multiplicidade do final do contêiner nunca pode ser diferente de [0..1] ou [1..1] em primeiro lugar, é claro (caso contrário, isso violaria o princípio de que um objeto pode, no máximo, fazer parte de uma única composição); se for [0..1] , você está dizendo que também pode haver ClassB -instances que não fazem parte de ClassA ; se for [1..1] , esse não é o caso.

Veja também link para uma discussão esclarecedora.

    
por 18.07.2016 / 17:29
fonte
0

É composição porque você está modelando a relação entre

classes A e B. NÃO as relações entre a Classe B e o resto de

o programa.

A classe C usa instâncias da classe B no diagrama acima, mas faz

não termina necessariamente o tempo de vida das instâncias da Classe B. Elas são capazes

para existir fora da classe C por causa da função getB (). Um exemplo

pode ser um álbum de músicas. Você pode transferir as músicas do Álbum para

outro então destrua o antigo álbum.

Por outro lado, a Classe A é composta de uma instância de Classe B porque não há como

instâncias da classe B podem existir fora da classe A. Um exemplo é a vida

de uma pessoa e seus segredos. Toda pessoa tem segredos. Ninguém sabe

sobre esses segredos e quando essa pessoa morre, seus segredos morrem com

eles.

    
por 03.08.2018 / 05:33
fonte