Object Oriented Modelling

1
Object Oriented Modelling
University of Ulster at Jordanstown
2
The UML Method

• First published on the Internet in 1996
• http//www.rational.com
• A second generation OO method derived from three
  1st generation methods
• OMT - Rumbaugh 1991
• Booch - Booch 1991, 1994
• Objectory - Jacobson 1992
• Several books on UML
• Rumbaugh 1998 and Booch 1998
• Eriksson Penker 1998

3
The General OO Methodological Process

• Requirements Specification and Use Case Modelling
• UX Modelling
• Analysis
• Design

4
Analysis versus Design
There is no significant distinction between the
techniques used during Analysis and those used
during Design. The techniques are equally valid
during both stages. The principle difference is
the level of objects you model with. The term
Object Modelling is sometimes used instead of
Object Analysis and Object Design.
5
Analysis versus Design

• Analysis level objects
• Customers, accounts, suppliers, accidents,
  invoices
• Protocols, motors, sensors, engines, traffic
• Design level objects
• User interface (dialogue and presentation
  objects)
• Objects to manage relationships, concurrency,
• referential integrity, transactions, etc...

6
UML Views

• Views provide high level representations of a
  domain or system. There are several
• Use-Case View User perception of functionality
  in domain or system.
• Logical View Internal representation showing
  both static structure and time-dependent dynamic
  behaviour.
• Component View Showing how a complete system is
  composed of discrete units.
• Concurrency View Division of system into
  separate execution threads - shows communication.
• Deployment View Represents physical deployment
  of the various parts (components) of the overall
  system.

7
UML Views and Diagrams

• Each UML View is expressed in terms of a number
  of diagrams. UML provides many diagram types.
  Usually it is not necessary to employ all diagram
  types - some will be more useful than others.
• These diagrams enable the two basic dimensions of
  a domain or system to be modelled
• Static, structural models
• Dynamic, behavioural models

8
The Class Diagram
9
Classes and Objects
Objectname Classname
Classname
OR
OR
Objectname Classname
Class Name
Data Attributes
Data Attributes
Methods/ functions/ behaviour
Methods/ functions/ behaviour
10
Identifying Classes
11
Identifying Classes
Natural language - Origins from Abbott 1983
CRC Cards - Beck 1989 - Wirfs-Brock 1990
12
Natural Language

• Nouns may indicate candidate classes
• Some nouns are actually sub-assemblies or
  aggregates of classes.
• Some nouns suggest merely attributes of a class
• When sufficient significance can be assigned to
  an attribute it may be promoted to a full class.
• Verb phrases suggest class associations or
  operations
• Often operations are tied to relationships
• Adjectives suggest attributes of a class
• Proper nouns suggest objects of a class type
• Try not to have too many classes for which there
  is only ever one instance created.

Original concept from Abbott 1983
13
Critique of Natural LanguageAnalysis

• Needs a full and accurate statement of the
  requirements
• Often the lack of clearly defined requirements is
  the reason why an OO approach may be being used.
• Nouns and Verbs tend only to help identify
  tangible things.
• Much of design requires thinking about less
  tangible concepts - abstractions
• Therefore natural language may contribute little
  to the design process.
• Nevertheless, useful starting point for some
  analysis work.

see Goldberg and Rubin 1995
14
Natural Language Example
A manager is responsible for a department and
must review the staff in that department each
year. The manager is also responsible for
ordering new equipment (such as PCs) and
furniture (such as desks and chairs) as
required. From time to time John (one of the
managers) must also recruit additional staff.
This involves placing advertisements and keeping
track of all applicants up to the closing date. A
short-list of suitable candidates for interview
is then composed .
15
Natural Language Example

• What classes are involved?
• What class relationships are involved?
• What objects are involved?

16
CRC Cards
Class, Responsibility and Collaboration
Department Employee Applicant
Departmental reviews Staff salary
reviews Ordering Equipment Staff recruitment
Beck Cunningham 1989
17
CRC Cards

• Write Class name on a 4 x 6 index card
• Write Responsibilities on card
• Responsibilities identify the problems which the
  class must solve.
• Group responsibilities into contracts.
• Identify Collaborator classes on the card
• Collaborator classes are classes which send
  messages to, or receive messages from, the class
  in question.
• DIscard classes without collaborations.

Beck Cunningham 1989
18
Class Description

• End up with a class description, either in
  textual prose or some more structured form. For
  example using a company Manager
