{{Short description|Architectural concept used in software design}} {{Distinguish|Stereotype (UML)}}
The '''entity–control–boundary''' ('''ECB'''), or '''entity–boundary–control''' ('''EBC'''), or '''boundary–control–entity''' ('''BCE''') is an architectural pattern used in use-case–driven object-oriented programming that structures the classes composing high-level object-oriented source code according to their responsibilities in the use-case realization.
== Origin and evolution == The entity–control–boundary approach finds its origin in Ivar Jacobson's use-case–driven object-oriented software engineering (OOSE) method published in 1992.<ref>{{Cite book|title=Object-oriented software engineering: a use case driven approach|last=Jacobson, Ivar.|date=1992|publisher=ACM Press|isbn=0201544350|location=[New York]|pages=[https://archive.org/details/objectorientedso00jaco/page/130 130–133]|oclc=26132801|url=https://archive.org/details/objectorientedso00jaco/page/130}}</ref><ref name=":0">{{Cite web|url=http://tedfelix.com/software/jacobson1992.html|title=Reading notice on Object Oriented Software Engineering, Ivar Jacobson, et al. (1992)|website=tedfelix.com|access-date=2019-08-14}}</ref> It was originally called ''entity–interface–control'' (''EIC'') but very quickly the term "''boundary''" replaced "''interface''" in order to avoid the potential confusion with object-oriented programming language terminology.
It is further developed in the Unified Process, which promotes the use of ECB in the analysis and design activities with the support of UML stereotypes.<ref>{{Cite book|title=The unified software development process|date=1999|publisher=Addison-Wesley|others=Jacobson, Ivar., Booch, Grady., Rumbaugh, Jim.|isbn=0201571692|location=Reading, Massachusetts|pages=44, 183–188, 202–205, 256–257, 439|oclc=636807532}}</ref> Agile modelling<ref name=":1">{{Cite web|url=https://agilemodeling.com/artifacts/robustnessDiagram.htm|title=Robustness Diagrams: An Agile Introduction|last=Scott Ambler|website=agilemodeling.com|access-date=2019-08-14}}</ref><ref>{{Cite book|title=The object primer : agile modeling-driven development with UML 2.0|last=Ambler, Scott W., 1966-|date=2004|publisher=Cambridge University Press|isbn=0521540186|edition= 3rd|location=Cambridge, UK|oclc=54081540}}</ref> and the ICONIX process<ref>{{Cite web|url=https://www.theregister.co.uk/Print/2007/12/14/robustness_analysis_book_extract_3/|title=Close the gap between analysis and design • The Register|website=www.theregister.co.uk|access-date=2019-08-14}}</ref> elaborated on top of the ECB architecture pattern with robustness diagrams.<ref>{{Cite book|last=Dugerdil|first=Philippe|title=Proceedings of the 2013 ACM workshop on Mobile development lifecycle |chapter=Architecting mobile enterprise app |date=2013|chapter-url=http://dl.acm.org/citation.cfm?doid=2542128.2542131|language=en|location=Indianapolis, Indiana, USA|publisher=ACM Press|pages=9–14|doi=10.1145/2542128.2542131|isbn=9781450326032|s2cid=14408662 }}</ref>
== Principle == The ECB pattern organises the responsibilities of classes according to their role in the use-case realization:
* an entity represents long-lived information relevant for the stakeholders (i.e. mostly derived from domain objects, usually persistent); * a boundary encapsulates interaction with external actors (users or external systems); * a control ensures the processing required for the execution of a use case and its business logic, and coordinates, sequences controls other objects involved in the use case.
The corresponding classes are then grouped into service packages, which are an indivisible set of related classes that can be used as software delivery units.
ECB classes are first identified when use cases are analyzed:
* every use case is represented as a control class; * every different relation between a use case and an actor is represented as a boundary class; * entities are derived from the use-case narrative.
The classes are then refined and re-structured or reorganized as needed for the design, for example:
* Factoring out common behaviors in different use-case controls * Identifying a central boundary class for each kind of human actor and for each external system that would provide a consistent interface to the outside world.
The ECB pattern assumes that the responsibilities of the classes is also reflected in the relations and interactions between the different categories of classes in order to ensure the robustness of the design.<ref>{{Cite web|url=https://posomas.isse.de/PosoMAS-Scrum/core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html|title=Guideline: Entity-Control-Boundary Pattern|website=posomas.isse.de|access-date=2019-08-14}}</ref><ref>{{Cite book|title=Architecting modern Java EE applications : designing lightweight, business-oriented enterprise applications in the age of cloud, containers, and Java EE 8|last=Daschner, Sebastian|date=2017|publisher=Packt Publishing|isbn=9781788397124|pages=section "Entity Control Boundary"|oclc=1008993521}}</ref>
== Robustness diagram == Robustness diagrams allow to visually represent the relation between entities, controls, boundaries and actors.<ref name=":1" /> It uses graphical stereotypes introduced in Jacobson's early work: {| class="wikitable" ! colspan="2" |Representation ! colspan="4" |Relation with |- !Role !Symbol !Actor !Boundary !Control !Entity |- |Actor |frameless|100x100px |Yes |Yes |No |No |- |Boundary |frameless|88x88px |Yes |Part/whole |Yes |No |- |Control |frameless|99x99px |No |Yes |Yes |Yes |- |Entity |frameless|103x103px |No |No |Yes |Yes |}
The following robustness constraints apply:
* Actors may only know and communicate with boundaries * Boundaries may communicate with actors and controls only. * Controls may know and communicate with boundaries and entities, and if needed other controls * Entities may only know about other entities but could communicate also with controls;
In theory, entities should not know about boundaries and controls. In practice however, entities may publish events, which boundaries and controls can observe without the entity knowing about them. This creates the communication from entities to boundaries and controls possible.
Similarly, the constraint of a boundary class not knowing about other boundary classes only applies at the highest level, and not between classes that cooperate to implement the same boundary.
== Relation to other architectural patterns == There is some similarity between ECB and model–view–controller (MVC): entities belong to the model, and views belongs to boundaries. However the role of the ECB-control is very different from MVC-controller, since it encapsulates also use-case business logic whereas the MVC controller processes user input which would be of the responsibility of the boundary in ECB. The ECB control increases separation of concerns in the architecture by encapsulating business logic that is not directly related to an entity.<ref name=":0" />
The ECB can be used in conjunction with the hexagonal architecture, whenever the boundaries form the outer adapter layer.<ref>{{Cite web|url=https://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm|title=The Entity-Control-Boundary Pattern|website=www.cs.sjsu.edu|access-date=2019-08-14}}</ref>
ECB is compatible with the clean architecture which merges ECB principles with other architectural design paradigms.<ref>{{Cite web|url=https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html|title=The Clean architecture {{!}} Clean Coder Blog|last=Martin|first=Robert, C.|date=2012-08-12|website=blog.cleancoder.com|access-date=2019-08-12}}</ref><ref>{{Cite book|title=Clean architecture : a craftsman's guide to software structure and design|last=Martin, Robert C.|publisher=Prentice Hall|year=2017|isbn=978-0-13-449416-6|oclc=1004983973}}</ref> Clean architecture places entities at the core, and surround them with a use-case ring (i.e. ECB control) and a ring with gateways and presenters (i.e. ECB boundaries). However, clean architecture requires a one-way dependency from outside to inside, which requires to split ECB controls into use-case logic and object coordination.
== See also == * Architectural patterns * Use case * Unified process * Object-oriented analysis and design
== Notes and references == {{Reflist}}
Category:Software design Category:Architectural pattern (computer science) Category:Object-oriented programming