J.E.D.I
5. Number the messages according to the chronological order of their invocation. Figure 3.20 shows an example.
Numbering of the messages are as follows:
1. enterAthleteData 2. enterGuardianData
3. submitAthleteRecord 4. saveAthleteRecord
5. addAthlete 6. return done
7. return done
Software Engineering 95
Figure 3.20 With Message Numbers
J.E.D.I
6. Elaborate on the messages by specifying any of the following: repetition, conditions, list of parameters, and return type. Figure 3.21 shows an example.
The elaborated messages are as follows:
1. The enterAthleteData message was elaborated to include the following parameters: lastname, firstname, mi, address, postalCode, telephone,
bday , and gender.
2. The enterGuardianData message was elaborated to include the following parameters: lastname, firstname, mi, address, postalCode and telephone.
3. The submitAthleteRecord message was elaborated to include the parameters, athlete and guardian object which represent the athlete and
guardian information respectively.
4. The saveAthleteRecord message was elaborated to include the parameters, athlete
and guardian object which represent the athlete and guardian
information respectively. Also, two conditions were identified that must be true in order for the message to be executed. They are [isAthleteInfoComplete
= yes] and [isGuardianInfoComplete = yes] , which means that the athlete
record is saved only if the athlete and guardian information are complete.
5. The addAthlete message was elaborated to include the parameters, athlete
and guardian object which represents the athlete and guardian
information respectively.
Software Engineering 96
Figure 3.21 With Elaborated Messages
J.E.D.I
7. Optionally, we can enhance the sequence diagram using the enhanced notation. Figure 3.22 shows an example.
This may not be the only sequence diagram for the Add Athlete Record use case. Other scenario for this Use Case are incomplete athlete information, incomplete guardian
information, athlete record already exists etc. For every scenario identified, a corresponding sequence diagram is created.
Software Engineering 97
Figure 3.22 Enhanced Sequence Diagram of Adding Athlete Record
J.E.D.I
Describing the Collaboration Diagram
The Collaboration Diagram is used to model a pattern of interaction among objects. It models the objects participating in the interaction by their links to each other and the
messages that they send to each other. It validates the class diagram by showing the need for each association. It models the recipients message effectively which defines an
interface to that object. Figure 3.23 shows the notation of the collaboration diagram.
The notation used in the Collaboration Diagram is similar with the Sequence Diagram except that we dont model the messages in chronological order. We only show the
message interaction.
Software Engineering 98
Figure 3.23 Collaboration Diagram
J.E.D.I
Developing the Collaboration Diagrams Collaboration diagrams can be derived from the sequence diagrams. Similar with
sequence diagrams, object-level is used in modeling. Therefore, for every sequence diagram, one collaboration diagram is created. In the following example, the successful
adding of athlete record scenario of the Add Athlete Use Case is used.
1. Draw the participating actors and objects. Figure 3.24 shows an example.
Again, the analysis objects :AthleteRecordUI, :AddAthlete and :Athlete are used with the :Club Staff.
Software Engineering 99
Figure 3.24 Actors and Objects
J.E.D.I
2. If objects exchange messages as shown in their sequence diagram, draw a line connecting them which signifies an association. The lines represent links. For an
example, Figure 3.25 depicts one. The :Club Staff exchanges messages with :AthleteRecordUI
. The :AthleteRecordUI exchanges messages with :AddAthlete. Finally, the :AddAthlete exchanges messages with :Athlete.
Software Engineering 100
Figure 3.25 Actors and Objects With Links
J.E.D.I
3. Draw the messages on the association lines. An example is shown in Figure 3.26. Messages are represented as arrow lines with the message written within them. As an
example, message number 1 is enterAthleteData message with its corresponding parameters. Complete message definition is written.
This is the collaboration diagram of a successful adding of athlete record scenario of the Add Athlete Record
Use Case. Similar with sequence diagrams, a collaboration diagram is created for every sequence diagram that was identified.
Software Engineering 101
Figure 3.26 Collaboration Diagram of Add Athlete Record
J.E.D.I
Step 4: For each resulting analysis classes, identify responsibilities.
A responsibility is something that an object provides to other objects or actors. It can be an action that the object can perform or a knowledge that the object maintains and
provides to other objects. It can be derived from messages obtained from the events or interaction diagrams.
Using the collaboration diagrams, incoming messages are the responsibility of the class. To get the responsibilities of the analysis classes of the Add Athlete Record Use Case,
we need to use its collaboration diagrams. Figure 3.27 shows the responsibilities of the classes for the Add Athlete Record Use Case using the collaboration diagrams. In this
example,
:AthleteRecordUIs responsibilities
are enterAthleteData,
enterGuardianData and submitAthleteRecord. :AddAthletes responsibility are
saveAthleteRecord . Finally, :Athletes responsibility is to addAthlete,
editAthlete, deleteAthlete and UpdateStatus.
To help identify the responsibility of the class, use the following guidelines. 1. Check that classes have consistent responsibility. If it seems that
responsibilities are disjoint, split the object into two or more classes. Update the sequence and collaboration diagrams to reflect the changes.
2. Check the classes for similar responsibilities. If it seems that classes have the same responsibilities, combine them. Update the sequence and collaboration
diagrams to reflect the changes.
Software Engineering 102
Figure 3.27 Responsibility Identification
J.E.D.I
3. Better distribution of responsibilities may be evident while working on another interaction diagram. In such a case, it is better and easier not to modify and
update previous diagrams. Take the time to set the diagrams right, but dont get hung up trying to optimize the class interactions.
4. There is no problem if a class has only one responsibility, per se, but it should raise question on why it is needed. It is necessary to justify its existence.
You should compile all responsibilities seen in all collaboration diagrams into a single class definition.
Step 5: For each resulting analysis classes, identify attributes.
An attribute is an information that an object owns or known about itself. It is used to store information. Identifying attributes specifies the information that an analysis class
is responsible for maintaining. They are specified using the following format:
attribute : data_type = default_value {constraints}
Table 9 gives the description of each component of the attribute specification. The attribute and data type are required.
Attribute Component Meaning
attribute It is the name of the attribute. When naming an
attribute make sure that it describes the value it holds.
data_type It specifies the type of the attribute. Preferably, use
the data types defined in the Java Programming Language. You can even used the user-defined data
types.
default_value It is the default value assigned to the attribute when
an object is instantiated.
constraints It represents additional constraints applied to the
allowable values of the attribute such as numeric ranges.
Table 10 Attribute Specifications
Software Engineering 103
J.E.D.I
Below are some examples of specifying attributes.
1. InvoiceNumber : Numeric Here, an attribute named InvoiceNumber contains a numeric value.
