Guidelines: Analysis Class
 Analysis Class |
Analysis classes represent an early conceptual model for ‘things in the system which have responsibilities and behavior’. They eventually evolve into classes and subsystems in the Design Model. |
Topics
Analysis Class Stereotypes 
Analysis classes may be stereotyped as one of the following:
- Boundary classes
- Control classes
- Entity classes
Apart from giving you more specific process guidance when finding classes, this stereotyping results in a robust object model because changes to the model tend to affect only a specific area. Changes in the user interface, for example, will affect only boundary classes. Changes in the control flow will affect only control classes. Changes in long-term information will affect only entity classes. However, these stereotypes are specially useful in helping you to identify classes in analysis and early design. You should probably consider using a slightly different set of stereotypes in later phases of design to better correlate to the implementation environment, the application type, and so on.
Boundary Class
A boundary class is a class used to model interaction between the system's surroundings and its inner workings. Such interaction involves transforming and translating events and noting changes in the system presentation (such as the interface).
Boundary classes model the parts of the system that depend on its surroundings. Entity classes and control classes model the parts that are independent of the system's surroundings. Thus, changing the GUI or communication protocol should mean changing only the boundary classes, not the entity and control classes.
Boundary classes also make it easier to understand the system because they clarify the system's boundaries. They aid design by providing a good point of departure for identifying related services. For example, if you identify a printer interface early in the design, you will soon see that you must also model the formatting of printouts.
Common boundary classes include windows, communication protocols, printer interfaces, sensors, and terminals. You do not have to model routine interface parts, such as buttons, as separate boundary classes if you are using a GUI builder. Generally the entire window is the finest grained boundary object. Boundary classes are also useful for capturing interfaces to possibly nonobject oriented API's, such as legacy code.
You should model boundary classes according to what kind of boundary they represent. Communication with another system and communication with a human actor (through a user interface) have very different objectives. During user-interface modeling, the most important concern is how the interface will be presented to the user. During system-communication modeling, the most important concern is the communication protocol.
A boundary object (an instance of a boundary class) can outlive a use case instance if, for example, it must appear on a screen between the performance of two use cases. Normally, however, boundary objects live only as long as the use case instance.
Control Class
A control class is a class used to model control behavior specific to one or a few use cases. Control objects (instances of control classes) often control other objects, so their behavior is of the coordinating type. Control classes encapsulate use-case specific behavior.
The behavior of a control object is closely related to the realization of a specific use case. In many scenarios, you might even say that the control objects "run" the use-case realizations. However, some control objects can participate in more than one use-case realization if the use-case tasks are strongly related. Furthermore, several control objects of different control classes can participate in one use case. Not all use cases require a control object. For example, if the flow of events in a use case is related to one entity object, a boundary object may realize the use case in cooperation with the entity object. You can start by identifying one control class per use-case realization, and then refine this as more use-case realizations are identified and commonality is discovered.
Control classes can contribute to understanding the system because they represent the dynamics of the system, handling the main tasks and control flows.
When the system performs the use case, a control object is created. Control objects usually die when their corresponding use case has been performed.
Note that a control class does not handle everything required in a use case. Instead, it coordinates the activities of other objects that implement the functionality. The control class delegates work to the objects that have been assigned the responsibility for the functionality.
Entity Class
An entity class is a class used to model information and associated behavior that must be stored. Entity objects (instances of entity classes) are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object. They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system.
An entity object is usually not specific to one use-case realization; sometimes, an entity object is not even specific to the system itself. The values of its attributes and relationships are often given by an actor. An entity object may also be needed to help perform internal system tasks. Entity objects can have behavior as complicated as that of other object stereotypes. However, unlike other objects, this behavior is strongly related to the phenomenon the entity object represents. Entity objects are independent of the environment (the actors).
Entity objects represent the key concepts of the system being developed. Typical examples of entity classes in a banking system are Account and Customer. In a network-handling system, examples are Node and Link.
If the phenomenon you wish to model is not used by any other class, you can model it as an attribute of an entity class, or even as a relationship between entity classes. On the other hand, if the phenomenon is used by any other class in the design model, you must model it as a class.
Entity classes provide another point of view from which to understand the system because they show the logical data structure, which can help you understand what the system is supposed to offer its users.
Association Restrictions
The following are allowable:
- Associations between two Boundary classes, for instance, to describe how a specific window is related to other boundary objects.
- Associations from a Boundary class to an Entity class, because boundary objects might need to keep track of certain entity objects between actions in the boundary object.
The following should be avoided:
- Associations from a Boundary class to a Control class, because it is not necessary to model this kind of reference between control and boundary objects as their relations last such a short time.
The following are allowable:
- Associations between Control classes and Entity classes, because control objects might need to keep track of certain entity objects between actions in the control object.
The following should be avoided:
- Associations between Control and Boundary classes, because it is not necessary to model this kind of reference between control and boundary objects as their relations last such a short time.
- Associations between Control classes, because it is not necessary to model this kind of reference between control objects, because their relations last such a short time.
Entity classes should only have associations to other entity classes. Entity class objects tend to be long-lived; control and boundary class objects tend to be very short-lived. It is not advisable to form associations between classes whose objects lifetimes differ so greatly.
Summary of association navigability recommendations
| From\To (navigability) |
Boundary |
Entity | Control |
Boundary |
yes |
yes | avoid |
Entity |
no* |
yes | no* |
Control |
avoid |
yes | yes |
Recommended use of associations between different stereotypes of classes.
* Use the 'subscribes-to' association instead, with the control class subscribing to certain events in the entity class object.
