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. [8] [9]
Robustness diagram
Robustness diagrams allow to visually represent the relation between entities, controls, boundaries and actors. [4] It uses graphical stereotypes introduced in Jacobson's early work:
| Representation | Relation with |
|---|
| Role | Symbol | Actor | Boundary | Control | Entity |
|---|
| Actor |  | Yes | Yes | No | No |
| Boundary |  | Yes | Part/whole | Yes | No |
| Control |  | No | Yes | Yes | Yes |
| Entity |  | 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 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 the architecture by encapsulating business logic that is not directly related to an entity. [2]
The ECB can be used in conjunction with the hexagonal architecture, whenever the boundaries form the outer adapter layer. [10]
ECB is compatible with the clean architecture which merges ECB principles with other architectural design paradigms. [11] [12] 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.
In software engineering, multitier architecture is a client–server architecture in which presentation, application processing and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture.
The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.
A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities. For instance, a data model may specify that the data element representing a car be composed of a number of other elements which, in turn, represent the color and size of the car and define its owner.
In software systems, encapsulation refers to the bundling of data with the mechanisms or methods that operate on the data, or the limiting of direct access to some data, such as an object's components. Encapsulation allows developers to present a consistent and usable interface which is independent of how a system is implemented internally. As one example, encapsulation can be used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods.
Model–view–controller (MVC) is a software architectural pattern commonly used for developing user interfaces that divide the related program logic into three interconnected elements. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.
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 in which a system receives an external request and responds to it.
Grady Booch is an American software engineer, best known for developing the Unified Modeling Language (UML) with Ivar Jacobson and James Rumbaugh. He is recognized internationally for his innovative work in software architecture, software engineering, and collaborative development environments.
Ivar Hjalmar Jacobson 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.
In computing and systems design, a loosely coupled system is one
- in which components are weakly associated with each other, and thus changes in one component least affect existence or performance of another component.
- in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.
The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor." The term actor refers to a group that requires a change in the module.
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 process to guide stakeholder communication and product quality.
The anemic domain model is described as a programming anti-pattern where the domain objects contain little or no business logic like validations, calculations, rules, and so forth. The business logic is thus baked into the architecture of the program itself, making refactoring and maintenance more difficult and time-consuming.
Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.
Domain-driven design (DDD) is a major software design approach, focusing on modeling software to match a domain according to input from that domain's experts.
In software engineering, SOLID is a mnemonic acronym for five design principles intended to make object-oriented designs more understandable, flexible, and maintainable. The principles are a subset of many principles promoted by American software engineer and instructor Robert C. Martin, first introduced in his 2000 paper Design Principles and Design Patterns discussing software rot.
Data, context, and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects. Its goals are:
Responsibility-driven design is a design technique in object-oriented programming, which improves encapsulation by using the client–server model. It focuses on the contract by considering the actions that the object is responsible for and the information that the object shares. It was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.
Entity Component System (ECS) is a software architectural pattern mostly used in video game development for the representation of game world objects. An ECS comprises entities composed from components of data, with systems which operate on entities' components.
The Knowledge Based Software Assistant (KBSA) was a research program funded by the United States Air Force. The goal of the program was to apply concepts from artificial intelligence to the problem of designing and implementing computer software. Software would be described by models in very high level languages (essentially equivalent to first order logic) and then transformation rules would transform the specification into efficient code. The air force hoped to be able to generate the software to control weapons systems and other command and control systems using this method. As software was becoming ever more critical to USAF weapons systems it was realized that improving the quality and productivity of the software development process could have significant benefits for the military, as well as for information technology in other major US industries.
The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters. This makes components exchangeable at any level and facilitates test automation.
This page is based on this
Wikipedia article Text is available under the
CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.