• Manager - A company employee and departmental
  controller. A manager is responsible for one or
  more employees. A manager can Review staff
  salaries, order equipment and recruit staff.
  These activities may all be part of periodic
  departmental reviews.

19
Structured Class Description
Class name MANAGER Description Details of a
company MANAGER - a person Superclass
PERSON Name Grade Description Details of
salary grading Type Integer (range
1-5) Cardinality One Name Manages Description
Details of employees managed Type
Employee Cardinality Many
20
Structured Class Description

• Public methods
• Name Review Department
• Parameters New Budget
• Description Used to carry out periodic reviews.
• Private methods
• Name Recruit Staff
• Parameters Numer of staff, type of staff
• Description Initiated by a Manager as a
  consequence of various factors and as a result of
  a request to Review Department.

21
Object Relationships

• Most OOAD methods (including UML) model
• 3 basic kinds of relationship
• Association
• Aggregation (part_of)
• Inheritance (is_a_kind_of)

22
Object and Class Associations

• Links and Associations
• Link - A physical or conceptual connection
  between two objects (instances)
• Association - A group of links with a common
  structure. Associations occur between classes of
  objects.
• Links represent object interactions (dynamic
  considerations)
• while associations depict static, structural
  issues.

23
Links and Associations
An Association
takes
Class diagram
Lecturer
Course
takes
Object diagram
George Lecturer
M.Sc Course
lecture
examine
A Link
24
Participation or Cardinality

• While participation is shown on class diagrams
• it relates to the number of instances of one
• class that are associated with an instance of the
• other class.

association name
Class 2
Class 1
role
role
1
Exactly one
Class
0..
Many (zero or more)
Class
0..1
Class
Optional (zero or one)
1..
Class
One or more
2
Numerically specified
Class
25
Example 1
Takes
0..
1..
Lecturer
Course
Is taken by
B.Sc Course
lecture
Joe Bloggs Lecturer
M.Sc Course
examine
26
Association Constraints

• You can document any constraints on the
  association. For example, a person may only drive
  a car if they have a valid licence

drives
0..
0..
Car
Person
person.licence_status valid)
27
Handling Link Attributes via an Association Class

• A class may be attached to an association rather
  than directly to another class. Such a class is
  called an Association Class. It can have data
  attributes and behaviour just like any other
  class
• Used to hold information on each occurrence of a
  relationship

Supplies
Supplier
Part
Contract
Date
28
Instances of the Association Class
BQ
21/12/92
aSaw
14/2/93
27/4/91
Texas
12/5/93
aHammer
5/9/93
Budget
29
Associations

• There can be more than one association between
  the same two classes
• Person hires car
• Person owns car
• Person drives car
• Suggests 3 distinct relationships between a
  Person and a Car
• May have different cardinalities
• Person hires many Cars
• A Car may be hired by many Persons (Over Time)

30
Example 2
owns
1
0..
Person
Car
0..
0..
hires
31
Time Dimension

• Time presents an interesting dimension when
  applied to associations.
• It often transforms a oneone into a onemany or
  a manymany.
• For example, a Car can only be hired by one
  person at a time (Rule). But it may be hired by
  many people over a period of time.
• The Rules must be identified by the analyst, so
  the designer can create the appropriate
  association participation.

32
Time Dimension

• If an Information System is required to track
  only details of who currently has a vehicle on
  hire, then the Car can be modelled in a OneOne
  association with a Person.
• However, if the system must provide a historical
  log of all customers who hired a particular Car
  then a ManyMany association will be required.

33
Time Dimension

• A Person may Drive a Car for much shorter periods
  of time. Is a record of all driving periods
  required?
• Perhaps for a haulage firm with a legal
  requirement to maintain a driving log for each
  Driver.
• In another situation it may only be necessary to
  record information about who is currently driving
  a particular Car.

34
Aggregation

• Aggregation is the part-whole relationship.
• It relates classes, representing parts (or
• components) to the whole (or assembly)
• class.

35
Aggregation

• A tightly coupled form of association with some
• extra semantics, namely transitivity (if A is a
• part of B and B is a part of C then A is a part
  of
• C).
• Properties of the assembly may propagate to
• the components. For example, the speed and
• location of a door is obtained from a fuselage
• which in turn obtains them from a Plane.

Rumbaugh 1991
36
UML Aggregation

• In UML there are three types of aggregation
• Normal Aggregation
• Shared Aggregation
• Composition aggregation

37
Composition Aggregation

• The whole owns the instances of the parts.
  Those instances cannot belong to any other
  instance of the whole.
• Composition Aggregation forms a tree structure.
• The lifetime of the whole dictates the lifetime
  of the constituent parts.

