Entity-control-boundary

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].

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].

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.

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.

• Patron d'architecture
• Cas d'utilisation
• Processus unifié
• Analyse et conception orientées objet