Computer science and programming
UML Analysis activities – From Use Case to Class Diagram
Miércoles 29 noviembre, 10:16 am
Object-Oriented Software Engineering
- Analysis p 173
- Identifying Associations pp 190
- Identifying Aggregates pp 192
- Identifying Attributes pp 193
In this section, we discuss the use of class diagrams for representing associations among objects. An association shows a relationship between two or more classes. For example, a FieldOfficer writes an EmergencyReport (see Figure 5-13).
Associations have several properties:
- A name to describe the association between the two classes (e.g., Writes in Figure 5-13). Association names are optional and need not be unique globally.
- A role at each end, identifying the function of each class with respect to the associations (e.g., author is the role played by FieldOfficer in the Writes association).
- A multiplicity at each end, identifying the possible number of instances (e.g., *
- indicates a FieldOfficer may write zero or more EmergencyReports, whereas 1
- indicates that each EmergencyReport has exactly one FieldOfficer as author).
Initially, the associations between entity objects are the most important, as they reveal more information about the application domain. According to Abbott’s heuristics (see Table 5-1), associations can be identified by examining verbs and verb phrases denoting a state (e.g., has, is part of, manages, reports to, is triggered by, is contained in, talks to, includes). Every association should be named, and roles should be assigned to each end.
The object model will initially include too many associations if developers include all associations identified after examining verb phrases. In Figure 5-14, for example, we identify two relationships: the first between an Incident and the EmergencyReport that triggered its creation; the second between the Incident and the reporting FieldOfficer. Given that the EmergencyReport and FieldOfficer already have an association modeling authorship, the association between Incident and FieldOfficer is not necessary. Adding unnecessary associations complicates the model, leading to incomprehensible models and redundant information.
Most entity objects have an identifying characteristic used by the actors to access them. FieldOfficers and Dispatchers have a badge number. Incidents and Reports are assigned numbers and are archived by date. Once the analysis model includes most classes and associations, the developers should go through each class and check how it is identified by the actors and in which context.
Aggregations are special types of associations denoting a whole–part relationship. For example, a FireStation consists of a number of FireFighters, FireEngines, Ambulances, and a LeadCar. A State is composed of a number of Counties that are, in turn, composed of a number of Townships (Figure 5-15). An aggregation is shown as a association with a diamond on the side of the whole part.
There are two types of aggregation, composition and shared. A solid diamond denotes composition. A composition aggregation indicates that the existence of the parts depends on the whole. For example, a County is always part of exactly one State, a Township is always part of a County. As political boundaries do not change often, a Township will not be part of or shared with another County.
A hollow diamond denotes a shared aggregation relationship, indicating the whole and the part can exist independently. For example, although a FireEngine is part of at most one FireStation at the time, it can be reassigned to a different FireStation during its life time. Aggregation associations are used in the analysis model to denote whole–part concepts. Aggregation associations add information to the analysis model about how containment concepts in the application domain can be organized in a hierarchy or in a directed graph. Aggregations are often used in the user interface to help the user browse through many instances.
If you are not sure that the association you are describing is a whole–part concept, it is better to model it as a one-to-many association, and revisit it later when you have a better understanding of the application domain.
Attributes are properties of individual objects. For example, an EmergencyReport, as described in Table 5-2, has an emergency type, a location, and a description property (see Figure 5-16).
These are entered by a FieldOfficer when she reports an emergency and are subsequently tracked by the system. When identifying properties of objects, only the attributes relevant to the system should be considered.
Properties that are represented by objects are not attributes. For example, every EmergencyReport has an author that is represented by an association to the FieldOfficer class. Developers should identify as many associations as possible before identifying attributes to avoid confusing attributes and objects. Attributes have:
- A name identifying them within an object. For example, an EmergencyReport may have a reportType attribute and an emergencyType attribute. The reportType describes the kind of report being filed (e.g., initial report, request for resource, final report). The emergencyType describes the type of emergency (e.g., fire, traffic, other). To avoid confusion, these attributes should not both be called type.
- A brief description.
- A type describing the legal values it can take. For example, the description attribute of an EmergencyReport is a string. The emergencyType attribute is an enumeration that can take one of three values: fire, traffic, other. Attribute types are based on predefined basic types in UML
Attributes can be identified using Abbott’s heuristics (see Table 5-1). In particular, a noun
phrase followed by a possessive phrase (e.g., the description of an emergency) or an adjective phrase (e.g., the emergency description) should be examined. In the case of entity objects, any property that must be stored by the system is a candidate attribute.
Note that attributes represent the least stable part of the object model. Often, attributes are discovered or added late in the development when the system is evaluated by the users. Unless the added attributes are associated with additional functionality, the added attributes do not entail major changes in the object (and system) structure. For these reasons, the developers need not spend excessive resources in identifying and detailing attributes that represent less important aspects of the system.
Literature Review by: Larry Francis Obando – Technical Specialist
Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, Caracas.
Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.
Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.
Contact: Ecuador (Quito, Guayaquil, Cuenca)