requirements analysis 15.1 specialised associations - 2005b515.ppt © copyright de montfort...

Requirements Analysis 15.1Specialised Associations - 2005b515.ppt

© Copyright De Montfort University 2000All Rights Reserved

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



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!

a:StudentINFO2005:Module16..640..8 EnrolledOn



Association Navigability

In design, navigability has another meaning

This is not usually an issue in analysis



Class Roles

Roles help clarify

Only employees

a:Vehiclean:Employee1..*0..1 IsAssigned

driveran:Employee

1..*0..1 IsAssigneda:Vehicle



Class Roles

A common role

Every manager

a:TeamMembera:Manager1..*0..1 Supervises

a:TeamMembera:Manager1..*0..1 Supervises

team leader



Class Roles

An object can play

a:Manager a:TeamMember1..*0..1 Supervises

team leader

driver

1..*

0..1

IsAssigned

a:Vehicle



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




ProductSpecification

Catalogue 1..*1 Contains

productCodedescription

ProductSpecification

Catalogue11 Contains

productCode

Note the change of multiplicity From unspecified many down to exactly one

A catalogue contains product specs

How do they relate?




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



UML Notation: Aggregation

Physical containment:

Airspace Stacking Queue1..n

1

*

1

Passenger

Flight0..n

1




CarWhole

Part

Aggregate

Engine

0..1

1

Wheels

0..5

1

Body

0..1

1

Components

Physical composition:




Conceptual collection:

Analysis Package

*

Use Case Realisatio

n

Analysis Class

**

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:



UML Notation:Composition

Car

Engine

0..1

1

Wheels

0..5

1

Body

0..1

1

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”



“Superclass is more general” A superclass abstracts out some

common features of its subclasses May be common attributes,

operations or associationsAcademicStaff

specialism

assignModulespaycalcHolidays

nameaddressphonenextOfKin

AdminStaff

grade

calcHolidayspay

nameaddressphonenextOfKin



UML Notation: Generalisation

StaffMembernameaddressphonenextOfKincalcHolidayspay

AdminStaff

grade

AcademicStaff

specialism

assignModules

Generalisation

Base Class

“Derived”Classes



“Subclass is fully consistent...” 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




StaffMember.pay is an abstract, generic definition of the operation

AcademicStaff

specialism

assignModulespay

AdminStaff

grade

calcHolidayspay

StaffMembernameaddressphonenextOfKincalcHolidayspay

<<abstract>>

Each subclass redefines this by adding the detailed logic for its own unique method of payment

Note <<abstract>> stereotype on StaffMember



“Subclass adds features...”

Every subclass is more specialised than all its superclasses:

AcademicStaff

specialism

assignModulespay

Person

nameaddressphone

Staff

paycalcHolidays

dateAppointedstaffNumberextension

Student

enrolOnModulepassLevel

nextOfKin

currentLeveldateEnrolled

PartTimeStudent

studyDay




University

Physical Resource

*

SupportAcademic Full-timePart-time

TechAdmin

*Person

StudentStaff



Using Generalisation

In analysis, inheritance offers a way to:

Even more useful during design Mechanism for reuse of base class

specifications



Self-association

An object can have links with other objects of the same class

E.g. team members take turns at leading a team

TeamMember

leader

led

1

*

LeadsTeam

Note the use of roles to clarify multiplicities



Self-association Often combined with aggregation structures E.g. recursive “parts explosion” for complex

assemblies:

Assembly

1

*Subassembly

*1

*

1

Part

Some assemblies are part of other assemblies



Summary

Explained significance of, and notation for:

Association Navigability Class Roles and Association Qualifiers Aggregation Composition Inheritance Self-association



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

requirements analysis 15.1 specialised associations - 2005b515.ppt © copyright de montfort...

Documents

analysis v

productcode v

different v

meaning v

analysis slide

navigability v roles

specialised associations

association label v