Pergunta

Normalmente fico muito confuso com a UML e esta situação não é diferente.Digamos que eu tenha uma interface IAnimal, classe Food and Cat:

interface IAnimal {
    void Feed(Food food);
}

class Cat : IAnimal {
    void Feed(Food food) {
        //code
    }
}

Tenho três perguntas sobre como desenhar diagramas de classes UML para estes três elementos:

  • Presumo que devo usar associação entre IAnimal e Food ou Cat and Food.Deveria haver uma seta em um lado da linha de associação; se sim, então de que lado e por que?

  • se eu escrever Feed como um método Ianimal no diagrama, devo escrever um método Feed dentro da classe Cat ou escrevo apenas métodos Cat adicionais?

  • o mais importante:a associação deveria ser entre IAnimal e Comida, Gato e Comida, ou ambos?

Foi útil?

Solução

A UML define uma série de relação tipos.

Os relacionamentos têm várias notações diferentes:

  • Os relacionamentos de associação têm uma notação básica de um caminho sólido
  • Os relacionamentos de dependência têm uma notação básica de uma seta tracejada
  • Os relacionamentos de generalização têm uma notação básica de um caminho sólido com uma ponta de seta triangular
  • Os relacionamentos de realização têm uma notação básica de uma seta tracejada com uma ponta de seta triangular (uma mistura de dependência e generalização)

Pictoricamente

+---------------------------+
|       <<interface>>       |
|           IAnimal         |
+---------------------------+                        +--------+
| + Feed(food: Food) : void |- - - - <<use>> - - - ->|  Food  |
+---------------------------+                        +--------+
              ^
             /_\
              |

              |

              |
        +-----------+
        |    Cat    |
        +-----------+

Aquilo é:

  • O relacionamento entre IAnimal e Food é um uso relação.Isto é mostrado como uma dependência do estereótipo «uso»
  • O relacionamento entre IAnimal e Cat é um realização relação.

Relacionamentos de associação são usados ​​para indicar conexões entre dois ou mais classificadores.Isto implica que pelo menos uma das classes tem um atributo do outro tipo (ou uma coleção).Na verdade, atributos e fins de associação contêm as mesmas informações e podem ser trocados.

Portanto, IMHO, os relacionamentos que você descreve não devem ser modelados como associações.

Outras dicas

Assumindo um diagrama de classes, você deve ter uma associação de "uso" entre Ianimal e comida e A "é uma associação entre CAT e Ianimal e Dog e Ianimal:

    IAnimal ----> Food
     ^   ^
    //   \\
   //     \\
 Cat      Dog

Quão exigente você é sobre esse tipo de coisa depende em grande parte do que você está usando a UML em primeiro lugar.

Se você tem algum tipo de tradutor de UML-to-Code Whizzy, precisa ser exigente (mas parece que você está mais confortável com código do que com caixas e linhas-então por que você usaria essa ferramenta?)

Se você está simplesmente usando a UML para se comunicar com outras pessoas, pode se dar ao luxo de ser um pouco menos exigente.

"Aplicar e padrões" de Craig Larman enfatiza esse ponto, incluindo diagramas que parecem ter sido esboçados em um quadro branco. Uma linha sólida que o padrão UML diz ser pontilhado é bom nesse tipo de diagrama. Então, com pontas de flechas e assim por diante.

Está claro para mim que a linha deve ir de IAnimal para Food.

Se o Arrowhead acrescenta clareza (para leitores humanos) é uma questão de escolha, mas indica um relacionamento unidirecional:

A partir de Esta peça introdutória:

"Em uma associação unidirecional, duas classes estão relacionadas, mas apenas uma classe sabe que o relacionamento existe".

Eu argumentaria que Ianimal teria um alimento, pois é metabolizado, mas se você realmente quiser denotar o Has-A, acho que deve ser uma agregação (diamante aberto) ou símbolo de composição (preenchido em diamante), dependendo do Características de exclusão em cascata.

Existem duas escolas de pensamento com a UML, de acordo com Martin Fowler. Existem os "Sketchers", que usam a notação em quadros brancos e peças de papel estranhas para comunicar o suficiente de suas idéias aos colegas desenvolvedores.

Depois, há quem vê a UML como desenhos de engenharia, onde todos os detalhes de um design devem ser capturados.

Estou firmemente no antigo acampamento. Como ex -engenheiro, posso dizer por experiência pessoal que a UML não tem o poder dos desenhos reais de engenharia para capturar totalmente um design de software.

Se você acreditar neste último, faça um design completo de desktop ou interface da web usando a UML e publique aqui.

1) Nenhuma associação deve ser escrita entre a interface Ianimal e o tipo de alimento. As associações são usadas apenas para conectar tipos com propriedades dentro das classes. POR EXEMPLO

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

Então você deve escrever uma associação indicando a conexão entre esses dois tipos.

O que você deve desenhar é uma dependência indicando que a interface Ianimal depende do tipo de alimento. A dependência é desenhada da mesma forma que a associação na figura acima, basta alterar a linha reta para uma pontilhada.

2) Não, não escreva esses métodos e não escreva dependentes. Deixe todas as anotações apenas na interface Ianimal

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top