38
Composition Aggregation Example
Aircraft
2
1
Fuselage
Engine
Wing
2
Landing Gear
Door
39
Alternative Notation
Aircraft
Engine
1
Wing
2
Fuselage
2
Door
Landing Gear
40
Aggregation

• Aggregation is most useful when there are common
  properties of components that can be attached to
  the assembly as a whole
• Or where operations can propagate from container
  to contained objects
• Parts explosions are the most compelling examples
  of aggregation
• If in doubt, use ordinary association!

41
Aggregation - discussion
University
Class diagram

Faculty

1
1..
School
Lecturer
works for
1..
takes
1..
Course
42
Aggregation - discussion
UUJ
Object diagram
L
Business Mmgt
L
S
L
S
Informatics
MBA
S
B.Eng
S
S
L
L
Sciences
L
S
L
S
L
S
M.Sc IT
S
M.Sc
L
L
B.Sc
L
43
Shared Aggregation in UML

• With Shared Aggregation the parts can be
  associated with many wholes - for example several
  instances of a collection class may act as
  collectors for a given class. To use the example
  of staff recruitment, a candidate may be
  associated with an applicants whole and at the
  same time be part of a short-listed whole and
  eventually an offer-made whole. Each of these
  wholes is acting as a collection class for
  applicants.

List

Open diamond symbol for both sharded and
normal aggregation

Shared aggregation if mutiplicity gt 1.
Applicant
44
Shared Aggregation in UML

• Lifetime of parts is not constrained by the
  lifetime of the container
• Parts can exist independently from the whole.
• Much closer to the idea of a 1-many association.
• Shared aggregates form a network of parts rather
  than a tree structure.

45
Normal Aggregation - Discussion
University
Class diagram

Faculty

1
1..
School
Lecturer
works for
1..
takes
1..
Course
46
And the corresponding object version...
S
S
L
L
UUJ
L
Business Mmgt
S
MBA
S
Informatics
S
B.Sc (Computing)
Sciences
S
L
L
B.Sc
L
S
S
L
S
L
L
M.Sc IT
L
M.Sc
L
47
Aggregation and Collections

• Collections are
• Used to manage groups of similar (but not
  necessarily the same - eg polymorphic) objects
• First point of contact for simple requests where
  the receiving object has to be located
• e.g. What class is the lecturer Joe Wilson
  taking right now?
• Handle requests involving multiple objects
• eg. What is the total salary bill for the Faculty
  of Informatics?

48
Collection Devices
School
Navigational Access
Computing Maths School
M.Sc IT Course
What Course?
1
collection
1..
Lecturer
Salary
Joe Wilson Lecturer
Associative Access
1..
takes
1..
Course
Name
School is acting as a collection device for
Lecturers
49
Access Mechanisms

• How do you access information from an Object
  Model?
• Two main ways
• Associative Access
• Finding an object by using the value of its
  attributes e.g. find Joe Wilson
• Navigational Access
• Following reference from one object to related
  objects e.g. what course does Joe Wilson teach on
  Monday morning?
• Common to employ both procedures
• Associative access to identify top-most object
• Then Navigational access as required

50
Aggregation versus Collection

• Completely different semantics
• True aggregation implies object levelling
• Abstraction layering, information hiding
• Collections are an organisational convenience
• heavily used in Object DBMSs
• provide associative access within an object model.

51
Inheritance

• Sometimes called the is_a relationship
• Provides a way of sharing attributes and methods
  between subclasses (or child classes) and their
  superclasses (or parents)
• Subclasses can share similarities with common
  superclasses while preserving their differences
• Default types of attributes and logic of methods
  can be overridden in the subclasses

52
Inheritance Example

• Build an inheritance hierarchy using the
• following items identified from OO Analysis.

• Student
• Qualifications
• Salary
• Lecturer
• Name
• Secretary
• Lecture

53
Inheritance sample solution
54
Multiple Inheritance example
Sales Person
Manager
Sales Manager
Director
55
Class hierarchies
Generalisation
Specialisation
56
Class roles and Inheritance

• In a previous slide we looked at class roles

takes
1..
Lecturer
Course
Admin
Here, the Person plays the role of a Course
Tutor. Often such roles are modelled through
inheritance
Lecturer
Course Tutor
57
Using Class Hierarchies
Generic class hierarchy
Using via sub-classing
copy
Using via delegation
Generic class
messages
Application specific class
Instantiation of a generic class
Instantiation of an application specific class
58
Dont confuse Inheritance and Aggregation!
Wing
Fuselage
Engine
Plane

