Em diagramas de classes UML, o que são classes de limite, classes de controle e classes de entidade?

Agora estou usando o NetBeans como meu IDE preferido, e ele tem um plug-in para modelagem UML. No diagrama de classe, há elementos de modelo conhecidos como Boundary Class, Control Classe Entity Class. No entanto, não consigo encontrar uma boa definição deles, mas encontrei este site em diagramas de classes UML.

Os diagramas de robustez são escritos após os casos de uso e antes dos diagramas de classe. Eles ajudam a identificar as funções das etapas do caso de uso. Você pode usá-los para garantir que seus casos de uso sejam suficientemente robustos para representar os requisitos de uso do sistema que você está construindo.

Eles envolvem:

1. Atores
2. Casos de Uso
3. Entidades
4. Limites
5. Controles

Enquanto o padrão Model-View-Controller é usado para interfaces de usuário, o padrão Entity-Control-Boundary (ECB) é usado para sistemas. Os seguintes aspectos do ECB podem ser comparados a uma versão abstrata do MVC, se isso for útil:

Entidades (modelo)
Objetos que representam dados do sistema, geralmente do modelo de domínio.

Limites (visão / colaborador de serviço)
Objetos que fazem interface com os atores do sistema (por exemplo, um usuário ou serviço externo ). Janelas, telas e menus são exemplos de limites que fazem interface com os usuários.

Controla (controlador)
Objetos que fazem a mediação entre fronteiras e entidades. Eles servem como a cola entre os elementos de fronteira e os elementos de entidade, implementando a lógica necessária para gerenciar os vários elementos e suas interações. É importante entender que você pode decidir implementar controladores em seu projeto como algo diferente de objetos - muitos controladores são simples o suficiente para serem implementados como um método de uma entidade ou classe de fronteira, por exemplo.

Quatro regras se aplicam à sua comunicação:

1. Atores só podem falar com objetos de fronteira.
2. Objetos de fronteira só podem falar com controladores e atores.
3. Os objetos de entidade só podem se comunicar com os controladores.
4. Os controladores podem falar com objetos de fronteira e objetos de entidade e com outros controladores, mas não com os atores

Comunicação permitida:

         Entity    Boundary   Control
Entity     X                     X
Boundary                         X
Control    X          X          X

Freqüentemente usado com / como parte do OOAD e modelagem de negócios. A definição de Neil está correta, mas é basicamente idêntica a MVC, mas apenas abstraída para o negócio. O "Bom resumo" está bem feito, então não vou copiá-lo aqui, pois não é meu trabalho, mais detalhado, mas em linha com os pontos de Neil.

Bom resumo - Conceito: Padrão Entidade-Controle-Fronteira

OOAD

Esses são estereótipos de classe usados ​​na análise.

• classes de fronteira são aquelas na fronteira do sistema - as classes com as quais você ou outros sistemas interagem

• classes de entidade são suas entidades comerciais típicas, como "pessoa" e "conta bancária"

• classes de controle implementam alguma lógica de negócios ou outra

O padrão de Entidade de Controle de Fronteira tem duas versões:
- estrutural antigo, descrito em 127 (entidade como elementos de modelo de dados, controle como uma função, fronteira como uma interface de aplicativo)
- novo padrão de objeto


Como um padrão de objeto:
- Fronteira é uma interface para " outro mundo "
- Controle em qualquer lógica interna (como um serviço no padrão DDD)
- Entidade é um serwis de persistência para objetos (como um repositório no padrão DDD).
Todas as classes têm operações (consulte o antipadrão de modelo de domínio anêmico de Fowler).
Todas elas são um componente do modelo no padrão MVC. As regras:
- Apenas a Boundary fornece serviços para o "outro mundo"
- A Boundary pode ligar apenas para o Controlador
- O Controle pode ligar para qualquer pessoa
- Entidade não pode chamar ninguém (!), Apenas ser chamada.

jz

Na verdade, os diagramas de robustez (ou diagramas de análise, como às vezes são chamados) são apenas diagramas de classes especializados. Eles fazem parte da UML, e têm sido desde o início (consulte o livro de Jacobson, The Unified Software Development Process - parte da série de livros "Three Amigos"). O livro mencionado anteriormente tem uma boa definição dessas três classes nas páginas 183-185.