web-dev-qa-db-fra.com

Que sont les classes de limite, les classes de contrôle et les classes d'entité dans les diagrammes de classes UML?

J'utilise maintenant NetBeans comme IDE de mon choix et il dispose d'un plugin pour la modélisation UML. Dans le diagramme de classes, il existe des éléments de modèle appelés Boundary Class, Control Class, et Entity Class. Cependant, je ne peux pas en trouver une bonne définition, mais j’ai trouvé ce site sur les diagrammes de classes UML.

umlclass-diagram
78
Thomas Owens

Souvent utilisé avec/dans le cadre de OOAD et de la modélisation métier. La définition de Neil est correcte, mais elle est fondamentalement identique à MVC, mais abstraite pour l’entreprise. Le "bon résumé" est bien fait, donc je ne le copierai pas ici car ce n'est pas mon travail, plus détaillé mais conforme aux points critiques de Neil.

Bon résumé - Conceito: motif de contrôle de limite d'entité

OOAD

19
Ted Johnson

Les diagrammes de robustesse sont écrits après les cas d'utilisation et avant les diagrammes de classe. Ils aident à identifier les rôles des étapes de cas d'utilisation. Vous pouvez les utiliser pour vous assurer que vos cas d'utilisation sont suffisamment robustes pour représenter les exigences d'utilisation du système que vous construisez.

Ils impliquent:

  1. Acteurs
  2. Cas d'utilisation
  3. Entités
  4. Limites
  5. Controls

Alors que le modèle Model-View-Controller est utilisé pour les interfaces utilisateur, le modèle Entity-Control-Boundary Pattern (ECB) est utilisé pour les systèmes. Les aspects suivants de la BCE peuvent être assimilés à une version abstraite de MVC, si cela est utile:

UML notation

Entités (modèle)
Objets représentant des données système, souvent issues du modèle de domaine.

Limites (collaborateur view/service)
Objets faisant interface avec des acteurs du système (par exemple, un utilisateur ou un service externe ). Windows, les écrans et les menus sont des exemples de limites qui interagissent avec les utilisateurs.

Contrôles (contrôleur)
Objets servant de médiateur entre des limites et des entités. Celles-ci servent de colle entre les éléments de frontière et les éléments d'entité, mettant en œuvre la logique nécessaire à la gestion des divers éléments et de leurs interactions. Il est important de comprendre que vous pouvez décider d'implémenter les contrôleurs dans votre conception autrement que comme des objets: de nombreux contrôleurs sont suffisamment simples pour être implémentés en tant que méthode d'entité ou de classe de limite, par exemple.

Quatre règles s'appliquent à leur communication:

  1. Les acteurs ne peuvent parler qu'aux objets de frontière.
  2. Les objets limites ne peuvent parler qu'aux contrôleurs et aux acteurs.
  3. Les objets d'entité ne peuvent parler qu'aux contrôleurs.
  4. Les contrôleurs peuvent parler aux objets de frontière et aux objets d'entité, ainsi qu'à d'autres contrôleurs, mais pas aux acteurs

Communication autorisée: 

         Entity    Boundary   Control
Entity     X                     X
Boundary                         X
Control    X          X          X
181
Pup

Ce sont des stéréotypes de classe utilisés dans l'analyse.

  • les classes de limite sont celles situées à la limite du système - les classes avec lesquelles vous ou d'autres systèmes interagissez

  • les classes d'entités sont vos entités commerciales typiques comme "personne" et "compte bancaire"

  • les classes de contrôle implémentent une logique métier ou autre

16
anon

Le modèle d'entité de contrôle des limites a deux versions:
- structure ancienne, décrite en 127 (entité en tant qu’élément de modèle de données, contrôle en tant que fonction, limite en tant qu’interface d’application)
- nouveau modèle d'objet


En tant que modèle d'objet:
- Boundary est une interface pour "l'autre monde"
- Contrôle dans une logique interne quelconque (comme un service dans un modèle DDD)
- Entity est un serwis de persistance pour les objets (comme un référentiel dans un modèle DDD).
Toutes les classes ont des opérations (voir Anti-pattern du modèle de domaine anémique de Fowler)
Tous sont des composants de modèle dans un modèle MVC. Les règles:
- Seule Boundary fournit des services pour "l'autre monde"
- Boundary ne peut appeler que le contrôle
- Le contrôle peut appeler n'importe qui
- L'entité ne peut appeler personne (!), Seulement être appelée.

jz

4
Jarek Zelinski

En fait, les diagrammes de robustesse (ou diagrammes d'analyse, comme on les appelle parfois) ne sont que des diagrammes de classes spécialisés. Ils font partie du langage UML depuis le début (voir l'ouvrage de Jacobson, Le processus de développement de logiciel unifié, qui fait partie de la série de livres "Three Amigos"). Le livre susmentionné a une bonne définition de ces trois classes aux pages 183-185.

4
KP Haldeman