In UML class diagrams, what are Boundary Classes, Control Classes, and Entity Classes?

Question

I'm now using NetBeans as my IDE-of-choice, and it has a plugin for UML modeling. In the class diagram, there are model elements known as Boundary Class, Control Class, and Entity Class. However, I can't find a good definition of them, but I did find this site on UML Class Diagrams.

Cobol

Wikipedia explains all you need to know about the Entity-Boundary-Control pattern and related concepts. It provides lots of sources for additional reading, if you need to know more. – Isador

Answer 1

Robustness diagrams are written after use cases and before class diagrams. They help to identify the roles of use case steps. You can use them to ensure your use cases are sufficiently robust to represent usage requirements for the system you're building.

They involve:

1. Actors
2. Use Cases
3. Entities
4. Boundaries
5. Controls

Whereas the Model-View-Controller pattern is used for user interfaces, the Entity-Control-Boundary Pattern (ECB) is used for systems. The following aspects of ECB can be likened to an abstract version of MVC, if that's helpful:

Entities (model)
Objects representing system data, often from the domain model.

Boundaries (view/service collaborator)
Objects that interface with system actors (e.g. a user or external service). Windows, screens and menus are examples of boundaries that interface with users.

Controls (controller)
Objects that mediate between boundaries and entities. These serve as the glue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions. It is important to understand that you may decide to implement controllers within your design as something other than objects – many controllers are simple enough to be implemented as a method of an entity or boundary class for example.

Four rules apply to their communication:

1. Actors can only talk to boundary objects.
2. Boundary objects can only talk to controllers and actors.
3. Entity objects can only talk to controllers.
4. Controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors

Communication allowed:

         Entity    Boundary   Control
Entity     X                     X
Boundary                         X
Control    X          X          X

Sanfordsanfourd

Judging by the comments, this answer isn't helping people appreciate the difference between "Entity Boundary Control" and MVC. One of them is that a Boundary is not a View; it's an element of the system that manages communication with elements outside the area under design, whatever that area might be. For example, a PayPal REST API facade inside your system might be a boundary element. Furthermore, your subsystems may have boundaries of their own. Compare this to a View, which is always a View from any perspective, and is always user-facing. – Lactose

This answer does include say the same thing, really: "Boundary: Objects that interface with system actors (e.g. a user or external service)". Anyhow, my point is that they are different: ECB is not a "simplification" of MVC. – Lactose

A point, these stereotype do not seem to be define in UML specification ... – Commitment

Answer 2

Often used with/as a part of OOAD and business modeling. The definition by Neil is correct, but it is basically identical to MVC, but just abstracted for the business. The "Good summary" is well done so I will not copy it here as it is not my work, more detailed but inline with Neil's bullet points.

Good summary - Conceito: Entity-Control-Boundary Pattern

OOAD

Hartshorn

But MVC is only for view layer. – Message

The answer should contain information and not only link to it. Unfortunately the link is dead. – Hahnke

@ted-johnson Any chance for an updated link? Thanks! – Theomania

Updated link to similar site that had content. – Hartshorn

Answer 3

These are class stereotypes used in analysis.

• boundary classes are ones at the boundary of the system - the classes that you or other systems interact with

• entity classes classes are your typical business entities like "person" and "bank account"

• control classes implement some business logic or other

Griseous

Answer 4

Actually, the Robustness Diagrams (or Analysis Diagrams, as they are sometimes called) are just specialized Class Diagrams. They are a part of UML, and have been from the beginning (see Jacobson's book, The Unified Software Development Process - part of the "Three Amigos" series of books). The aforementioned book has a good definition of these three classes on pp 183-185.

Adonis

Answer 5

Boundary Control Entity pattern have two versions:
- old structural, described at 127 (entity as an data model elements, control as an functions, boundary as an application interface)
- new object pattern


As an object pattern:
- Boundary is an interface for "other world"
- Control in an any internal logic (like a service in DDD pattern)
- Entity is an an persistence serwis for objects (like a repository in DDD pattern).
All classes have operations (see Fowler anemic domain model anti-pattern)
All of them is an Model component in MVC pattern. The rules:
- Only Boundary provide services for the "other world"
- Boundary can call only to Controll
- Control can call anybody
- Entity can't call anybody (!), only be called.

jz

Nickel

Answer 6

For the records, the Entity-Boundary-Control pattern comes from use-case driven software development and is much older than Scott Ambler's robustness diagrams who only reused the concept.

The pattern is not part of UML, but is closely related to it because it was promoted by Ivar Jacobson (who initiated it in 1992), Grady Booch and Jim Rumbaugh, the founding fathers of UML... and of the Unified process (UP, RUP). In UML it's just stereotypes like any others.

The Wikipedia explains it best, but Control classes correspond to Use Cases, Boundary classes correspond to the association between a Use-Case and an Actor, and Entities correspond to domain objects identified as being involved in the use-case.

The circulars symbols that most UML tools use with predefined BCE stereotypes are also from Jacobson. The robustness rules are just the transposition of the use-case mapping explained above.

Isador