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 software design that structures the classes composing a
software
Software is a set of computer programs and associated software documentation, documentation and data (computing), data. This is in contrast to Computer hardware, hardware, from which the system is built and which actually performs the work.
...
according to their responsibilities in the use-case realization.
Origin and evolution
The Entity-Control-Boundary approach finds its origin in
Ivar Jacobson
Ivar Hjalmar Jacobson (born 1939) is a Swedish computer scientist and software engineer, known as major contributor to UML, Objectory, Rational Unified Process (RUP), aspect-oriented software development and Essence.
Biography
Ivar Jacobson w ...
's use-case driven
OOSE
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code. The data is in the form of fields (often known as attributes or ''properties''), and the code is in the form of pr ...
method published in 1992
,.
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
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code. The data is in the form of fields (often known as attributes or ''properties''), and the code is in the form of ...
terminology.
It is further developed in the
Unified Process
The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (R ...
, which promotes the use of ECB in the analysis and design activities with the support of
UML stereotypes.
Agile modelling,
and the
ICONIX process elaborated on top of ECB architecture pattern with robustness diagrams.
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.
Robustness diagram
Robustness diagrams allow to visually represent the relation between entities, controls, boundaries and actors.
It uses graphical stereotypes introduced in Jacobson's early work:
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 principle entities should not know about boundaries and controls. In practice however, some variants allow entities, boundaries and controls to subscribe as observer to an entity.
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 computer science, separation of concerns is a design principle for separating a computer program into distinct sections. Each section addresses a separate '' concern'', a set of information that affects the code of a computer program. A concern ...
in the
architecture
Architecture is the art and technique of designing and building, as distinguished from the skills associated with construction. It is both the process and the product of sketching, conceiving, planning, designing, and constructing building ...
by encapsulating business logic that is not directly related to an entity.
The ECB can be used in conjunction with the
hexagonal architecture, whenever the boundaries form the outer adapter layer.
ECB is compatible with the clean architecture which merges ECB principles with other architectural design paradigms.
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
In software and systems engineering, the phrase use case is a polyseme with two senses:
# A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
# A potential scenario ...
*
Unified process
The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (R ...
*
Object-oriented analysis and design
Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development proces ...
Notes and references
{{Reflist
Software design
Architectural pattern (computer science)
Object-oriented programming