• Not intuitive, therefore confusing to someone
  else. (A Plane is not a kind of Wing...)

59
Associations and Inheritance
1..
1
1
0..1
Crew Member
Plane
Licence
is_operated_by
Owns
0..1
1
Commercial
Private
Pilot
Licence
60
Aggregation versus Inheritance

• Aggregation is not the same thing as inheritance
• Aggregation relates to Instances
• Inheritance relates to Classes

61
Aggregation and Inheritance
1
Fuselage
1
Engine
Plane
2
Wing
Commercial
Private
Military
62
Candidate Classes for a Library

• It is important to be aware of the relative
• stability of the various classes used in your
• object model. Not all classes will exhibit the
• same potential stability with respect to future
• required changes.
• Component classes are likely to be more stable
  than container classes
• Subclasses representing roles will be less stable
  than the more fundamental superclass

63
Fundamental Classes

• Scroll Bars
• Menus
• Cursors
• Lists

Suitable material for inclusion in generic,
re-usable class libraries
64
Composite Classes

• User interface window

Window
. . . .
Menu
Icon
ScrollBar
Cursor
65
Managing the bigger picture

• UML employs the notion of a Package as a
  mechanism for grouping related model elements.
  For example, groups of collaborating classes
  could be called a package. An overall system can
  then be composed from a number of packages.

A
UML Notation for a Package
66
UML Component Diagram

• An overall system may consist of a number of
  physical components for example, where various
  classes are implemented in different code
  components. The notation is shown below

Room
User
GUI
Booking
67
UML Deployment Diagram

• Different code components can be distributed
  amongst a number of processors or nodes in a
  network. The deployment diagram enables the
  designer to illustrate this distributed nature

UserUserBase
ltltTCP/IPgtgt
GUI ClientA
Booking BuildingDiary
ltltTCP/IPgtgt
Deployment diagram for a Room Booking System
68
Developing Static Models

• Identify the main Use-cases and write down
  descriptions of these
• Identify the main elements of information which
  must be stored.
• Identify the main actors with which the system
  must interact.
• Identify objects and classes
• Identify associations between classes
• Creating object model segments for each Use-case.
• Identify attributes for classes
• Merge the object model segments to create an
  overall object model for the system
• Organise and simplify classes using inheritance
• Test the object model and its relationships by
  performing walk-throughs using, for example, UML
  Sequence diagrams (Dynamic Modelling)
• Iterate and refine the models

69
Class Model Summary

• The Class Model is used to identify classes and
• their inter-relationships. It provides a static,
• structural view of a system without any
• consideration of time sequencing or object
• interactions.

70
References

• Rumbaugh 1991
• Object oriented modeling and design
• by J.Rumbaugh, M.Blaha, W.Premerlani, F.Eddy
  W.Lorensen
• Prentice-Hall, 1991
• ISBN 0-13-630054-5
• Beck 1989
• A Laboratory for teaching object oriented
  thinking
• by K.Beck W.Cunningham
• in OOPSLA 89 COnference Proceedings, ACM Press,
  pp1-10

71
References continued

• Abbott 1983
• Program Design by Informal English Descriptions
• By R.Abbott
• Communications of the ACM Vol. 26(11), November
  1983
• pp.882-94
• Booch 1994
• Object oriented analysis and design - with
  applications
• By G.Booch
• Benjamin-Cummings, 1994, ISBN 0-8053-5340-2
• Jacobson 1992
• Object oriented software engineering - A Use Case
  Driven Approach
• By I.Jacobson, M.Christerson, P.Jonsson
  G.Overgaard
• Addison-Wesley publishers, 1992, ISBN
  0-201-54435-0

72
More References

• Goldberg and Rubin 1995
• Succeeding with Objects Decision Frameworks for
  Project Management.
• By A. Goldberg and K.S.Rubin
• Addison Wesley, 1995
• pp. 341.
• Booch 1998
• Unified Modeling Language User Guide
• By Booch, Rumnaugh Jacobson
• Addison-Wesley-Longman, 1998
• ISBN 0-201-57168-4
• Rumbaugh 1998
• Unified Modeling Language Reference Manual
• By Rumbaugh, Jacobson Booch
• Addison-Wesley-Longman, 1998
• ISBN 0-201-30998-X

73
Yet More References

• Eriksson Penker 1998
• UML Toolkit
• By Hans-Erik Eriksson and Magnus Penker
• Wiley, 1998
• ISBN 0-471-19161-2