Entité-contrôle-frontière - Entity-control-boundary
La maîtrise-limite entité ( BCE ), ou entité de limite de commande ( EBC ), ou la limite de contrôle de l' entité ( BCE ) est un motif architectural utilisés dans des cas d' utilisation entraîné conception de logiciels orientés objet qui structure les classes composant une logiciel en fonction de leurs responsabilités dans la réalisation du cas d'utilisation.
Origine et évolution
L'approche Entity-Control-Boundary trouve son origine dans Ivar Jacobson de conduit cas d' utilisation OOSE méthode publiée en 1992 , . Il s'appelait à l'origine Entity-Interface-Control (EIC) mais très rapidement le terme « frontière » a remplacé « interface » afin d'éviter la confusion potentielle avec la terminologie du langage de programmation orienté objet .
Il est développé plus avant dans le Processus unifié , qui promeut l'utilisation de l'ECB dans les activités d'analyse et de conception avec le soutien des stéréotypes UML . Modélisation agile et processus ICONIX élaborés au sommet du modèle d'architecture ECB avec des diagrammes de robustesse.
Principe
Le modèle ECB organise les responsabilités des classes en fonction de leur rôle dans la réalisation du cas d'utilisation:
- une entité représente des informations à long terme pertinentes pour les parties prenantes (c'est-à-dire principalement dérivées d'objets du domaine, généralement persistantes);
- une frontière encapsule l'interaction avec des acteurs externes (utilisateurs ou systèmes externes);
- un contrôle assure le traitement nécessaire à l'exécution d'un cas d'utilisation et sa logique métier, et coordonne, les séquences contrôle les autres objets impliqués dans le cas d'utilisation.
Les classes correspondantes sont ensuite regroupées en packages de services, qui sont un ensemble indivisible de classes associées pouvant être utilisées comme unités de fourniture de logiciels.
Les classes ECB sont identifiées pour la première fois lors de l' analyse des cas d'utilisation :
- chaque cas d'utilisation est représenté comme une classe de contrôle;
- chaque relation différente entre un cas d'utilisation et un acteur est représentée comme une classe limite;
- les entités sont dérivées du récit du cas d'utilisation.
Les classes sont ensuite affinées et restructurées ou réorganisées selon les besoins de la conception, par exemple:
- Prise en compte des comportements courants dans différents contrôles de cas d'utilisation
- Identifier une classe frontière centrale pour chaque type d'acteur humain et pour chaque système externe qui fournirait une interface cohérente avec le monde extérieur.
Le modèle ECB suppose que les responsabilités des classes se reflètent également dans les relations et les interactions entre les différentes catégories de classes afin d'assurer la robustesse de la conception.
Diagramme de robustesse
Les diagrammes de robustesse permettent de représenter visuellement la relation entre entités, contrôles, frontières et acteurs. Il utilise des stéréotypes graphiques introduits dans les premiers travaux de Jacobson:
| Représentation | Relation avec | ||||
|---|---|---|---|---|---|
| Rôle | symbole | Acteur | Frontière | Contrôler | Entité |
| Acteur |
|
Oui | Oui | Non | Non |
| Frontière |
|
Oui | Partie / tout | Oui | Non |
| Contrôler |
|
Non | Oui | Oui | Oui |
| Entité |
|
Non | Non | Oui | Oui |
Les contraintes de robustesse suivantes s'appliquent:
- Les acteurs ne peuvent connaître et communiquer qu'avec les frontières
- Les frontières peuvent communiquer uniquement avec les acteurs et les contrôles.
- Les contrôles peuvent connaître et communiquer avec les limites et les entités, et si nécessaire d'autres contrôles
- Les entités ne peuvent connaître que d'autres entités mais peuvent également communiquer avec les contrôles;
En principe, les entités ne devraient pas connaître les limites et les contrôles. Dans la pratique cependant, certaines variantes permettent aux entités, aux limites et aux contrôles de s'abonner en tant qu'observateur à une entité.
De même, la contrainte d'une classe frontière ne sachant pas sur les autres classes limites ne s'applique qu'au niveau le plus élevé, et non entre les classes qui coopèrent pour implémenter la même frontière.
Relation avec d'autres modèles architecturaux
Il existe une certaine similitude entre l'ECB et le modèle-vue-contrôleur (MVC): les entités appartiennent au modèle et les vues appartiennent aux limites. Cependant, le rôle du contrôle ECB est très différent de celui du contrôleur MVC, car il encapsule également la logique métier de cas d'utilisation alors que le contrôleur MVC traite les entrées de l'utilisateur qui seraient de la responsabilité de la frontière dans ECB. Le contrôle de la BCE augmente la séparation des préoccupations dans l' architecture en encapsulant une logique métier qui n'est pas directement liée à une entité.
L'ECB peut être utilisé en conjonction avec l' architecture hexagonale , chaque fois que les limites forment la couche d'adaptateur externe.
ECB est compatible avec l'architecture épurée qui fusionne les principes ECB avec d'autres paradigmes de conception architecturale. L'architecture propre place les entités au cœur et les entoure d'un anneau de cas d'utilisation (c'est-à-dire contrôle ECB) et d'un anneau avec des passerelles et des présentateurs (c'est-à-dire des limites ECB). Cependant, une architecture propre nécessite une dépendance unidirectionnelle de l'extérieur vers l'intérieur, ce qui nécessite de diviser les contrôles ECB en logique de cas d'utilisation et en coordination d'objets.