1. Requirements Analysis 15.1 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Specialised Associations: Roles, Qualifiers, Aggregation, Composition & Inheritance Department of Information Systems

2. Requirements Analysis 15.2 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Learning Objectives Understand significance of, and notation for: v Navigability v Roles and Qualifiers v Aggregation v Composition v Inheritance v Self-association

3. Requirements Analysis 15.3 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Association Navigability v Associations are normally read left to right, but not always possible to draw neatly v Navigability arrows show which way to read an association label v A module is not enrolled on a student! a:StudentINFO2005:Module 16..64 0..8 EnrolledOn

4. Requirements Analysis 15.4 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Association Navigability v In design, navigability has another meaning v This is not usually an issue in analysis

5. Requirements Analysis 15.5 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Class Roles v Roles help clarify v Only employees a:Vehiclean:Employee 1..*0..1 IsAssigned driver an:Employee 1..*0..1IsAssigned a:Vehicle

6. Requirements Analysis 15.6 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Class Roles v A common role v Every manager a:TeamMembera:Manager 1..*0..1 Supervises a:TeamMembera:Manager 1..*0..1 Supervises team leader

7. Requirements Analysis 15.7 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Class Roles v An object can play a:Manager a:TeamMember 1..*0..1 Supervises team leader driver 1..* 0..1 IsAssigned a:Vehicle

8. Requirements Analysis 15.8 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Association Qualifiers v Superficially similar to roles, qualifiers are actually quite different v A qualifier identifies the subset of objects that link to another object: “[It] distinguishes the set of objects at the far end of an association based on the qualifier value” Larman, 1998

9. Requirements Analysis 15.9 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Association Qualifiers Product Specification Catalogue 1..*1Contains productCode description Product Specification Catalogue 11 Contains productCode v Note the change of multiplicity v From unspecified many down to exactly one v A catalogue contains product specs v How do they relate?

10. Requirements Analysis 15.10 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Association Qualifiers v Qualifiers are generally more useful in design than in analysis v But they can also sometimes help to clarify our understanding of the domain

11. Requirements Analysis 15.11 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Aggregation v A special form of association v Models Whole-Part relationships v Aggregate (whole) may delegate some responsibilities to its parts v Parts are encapsulated v Aggregate (usually) presents the sole interface to other bits of the model

12. Requirements Analysis 15.12 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Aggregation v The Rational people say that aggregation expresses: –Physical containment, e.g. car + passengers... –Physical composition, e.g. car + engine, body, wheels... –Conceptual collection, e.g family + mother, father, daughter… Jacobson et al, 1999

13. Requirements Analysis 15.13 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Aggregation v Physical containment: Airspace Stacking Queue 1..n 1 * 1 Passenger Flight 0..n 1

14. Requirements Analysis 15.14 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Aggregation Car Whole Part Aggregate Engine 0..1 1 Wheels 0..5 1 Body 0..1 1 Components v Physical composition:

15. Requirements Analysis 15.15 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Aggregation v Conceptual collection: Analysis Package * Use Case Realisation Analysis Class * * v Note the new notation for package v Analysis packages often become distinct subsystems in the software Adapted from Jacobson et al, 1999

16. Requirements Analysis 15.16 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Composition v A strong form of aggregation:

17. Requirements Analysis 15.17 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation:Composition Car Engine 0..1 1 Wheels 0..5 1 Body 0..1 1 v Actually, the car example is better modelled as composition:

18. Requirements Analysis 15.18 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Using Aggregation & Composition v Usefulness in analysis?

19. Requirements Analysis 15.19 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Generalisation v Another term for inheritance relationship v Applies only where: v Familiar basis of most classification v Formally equivalent to “A is a kind of B”

20. Requirements Analysis 15.20 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved “Superclass is more general” v A superclass abstracts out some common features of its subclasses v May be common attributes, operations or associations AcademicStaff specialism assignModules pay calcHolidays name address phone nextOfKin AdminStaff grade calcHolidays pay name address phone nextOfKin

21. Requirements Analysis 15.21 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Generalisation StaffMember name address phone nextOfKin calcHolidays pay AdminStaff grade AcademicStaff specialism assignModules Generalisation Base Class “Derived” Classes

22. Requirements Analysis 15.22 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved “Subclass is fully consistent...” v Every subclass inherits everything in its superclass definition v Redefined operations appear to break this rule, but actually they don’t v Suppose academic staff salaries are calculated differently from admin staff  We may still define a generic pay operation at superclass level

23. Requirements Analysis 15.23 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Generalisation StaffMember.pay is an abstract, generic definition of the operation AcademicStaff specialism assignModules pay AdminStaff grade calcHolidays pay StaffMember name address phone nextOfKin calcHolidays pay > Each subclass redefines this by adding the detailed logic for its own unique method of payment Note > stereotype on StaffMember

24. Requirements Analysis 15.24 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved “Subclass adds features...” v Every subclass is more specialised than all its superclasses: AcademicStaff specialism assignModules pay Person name address phone Staff pay calcHolidays dateAppointed staffNumber extension Student enrolOnModule passLevel nextOfKin currentLevel dateEnrolled PartTimeStudent studyDay

25. Requirements Analysis 15.25 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved UML Notation: Generalisation University Physical Resource * SupportAcademic Full-timePart-time TechAdmin * Person StudentStaff

26. Requirements Analysis 15.26 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Using Generalisation v In analysis, inheritance offers a way to: v Even more useful during design v Mechanism for reuse of base class specifications

27. Requirements Analysis 15.27 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Self-association v An object can have links with other objects of the same class v E.g. team members take turns at leading a team TeamMember leader led 1 * LeadsTeam v Note the use of roles to clarify multiplicities

28. Requirements Analysis 15.28 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Self-association v Often combined with aggregation structures v E.g. recursive “parts explosion” for complex assemblies: Assembly 1 * Subassembly * 1 * 1 Part v Some assemblies are part of other assemblies

29. Requirements Analysis 15.29 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Summary Explained significance of, and notation for: v Association Navigability v Class Roles and Association Qualifiers v Aggregation v Composition v Inheritance v Self-association

30. Requirements Analysis 15.30 Specialised Associations - 2005b515.ppt © Copyright De Montfort University 2000 All Rights Reserved Further Reading Bennett, S. et al. “Object-Oriented Systems Analysis & Design using UML” McGraw-Hill 1999, esp Chs 7 and 8 Britton, C. and Doake, J. “Object-Oriented Systems Development: a Gentle Introduction” McGraw-Hill 2000 Jacobson, I. et al. “The Unified Software Development Process” Addison Wesley 1999 Larman, C. “Applying UML and Patterns” Prentice Hall 1998 Rational Unified Process, 2000