COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Introduction to Requirements Analysis Lecture 6 Specialised Associations :

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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 EnrolledOn

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Association Navigability v In design, navigability has another meaning –We need to know if one object can send messages to another object –Navigability shows which way messages can travel along an association v This is not usually an issue in analysis –More strongly concerned with semantics - i.e. the meaning of business requirements

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Class Roles v Roles help clarify when a class can participate in an association v Only employees in the role of driver are associated with a vehicle a:Vehiclean:Employee 1..*0..1 IsAssigned driver an:Employee 1..*0..1IsAssigned a:Vehicle

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Class Roles v A common role example is the supervisor-supervisee relationship v Every manager doesn’t supervise every team member - only those in their own team a:TeamMembera:Manager 1..*0..1 Supervises a:TeamMembera:Manager 1..*0..1 Supervises team leader

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Class Roles v An object can play multiple roles v It can participate in different associations, either at different times or simultaneously a:Manager a:TeamMember 1..*0..1 Supervises team leader driver 1..* 0..1 IsAssigned a:Vehicle

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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?

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Association Qualifiers v Qualifiers are generally more useful in design than in analysis –E.g to design the indexing that supports efficient message pathways v But they can also sometimes help to clarify our understanding of the domain

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved UML Notation: Aggregation v Physical containment: Airspace Stacking Queue 1..n 1 * 1 Passenger Flight 0..n 1 v Note this example is dynamic, changing as one flight lands and another arrives

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved UML Notation: Aggregation Car Whole Part Aggregate Engine Wheels Body Components v Physical composition:

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Composition v A strong form of aggregation: –The whole has lifetime ownership of its parts –If a whole is destroyed, so are all its parts –A part may belong only to one whole at a time –A part may be removed or added to a whole –Only when explicitly removed from one whole can a part be added to another whole

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved UML Notation:Composition Cat Legs Head 1 1 Tail v A cat example is better modelled as composition:

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Using Aggregation & Composition v There is debate about the usefulness of these modelling constructs in analysis v They can help in handling complexity v They can express important structure in the problem domain v They contribute to the design of robust, reusable components v But Larman says “when in doubt, don’t”

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Generalisation v Another term for inheritance relationship v Applies only where: – Superclass is more general than subclasses – Subclass is fully consistent with superclass – Subclass adds additional (specialised) features v Familiar basis of most classification v Formally equivalent to “A is a kind of B”

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved UML Notation: Generalisation StaffMember name address phone nextOfKin calcHolidays pay AdminStaff grade AcademicStaff specialism assignModules Generalisation Base Class “Derived” Classes

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved UML Notation: Generalisation University Physical Resource * SupportAcademic Full-timePart-time TechAdmin * Person StudentStaff

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Using Generalisation v In analysis, inheritance offers a way to: –Express the semantics of logical classifications –Organise complexity v Like aggregation, it is even more useful during design v Here it provides a mechanism for reuse of base class specifications

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 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

COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved Further Reading Maciaszek, Requuirements Analysis & Systems Design Chapters 2 & 5 Bennett, S. et al. “Object-Oriented Systems Analysis & Design using UML” McGraw-Hill 1999, esp Chs 6 and 7 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