|
Entity-control-boundary Ne doit pas être confondu avec Stéréotype (UML). 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 évolutionL'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]. PrincipesLe patron d'architecture ECB organise les responsabilités des classes en fonction de leur rôle dans la réalisation de 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 :
Les classes sont ensuite affinées et restructurées ou réorganisées selon les besoins de la conception, par exemple:
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 robustesseLe 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:
Les contraintes de robustesse suivantes s'appliquent:
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 architecturauxIl 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. Articles LiésNotes et références(en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Entity-control-boundary » (voir la liste des auteurs).
|
||||||||||||||||||||||||||||||||||||
