2. 3.2 Classes and Objects
Classes
Associations
(Static Modelling)
3. Classes and Objects
• 1 Classes & Objects
• 2 The Class Diagram
• 3 Associations
• 4 Aggregation & Composition
• 5 Generalisation
4. Classes and Objects
• Classes, Objects and their relationships are
the primary way to model.
• A class is like a type and therefore an
object is like a variable.
5. An Object has ...
• Attributes (data).
• Behaviour (operations).
• State (memory)
• Identity
• Responsibilities
6. An example Object ...
• A sensor:
– Attributes (data): Value, Rate of change
– Behaviour (operations): acquire, report ...
– State (memory) Last value, Last Rate
– Identity: Robot arm joint sensor
– Responsibilities: Gives co-ordinates for arm
7. The Class: Sensor
• All sensors share certain characteristics
hence we have a class of sensors.
• But each individual example is an object.
• (An instance of the class)
8. Attributes
• Describe the state and characteristics of the
object.
• Must be typed, primitives like integer, real,
Boolean, point, area, enumeration. May be
language specific.
• Visibility may be public (+), private (-) or
protected (#).
9. Attributes (Contd.)
• Class variables have scope across every
instance of class, change one changes all.
• Property strings may be used to define
allowable properties of an attribute. Used for
enumeration types.
• Syntax
– visibility name : type-expression = initial-value
{property-string}
• Only name and type are mandatory.
10. Example Class
Sensor
+ Linear_Value :Real
+ Rate_Of_Change : Real = 0.0
+ Sensor_Name : String
+ Sensor_Location: String
- Controller: String = “Unspecified”
- number_of_sensors: Integer
+ status: Status = ON{ON, OFF}
Name, bold
Public, typed
Default value
Class variable
Private, typed,
default value
Property
11. Operations
• Operations manipulate attributes and
perform other tasks.
• Scope is the Class.
• Operation signature is composed of name,
parameters and return type.
– name(parameter-list) return-type-expression
• Scope and visibility rules apply.
12. Syntactic Constructs
• Formal syntax is as follows
– visibility name(parameter-list) return-
type-expression {property-string}
• parameter-list specified as …
– name: type-expression=default-value
• All operations must have unique signature.
• Default values on parameters are Ok.
13. Figure
-size: Size
-pos: Position
+figCounter: Integer
+draw()
+resize(percentX: Integer=25, percentY=30)
+returnPos(): Position
incCounter(): Integer
MyFigure.resize(10,10)
MyFigure.resize(27)
MyFigure.resize()
percentX=10, percentY=10
percentX=27, percentY=30
percentX=25, percentY=30
Signatures ?
Class scope ?
Defaults ?
On the Class Diagram
15. Class & Object Representation
Rent
Member Video
Sunset Boulevard: Video
Night for day: Video
John Doe: Member
0..1 *
16. Navigable Associations
• Used to indicate responsibility, later may
be translated into pointer mechanism.
• May be bi-directional.
Person Car
owns
0..*
17. Recursion
• Self referential construct.
• Complex construct, may not be supported
by target language.
User
Directory container
contents
owner
authorised user
* *
*
*
0..1
18. Qualified Associations
• A qualified association relates two Object
Classes and a “qualifier”.
• One-to-many and many-to-many
associations may be qualified.
• The qualifier distinguishes among the set
of objects at the “many” end of an
association.
19. Directory File
Is more clearly expressed as .....
Directory File
File name
*
Qualified Associations
20. Or-Association
• A constraint on two or more associations.
• Objects of a class may participate in at
most one of the associations at a time.
Insurance Co
Insurance
Contract
Person Company
1 0..*
{or}
0..*
1..*
1..*
21. Ordered Association
• Shows implicit order of associations.
• Default is unordered.
Window Screen
Controller Sensor
{ordered}
{ordered}
Visible on
polls
*
*
22. Association Class
• Class may be attached to association, and
not another class.
Person
Company
Employment
Period: dateRange
*
0..1
Association Class
employer
24. Composition Aggregation
• More restrictive. Strong ownership here.
• Rules
– Parts live inside whole, parts die with whole,
like automatic variables.
– Multiplicity on whole side must be “0..1”, on
part side may be anything.
• Composition aggregation forms a tree of
parts, shared forms a network of parts.
27. Generalisation
• Generalisation and Inheritance allow
sharing of similarities among Classes while
also preserving differences.
• Inheritance refers to mechanism of sharing
attributes & operations between subclasses
and their superclass.
• Default values of attributes & methods for
operations may be overridden in subclass.
31. Constrained Generalization
• Generalisations may be
– Overlapping: inherit multiple subclasses with
common superclass.
– Disjoint: opposite to overlapping.
– Complete: all subclasses specified, no more
allowed.
– Incomplete: more subclasses may be added to
hierarchy.
32. Engineering Process for Allocation
of Responsibility
• Process will lay down rules for timing of
allocation of responsibilities to classes from
use cases.
• May use domain analysis, find classes &
relationships, then allocate from use cases.
• May find classes from use cases.
34. Class Description
• Develop a Class description, either in
textual prose or some other structured
form. E.G. using a customer in a Bank
– Customer: a holder of one or more accounts in
a Bank. A customer can consist of one or more
persons or companies. A customer can: make
withdrawals; deposit money; transfer money
between their accounts or to another account;
query their accounts.
35. Structured Class Description
Class Name: Customer
Description: Personal or company details
Superclass: User
Name: Name
Description: Customer’s name
Type: String (max. 12 chars)
Cardinality: 1
Name: Owns
Description: Details of bank accounts
Type: Account
Cardinality: Many
38. Class Diagram Notation
• Depicts static structure of classes.
• Classes represent things in the system.
• Classes may be related in many ways…
– Associated
– Dependant
– Specialised
– Packaged
