Ternary association which is a relationship of three or more objects of

J.E.D.I Step 6: For each resulting analysis classes, identify associations. An association represents the structural relationships between objects of different classes. It connects instances of two or more classes together for some duration. It may be: 1. Unary Association which is a relationship of objects of the same class. 2. Binary association which is a relationship of two objects of different classes.

3. Ternary association which is a relationship of three or more objects of

different classes. Figure 3.29 shows examples of the type of associations. The first example shows a unary association where a manager manages zero or many employee and an employee is being managed by one manager. The second example shows a binary association where an athlete is assigned to zero or one squad while a squad has many athlets. Aggregation is a special form of association that models a whole-part relationship between an aggregate and its part. Some situations where an aggregation is appropriate are: • An object is physically composed of other objects. • An object is a logical collection of other objects. • An object physically contains other objects. Aggregation is modeled in Figure 3.30 which shows another way of modeling athlete and squad relationship. A squad is an aggregation of zero or many athletes. The end of the link that has a diamond shape symbol which represents “parts” or “components” of the aggregate or whole. Software Engineering 106 Figure 3.29 Types of Associations Figure 3.30 Aggregation J.E.D.I Multiplicity is the number of objects of the class that can be associated with one object of the other class. It is indicated by a text expression on the association line. It answers the following questions. • Is the association optional or mandatory? • What is the minimum and maximum number of instance that can be linked to one instance of an object? It is possible that there can be multiple association between the same class. However, they should represent relationship among distinct objects of the same class. Multiplicity specification are shown in Table 10. Multiplicity Description Unspecified. Use this if you dont know how many instances is associated with one object. Exactly One. Use this if you know that exactly one object is associated with the other object. Zero or Many. Use this if you know that zero or many objects are associated with the other object. This is also known as optional association. One or Many. Use this if you know that one or many objects are associated with the other object. This is also known as mandatory association Specified Range. Use this if the number of objects has a specified range. Multiple, Disjoint. Table 11 Multiplicity Specifications Software Engineering 107 1 0.. 0..1 2,4..6 2-4 J.E.D.I To help in the identification of the associations, the following guidelines can be used. 1. Start studying the links in the collaboration diagrams. They indicate that classes need to communicate. 2. Reflexive links do not need to be instances of unary association. An object can send a message to itself. Unary relationship is needed when two different object of the same class need to communicate. 3. Focus only on associations needed to realize the use case. Do not add 4. Give association names- either verb or roles. 5. Write a brief description of the association to indicate how the association is used, or what relationships the association represents. Software Engineering 108 J.E.D.I In our running example, the following associations identified is shown in Figure 3.31. An AthleteRecordUI boundary class interacts with only one AddAthlete control class. An AddAthlete control class interacts with only one Athlete entity class. An Athlete has only one Guardian and one AthleteStatus. An AthleteStatus can be assigned to zero or many Athletes. Software Engineering 109 Figure 3.31 Association Identification J.E.D.I Step 7: Unify analysis classes in a class diagram. Unifying analysis classes means ensuring that each analysis class represents a single well-defined concepts with non-overlapping responsibilities. It filters the analysis classes to ensure minimum number of new concepts have been created. To help in unifying the analysis classes in a single class diagram, the following guidelines can be used. 1. The name of the analysis class should accurately capture the role played by the class in the system. It should be unique, and no two classes should have the same names. 2. Merge classes that have a similar behavior. 3. Merge entity classes that have similar attributes, even if their defined behavior is different; aggregate the behaviors of the merged classes. 4. When one updates a class, you should update any supplemental documentation, where necessary. Sometimes, an update on the original requirements may be required. BUT, this should be controlled as the requirements are the contract with the usercustomer, and any changes must be verified and controlled. 5. Evaluate the result. Be sure to: • verify that the analysis classes meet the functional requirements made on the system • verify that the analysis classes and their relationships are consistent with the collaboration they support If you noticed the unified class diagram, attribute and responsibilities are refined to give a clear definition of the classes. Remember that the analysis classes rarely survive after the design phase. The important thing at this point is that data as represented by the attributes and the operations as represented by the responsibilities are represented and distributed to classes. They will be restructured and redefined during the design phase. Use the validation checklist discussed in the succeeding section to check the analysis model. Figure 3.32 shows the unified class diagram of the Club Membership Maintenance. Software Engineering 110 J.E.D.I Software Engineering 111 Figure 3.32 Club Membership Maintenance Class Diagram J.E.D.I

3.4.3 Analysis Model Validation Checklist