L' « Entity-Control-Boundary (ECB) » ou « Entity-Boundary-Control (EBC) », ou « Boundary-Control-Entity (BCE) », qui pourrait être traduit en français par « Entité-Contrôle-Frontière », est un patron d'architecture utilisé pour la conception de logiciels orientés objet. Il vise à structurer les classes selon leurs responsabilités dans la mise en œuvre de cas d'utilisations.
Origine et évolution
L'approche ECB trouve son origine dans la méthode OOSE d'Ivar Jacobson publiée en 1992. Cette méthode est pilotée par les cas d'utilisation et cherche une approche systémique permettant de transformer ceux-ci en une conception[1],[2]. À l'origine l'approche est appelée « Entity-Interface-Control (EIC) » , mais très rapidement, le terme « frontière » remplace « interface » en raison de la confusion possible de ce concept avec la terminologie des langage de programmation orienté objet.
ECB s'est ensuite développée dans le contexte du processus unifié, qui encourage l'utilisation de l'approche ECB pour les activités d'analyse et de conception, en ayant recours aux stéréotypes UML[3]. Des méthodes agiles basées sur la modélisation comme « Agile modeling » de Scott Ambler[4],[5] ou ICONIX[6] ont également utilisées le patron d'architecture ECB qui est à la base des diagrammes de robustesse préconisés par ces méthodes[7].
Principes
Le patron d'architecture ECB organise les responsabilités des classes en fonction de leur rôle dans la réalisation de cas d'utilisation :
une entité représente une information de longue durée qui est pertinente pour les parties prenantes (c'est-à-dire principalement des objets de domaine, et généralement des données persistantes);
une « frontière » (« boundary » en anglais) encapsule l'interaction avec des acteurs externes (utilisateurs humains ou systèmes externes);
un « contrôle » assure les traitements requis pour l'exécution d'un cas d'utilisation et de sa logique métier, et coordonne les interactions entre les autres objets impliqués dans le cas d'utilisation.
Les classes correspondantes sont ensuite regroupées dans des packages de services. Ceux-ci constituent des ensembles indivisibles de classes liées offrant une fonctionnalité. Ils peuvent être utilisés comme des unités indépendantes de distribution du logiciel.
Dans un premier temps, les classes ECB sont identifiées lors de l'analyse des cas d'utilisation :
chaque cas d'utilisation est représenté par une classe de contrôle;
chaque relation distincte entre un cas d'utilisation et un acteur est représentée par une classe de frontière;
les entités sont dérivées du récit narratif 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:
en factorisant les comportements communs à plusieurs contrôles;
en définissant une classe frontière centrale pour chaque type d'acteur humain et pour chaque système externe afin de fournir au monde extérieur une interface cohérente et homogène.
Le patron d'architecture ECB implique que les responsabilités des classes se reflètent également dans les interactions entre les différentes catégories de classes afin de garantir la robustesse de la conception[8],[9].
Diagramme de robustesse
Le diagramme de robustesse permet de représenter visuellement la relation entre entités, contrôles, frontières et acteurs[4] sans nécessairement passer par les cas d'utilisation. Il utilise des stéréotypes graphiques introduits par Jacobson dès ses premiers travaux:
Représentation
Relation avec
Rôle
symbole
Acteur
Frontière
Contrôle
Entité
Acteur
Oui
Oui
Non
Non
Frontière
Oui
Partie / Tout
Oui
Non
Contrôle
Non
Oui
Oui
Oui
Entité
Non
Non
Oui
Oui
Les contraintes de robustesse suivantes s'appliquent:
Les acteurs connaissent uniquement les frontières avec lesquelles ils peuvent communiquer;
Les frontières ne peuvent communiquer qu'avec les acteurs et les contrôles.
Les contrôles peuvent se référer à et communiquer avec les frontières, les entités et, si nécessaire, d'autres contrôles;
Les entités peuvent se référer à d'autres entités. Les entités peuvent communiquer entre elles et avec les contrôles;
En principe, il n'y a pas de relation navigable des entités vers les frontières et les contrôles. Cependant, dans la pratique, certaines variantes du patron ECB permettent aux entités, aux frontières et aux contrôles de s’abonner en tant qu’observateur à une entité.
De même, la contrainte qu'une classe frontière ne soit pas liée à d'autres classes frontières ne s'applique qu'au niveau le plus élevé. Cette restriction ne concerne pas les classes qui coopèrent pour implémenter une même frontière.
Relation avec d'autres modèles architecturaux
Il existe certaines similitudes entre ECB et le patron Modèle-vue-controleur (MVC): les entités appartiennent au modèle et les vues sont des éléments des frontières. Cependant, le rôle du contrôle ECB est très différent de celui du contrôleur MVC, car il englobe également la logique métier des cas d'utilisation, tandis que le contrôleur MVC traite les entrées utilisateur qui seraient de la responsabilité de la frontière dans le schéma ECB. Le contrôle du schéma ECB accroît la séparation des préoccupations dans l’ architecture logicielle en encapsulant la logique métier lorsque celle-ci n’est pas directement liée à une entité[2] .
ECB peut être utilisée conjointement avec l'architecture hexagonale, lorsque les classes frontières forment la couche externe des adaptateurs de l'architecture hexagonale[10].
ECB est compatible avec l’« architecture épurée » de Robert C. Martin (« clean architecture ») qui fusionne les principes ECB avec d’autres conceptions architecturales[11],[12]. L’architecture de Martin place les entités au cœur de l'application et les entoure d’un anneau pour la logique des cas d’utilisation (contrôle dans la terminologie ECB) et d’un anneau avec passerelles et présentateurs (frontières dans la logique ECB). Cependant, l'architecture dite épurée requiert que toutes les dépendance soient unidirectionnelle d'un anneau extérieur vers un anneau intérieur, ce qui nécessite de décomposer les contrôles ECB en séparant la logique métier des autres responsabilités.
↑(en) Jacobson, Ivar., Object-oriented software engineering : a use case driven approach, New York, ACM Press, , 130-133 p. (ISBN0-201-54435-0, OCLC26132801, lire en ligne)
↑(en) Dugerdil, « Architecting mobile enterprise app: a modeling approach to adapt enterprise applications to the mobile », Proceedings of the 2013 ACM workshop on Mobile development lifecycle - MobileDeLi '13, Indianapolis, Indiana, USA, ACM Press, , p. 9–14 (ISBN9781450326032, DOI10.1145/2542128.2542131, lire en ligne)
↑(en) Daschner, Sebastian,, Architecting modern Java EE applications : designing lightweight, business-oriented enterprise applications in the age of cloud, containers, and Java EE 8, Packt Publishing, , section "Entity Control Boundary" (ISBN978-1-78839-712-4, OCLC1008993521, lire en ligne)
