Students will be able to :
• Describe a class
• Identify components of a class diagram
• Explain the terms:
– Multiplicity
– Inheritance
– Aggregation
– Generalisation

• A description of a set of objects that share the same attributes, relationships and semantics.
• An abstraction
• 3 Parts : A Name, Attributes and Operations
• An object would be an instance of the class
• EG
– Class – a libraryMember borrows a bookCopy
– Object – Joe Bloggs borrows copy 1 of UML Distilled

ClassName
Attribute1
Attribute2, etc
Operation1
Operation2, etc
Eg
Window origin size open() close() move() display()

• Named property of a class – usually a noun
• Describes a range of values
• A class can have many attributes or none
• The attribute is shared by all objects of the class
• EG
– All students have name, address, date of birth
– All cats have ....

Eg
Wall height: Float width: Float thickness: Float isLoadBearing: Boolean = false
Can be further specified by stating their type and even a default value

• The implementation of a service
• Something that can be done to an object, that is shared by all objects of that class
• Each class can have many operations or none
• Usually a verb

WashingMachine brandName: String modelName: String serialNumber: String
Capacity: Integer acceptClothes (c:String) acceptDetergent (d:Integer) turnOn( ) : Boolean capacity( ) : Boolean
Can be further specified by stating parameter
& parameter type and function return values

Attributes and Operations with Visibility
Television
+ brandName: String
+ modelName: String
+ changeVolume( )
+ changeChannel ( )
- paintImageOnScreen ( )
Accessibility levels
+ Public
# Protected
- Private

WashingMachine brandName: String modelName: String serialNumber: String
Capacity: Integer acceptClothes (c:String) acceptDetergent (d:Integer) turnOn( ) : Boolean capacity( ) : Boolean
Take dirty clothes as input and produce clean clothes as output
In an area below
The operations list you can describe the class’s responsibility
(must be done in an unambiguous way)

WashingMachine brandName: String modelName: String serialNumber: String
Capacity: Integer acceptClothes (c:String) acceptDetergent (d:Integer) turnOn( ) : Boolean capacity( ) : Boolean (capacity = 16 or 18 or 20lb)

• A description of types of objects in the system
• It has classes, relationships and multiplicities
• Constraints may be applied to the way objects are connected
• It may also have navigability or roles

borland.com

• A relationship between classes
• Used if there is a real-world association
• A short sentence – associations correspond to verbs
• E.g. – A player plays on a team
• Links can be uni-directional or bi-directional
• In class associations each class usually plays a role e.g. in professional team, team is employer and player is employee
Player
Employee
Plays on ►
Employer
Team

• Records constraints on associations
• Caters for permitted or required number of links (a link is an instance of an association)
• Specify :
– An exact number (e.g. use 1)
– A range of numbers (e.g. use 2..8 or 1..*)
– Arbitrary, unspecified number (use *)
– Discrete numbers (e.g. use 5,10)

• Optional
• – lower bound of 0
• Mandatory
• – lower bound of 1 or more
• Single-valued
• – upper bound of 1
• Multivalued
• – upper bound of > 1 (usually *)

EggBox
holds 1 12,24
Egg
Car
1..* Is owned by 1
Owner

borland.com

• Ways of showing more about an association
• An object of one class is part of an object of another class
• Denoted by a diamond at the whole end of the association
• Composition is a special kind of aggregation
– the whole owns its parts

borland.com

• Uses inheritance
• EG – a business could have two types of customer
– Corporate customer
– Personal customer
• Both have similarities that can be placed in a general Customer class (supertype)
• Personal and Corporate customers are subtypes

Customer
+name
-address
+getCreditRating()
Corporate Customer
+contactName
-creditRating
-creditLimit
+billForMonth()
+remind()
Personal Customer
+creditCardNumber

Another Generalisation Example

• Relationship between an object and its type
• Single Classification :
– Object belongs to single type
– May inherit from supertypes
• Multiple Classification :
– Object may be described by several types
– Not necessarily connected by inheritance

Multiple Classification Example
Agilemodeling.com

• Static structure of objects in a system
– Identity
– Relationships
– Attributes
– Operations

• Class : Group of similar objects
• Association : group of similar connections between objects
• Generalisation : structures description of objects by organising classes by similarities/differences
• Attributes and Operations : elaborate structure

• Describes real-world classes and their relationships to each other.
• Information gained from :-
– Problem statement
– Artefacts
– Expert knowledge of application domain
– General knowledge of real world
• Does not rely on a single source

Constructing a Domain Class Model
• Find classes
• Prepare data dictionary
• Find associations
• Find attributes of objects and links
• Organise and simplify using inheritance
• Iterate and refine

• Physical Entities
– Houses, People, Machines, etc
• Concepts
– seating assignments, payment schedules, etc
• Usually Nouns
Requirements
Source
Extract Nouns
Tentative
Classes
Eliminate Spurious
Classes
Classes

• Is it beyond the scope of the system ?
• Does it refer to the system as a whole ?
• Does it duplicate another class ?
• Is it too vague ?
• Is it too specific ?
• Is it too tied up with physical I/Os ?
• Is it really an attribute ?
• Is it really an operation ?
• Is it really an association ?

• Littlesand, Pebblesea and Mudport are three charming resorts on the south coast which are very popular with tourists, since they score well on beach ratings and hours of sunshine for the sea.
• All three resorts have a large number of places to stay, ranging from one-room guest houses to the exclusive Palace Hotel at
Pebblesea. The local tourist board wants to set up a central system to deal with room bookings in the area.
Britton & Doake (2000)

Exercise part a) & b)
- Tentative Classes
• Write out the scenario on previous slide and underline the tentative classes (possible classes)
• Some of the words/phrases that you underline will class attributes
• Then following the example on the next slide, categorise the classes into
– Vague – too vague to use
– Redundant – no use for it
– Implementation – concerned with implementation issues
– Attribute – the item has turned out to be an attribute of a class

Vague
Exercise part b)
- Bad Classes
Implementation
Attribute
Redundant

Exercise part c)
- Good Classes
• Write out a list of the classes that you have left
• These will be used to create you class diagrams

Exercise part d)
- Prepare Data Dictionary
• Isolated words can be misinterpreted
• Write a paragraph precisely describing each class
• Eg: Room – a room at a place to stay against which bookings can be made. Rooms may be of various types. A place to stay can contain more than one room.

Exercise part e)
- Initial Class Diagram
- construct a class diagram showing just class names

Exercise part f)
- Find Associations and multiplicity
• Show relationships between classes
• Often correspond verbs :
– Physical Locations (NextTo, PartOf,
ContainedIn, etc
– Directed actions (Drives)
– Communication (TalksTo)
– Ownership (Has, PartOf)
– Satisfaction of Condition (WorksFor,
MarriedTo, Manages, etc)

Exercise part g)
- Find Attributes for the main (resort) class
• Data Properties of individual objects
• Use
– Knowledge of application domain
– Artefacts
• Capture the most important – you can add detail later

Exercise part h)
- Refine Using Inheritance
• Bottom-up generalisation
– Classes with similar attributes, associations, operations
– Define superclass to share common features
• Top-down specialisation
– Similar class names (eg fixed menu, pop-up menu, sliding menu)

• Object-Oriented Modelling and Design with UML,
Michael Blaha and James Rumbaugh,
• UML Distilled, Martin Fowler,Addison Wesley ISBN 0-
321-19368-7
• Using UML, Perdita Stevens
• www.agilemodeling.com
• Object-Oriented System Development (2000) Britton
& Doake