300 likes | 448 Vues
INFO2005 Requirements Analysis Specialised Associations: Roles, Qualifiers, Aggregation, Composition & Inheritance. Department of Information Systems. Learning Objectives. Understand significance of, and notation for: Navigability Roles and Qualifiers Aggregation Composition Inheritance
E N D
INFO2005Requirements Analysis Specialised Associations:Roles, Qualifiers,Aggregation, Composition & Inheritance Department of Information Systems
Learning Objectives Understand significance of, and notation for: • Navigability • Roles and Qualifiers • Aggregation • Composition • Inheritance • Self-association
0..8 16..64 EnrolledOn INFO2005:Module a:Student Association Navigability • Associations are normally read left to right, but not always possible to draw neatly • Navigability arrows show which way to read an association label • A module is not enrolled on a student!
Association Navigability • In design, navigability has another meaning • This is not usually an issue in analysis
0..1 1..* IsAssigned an:Employee a:Vehicle 0..1 IsAssigned 1..* a:Vehicle an:Employee driver Class Roles • Roles help clarify • Only employees
0..1 1..* Supervises a:Manager a:TeamMember 0..1 1..* Supervises a:Manager a:TeamMember team leader Class Roles • A common role • Every manager
0..1 1..* Supervises a:Manager a:TeamMember team leader 0..1 driver IsAssigned 1..* a:Vehicle Class Roles • An object can play
Association Qualifiers • Superficially similar to roles, qualifiers are actually quite different • 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
1 Contains 1..* Catalogue Product Specification productCode description 1 1 Contains Product Specification productCode Catalogue Association Qualifiers • A catalogue contains product specs • Note the change of multiplicity • From unspecified many down to exactly one • How do they relate?
Association Qualifiers • Qualifiers are generally more useful in design than in analysis • But they can also sometimes help to clarify our understanding of the domain
Aggregation • A special form of association • Models Whole-Part relationships • Aggregate (whole) may delegate some responsibilities to its parts • Parts are encapsulated • Aggregate (usually) presents the sole interface to other bits of the model
Aggregation • 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
1 1 Stacking Queue Airspace Flight 1..n 0..n 1 * Passenger UML Notation: Aggregation • Physical containment:
Aggregate Car 1 1 1 0..1 0..5 0..1 Wheels Engine Body Components UML Notation: Aggregation • Physical composition: Whole Part
Analysis Package * * * Analysis Class UseCaseRealisation UML Notation: Aggregation • Conceptual collection: • Note the new notation for package • Analysis packages often become distinct subsystems in the software Adapted from Jacobson et al, 1999
Composition • A strong form of aggregation:
Car 1 1 1 0..1 0..5 0..1 Wheels Engine Body UML Notation:Composition • Actually, the car example is better modelled as composition:
Using Aggregation & Composition • Usefulness in analysis?
Generalisation • Another term for inheritance relationship • Applies only where: • Familiar basis of most classification • Formally equivalent to “A is a kind of B”
AcademicStaff AdminStaff name name address address phone phone nextOfKin nextOfKin specialism grade calcHolidays calcHolidays pay pay assignModules “Superclass is more general” • A superclass abstracts out some common features of its subclasses • May be common attributes, operations or associations
StaffMember name address phone nextOfKin calcHolidays pay Generalisation AcademicStaff AdminStaff specialism grade assignModules UML Notation: Generalisation Base Class “Derived” Classes
Every subclass inherits everything in its superclass definition Redefined operations appear to break this rule, but actually they don’t Suppose academic staff salaries are calculated differently from admin staff We may still define a generic pay operation at superclass level “Subclass is fully consistent...”
<<abstract>> StaffMember name address phone nextOfKin calcHolidays pay AcademicStaff AdminStaff specialism grade assignModules calcHolidays pay pay UML Notation: Generalisation StaffMember.pay is an abstract, generic definition of the operation Each subclass redefines this by adding the detailed logic for its own unique method of payment Note <<abstract>> stereotype on StaffMember
Every subclass is more specialised than all its superclasses: Staff AcademicStaff dateAppointed specialism staffNumber extension Person calcHolidays pay name pay assignModules address phone Student PartTimeStudent nextOfKin studyDay dateEnrolled currentLevel enrolOnModule passLevel “Subclass adds features...”
* * University Person Staff Academic Full-time Part-time Support Admin Student Tech Physical Resource UML Notation: Generalisation
In analysis, inheritance offers a way to: Even more useful during design Mechanism for reuse of base class specifications Using Generalisation
An object can have links with other objects of the same class E.g. team members take turns at leading a team TeamMember LeadsTeam leader 1 * led Self-association • Note the use of roles to clarify multiplicities
Often combined with aggregation structures E.g. recursive “parts explosion” for complex assemblies: Subassembly Assembly Part 1 1 * * 1 * Self-association • Some assemblies are part of other assemblies
Explained significance of, and notation for: Association Navigability Class Roles and Association Qualifiers Aggregation Composition Inheritance Self-association Summary
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 Further Reading