Artifact: Boundary Class
 Boundary Class |
A boundary class models the interaction between one or more actors and the system. |
| UML representation: | Class, stereotyped as «boundary». |
| Worker: | User-Interface Designer |
| Sample Reports: | Report: Class <class name> |
| More information: | Guidelines: Boundary Class (Modeling the User Interface) |
Purpose 
The following people use the boundary classes:
- implementers for a specification when they implement the classes;
- designers of other parts of the system to understand how their functionality can be used, and what their relationships means;
- use-case designers, to instantiate them in use-case realizations;
- user-interface designers, to instantiate them in use-case storyboards;
- those who design the next version of the system, to understand the functionality in the design model;
- those who test the classes, to plan testing activities.
Properties
Property Name |
Brief Description |
UML Representation |
| Name | The name of the class. | The attribute "Name" on model element. |
| Brief Description | A brief description of the role and purpose of the class. | Tagged value, of type "short text". |
| Responsibilities | The responsibilities defined by the class. | A (predefined) tagged value on the superclass "Type". |
| Relationships | The relationships, such as generalizations, associations, and aggregations, in which the class participates. | Owned by an enclosing package, via the aggregation "owns". |
| Attributes | The attributes defined by the class. | - " - |
| Special Requirements | A textual description that collects all requirements (such as usability requirements and non-functional requirements) on the boundary class that are not considered in the analysis model, but that need to be taken care of during prototyping, design and implementation. | Tagged value, of type "short text". |
| Diagrams | Any diagrams local to the class, such as class diagrams depicting its attributes and responsibilities. | Owned by an enclosing package, via the aggregation "owns". |
Timing
Boundary classes relevant to the usability of the system are identified and described during the inception and/or elaboration phase before the user interface is prototyped, designed, and implemented.
Responsibility
A user-interface designer or an object analyst is responsible for the integrity of the boundary class, ensuring that:
- The class fulfills the requirements made on it from the use-case realizations and use-case storyboards in which it participates.
- The class is as independent as possible of other classes.
- The properties of the class, including its responsibilities, uni-directional relationships, and attributes, are justified and kept consistent with each other.
- The role of the class in bi-directional relationships in which it is involved is clear and intuitive.
- The visibilities of its members, primarily attributes, are correct. A visibility can be "public," "private," and so on.
- The scope of its members, primarily operations and attributes, are correct. A scope is "true" for a type/class scope, and "false" for an object/instance scope.
- The Special Requirements are readable and suit their purpose.
- The diagrams describing the class are readable and consistent with the other properties.
