COMP1807

Agile Development with SCRUM

Lecture 10: Object Oriented modelling of user
stories within Extreme Programming
Conceptual Class Diagram

By: Dr Avgousta Kyriakidou-Zacharoudiou

a.kyriakidou@gre.ac.uk
By the end of today’s lecture
 User stories (requirements) modelling within the Design phase of
Extreme Programming

 Object Oriented Analysis and Design

 Introduction to UML modelling and diagrams
 Object modelling – Conceptual class diagrams

Dr A.Kyriakidou
Object Oriented Analysis and Design
 The problem area is viewed as objects with certain characteristics (attributes),
exhibiting certain behaviour (methods) that interact/collaborate with each other
to get things done.

An attempt to put data, process and behaviour back together again all in one object.
 By keeping the three elements together, it is easier to model the real problem
domain.
 Provides a cleaner and well-integrated model of system behaviour
 Smooths the transition between analysis, design and programming
 Supports the iterative (repeated cycles) and incremental (in smaller portions
at a time) development process.
 the analysis, design and development happen at repeated cycles and in
smaller portions at a time.

Dr A.Kyriakidou
What is an Object?
 OO indented to make thinking about programming closer to thinking
about the real world.
• What is an object in programming we need to ask what is an object in the real
world?

 Object: a “thing” that is capable of being seen, touched or sensed and

about which users store data and associate behaviour.

BUT WHAT IS A THING?

Types of objects may include a person, place, tangible things or events:
Person objects: student, customer, inspector
Place objects: warehouse, building, room
Things objects: product, vehicle, equipment
Event objects: Order, payment, invoice, reservation, registration,
application, contract
These things exist within the system’s environment, and equally within the system.
Dr A.Kyriakidou
What is an Object?
 Entities that encapsulate data and behaviour
 About which users store data and associate behaviour
 Have characteristics – inherent properties (attributes) that describe them (e.g.
a mag can be full or empty, a lamp can be on or of, an apple can be yellow or
red)
» these are the attributes of any object, things like colour, size, weight
» An object can have many attributes – anything we would like to store for the
object
» describe the current state of an object – state of one object is independent of the
state of the other
 Behaviour – what the object can do, e.g. calculate order total, edit amount.
 Most common methods: Get (view/display), Set (Edit), Create(), Delete()

type : rectangle number: 12445231 name: John

height: 10 type: current gender: M
width: 20 balance: 1000 dob: 14/09/98
getArea() deposit() walk()
resize() withdraw() run ()

Shape Object Bank Account Object Person Object

What is an Object?
Objects are not always physical items or visible items e.g. car, house,
product, apple
 A date, a bank account, timer can be an object – they still meet our idea of object

Each object has an identity, multiple attributes and behaviour

 it can be referred individually
 it is distinguishable from other objects
 Attributes: a mug can be full or empty, but also black or white
 Behaviour: a phone can ring, an airplane can fly , you can deposit in a bank
account or withdrawn.

Can you put the word “the” in front of them?

 The mug, the apple, the bank account, the date.
 You wouldn’t say the saving, the printing, those are verbs indicating behaviours
of objects
Dr A.Kyriakidou
What is a Class?
 Objects and classes go hand in hand.
 Cannot talk about one without talking about the other
 OOAD is all about classes because we use classes to create objects

 A class is a blueprint or template or set of instructions used to create a specific

type of object (object instances) - describes what an object will be, but it’s not
the object itself
 A class comes first

 An abstraction specifying the attributes /behaviour of a set of objects

 Each abstraction describes a set of objects with: common properties
(attributes), common behaviour (operations/methods), common
relationships to other objects, and common semantics

 All objects of a given class are identical in structure (attributes) and behaviour
but contain different data in their attributes. Dr A.Kyriakidou
What is a Class?
• A good class captures one and only one abstraction . It should have one major
theme
• E.g. represents a kind of person, place, event or thing about which the system
will need to capture and store information.
• Each object is an instance of some class, and objects cannot be instances of more
than one class

A class is a blueprint, or prototype, that defines the attributes and the methods
common to all objects of a certain kind.

Class car:
Attributes: make, colour, type, weight etc.
Behaviour: start_engine(); drive()

Class (the blueprint) Objects

Dr A.Kyriakidou
UML Class Notation
 Simply represented as a box with class name inside
 Which also shows the attributes and operations
 The complete signature of an attribute /operation is:
<attributeName>:<type>
<operationName(parameterName:paramType…)>:<returnType>
Visibility: private (-), public (+), protected (#), or package(~)

BankAccount BankAccount BankAccount BankAccount BankAccount

number deposit() number - number: int
balance withdraw() balance - balance: double
Class name

deposit() + deposit(real)
Behaviour withdraw() + withdraw():real
(operations/methods)

Dr A.Kyriakidou
UML Class Notation

Object – Instance of Book

Book : Joebook
title = “Software Engineering”
author = “Pressman”
Class isbn = “2-5345-53455-6”
publisher = “McGraw and Hill” Object – Instance of Book
Book price = 40.00
Book : MariaBook
title: String getQuantity()
author : String get_bookDetails() title = “Computer Science”
isbn: String set_bookDetails() author = “Sommervile”
publisher: String deletebook() isbn = “6-5344-534343-4”
price: Real publisher = “Publishing”
getQuantity() price = 35.00
get_bookDetails() getQuantity()
set_bookDetails() get_bookDetails()
deletebook() set_bookDetails()
deletebook()

In classes we don’t define primary and foreign keys. This goes against the primary
principles of object orientation. It’s not an ERD!
Dr A.Kyriakidou
Object/Class Principles
• Identity - an object knows who it is
• Classification - an object knows the class it belongs to
classify objects to later create similar objects as needed
• Relationships - an object knows of other objects to interact with
this helps to determine inputs and outputs of an object
• Abstract behaviour – an object performs actions/operations/functions,
it does things, it has a specific behaviour
the way data is processed within an object

To define these, ask questions like:

 What do I need to know to perform my role? (What data do they (classes) hold?)
(attributes)
 What do I need to do in order to be able to perform my role? What do they
classes) do? (methods)
 Whom do I need to know to perform my role? (How are they (classes)
associated?) (relations/visibility)
Dr A.Kyriakidou
Objects/Classes collaboration
Customer:
Product: 2459
Mr. Brown
Or
de Order:Brown1
r2 h?
45 uc
9 m
ow
H

300
£
300
” £
own
r

Mr.
.r B wn”
“M B ro

Bro me to
ll r.
Bi to M
S old
en

wn
d
Be

Sen
ou’ve
“Y

CreditCard: Mr. Brown’s Card Dispatch Object Dr A.Kyriakidou

Object Oriented Approach Principles
There are a number of concepts under the OO paradigm that help us deal with
problems.

 OOAD is based on a set of principles that serve to manage and reduce the
complexity of the world.

APIE - Abstraction, Polymorphism, Inheritance, Encapsulation

 Abstraction: capture key aspects, ignore irrelevant detail

 Only include relevant and important things in a class
 Supported by two main ideas:
 Information Hiding and Encapsulation

Dr A.Kyriakidou
Object Oriented Approach Principles
Information Hiding

• A class should hide details of how they are internally implemented as computer
code from other classes.
• Allows for the data (attributes) not to be visible to the outside world, thus
methods are the ones to allow other objects to access the data in a controlled
fashion.

• Hiding information is useful as it cannot be corrupted by other classes that are

not supposed to use it.

• Clipboard example: we can’t see the information on the other person’s

clipboard. We have to ask for permission to access that information.

Dr A.Kyriakidou
Object Oriented Approach Principles
Encapsulation:
 Combining both attributes and behaviour in a class and hide the non relevant
detail at a given scale.
 If you put data and process together you support abstraction as Objects can
be used as building blocks which can be put together to make the system.
 Encapsulation allows for a more robust model, easier to reuse and easier to
maintain Shell
White
Yolk

Example: Object is like an Egg

Yolk is the data surrounded by the white which is the methods that act on the
data. The shell surrounds the whole thing and keeps it together and hides it
from the outside world. The shell is the interface and the only thing that is
seen.

With encapsulation and information hiding, the overhead during maintenance is

reduced as you are certain that when you are fixing a problem inside a class, only
that particular class’s code is affected. Dr A.Kyriakidou
Object Oriented Approach Principles
Inheritance
 An object from a more specific class may inherit properties from a more generic
class. This is referred to as generalisation/specialisation.
• the super-class is general and contains the common attributes and
behaviours of the hierarchy
• the sub-classes are specialised in that they contain attributes and
behaviours unique to the object/class, but they inherit the super-class’
attributes and behaviours also.
• it is a reuse mechanism at both the design and the implementation level

• Identified as an ‘is-a’ or ‘is-a-kind-of’ relation

• 100% Rule - The subclass must conform to 100% of the superclass's attributes,
behaviour and associations Payment
1 Sale
1
amount: Money

Cash Credit Cheque

Dr A.Kyriakidou
Generalisation/Specialisation Example

Generalisation Specialisation
User
name: String
address: String
Inheritable
age: int
gender: Char
Attributes
and display()

+ +
login()
Behaviour

name: String name: String

address: String address: String
age: int age: int
gender: Char gender: Char

display() display()
Student login() Academic login()
gpa: real position : String
status: Char
Super-class: User
enroll() recordGrades()
Sub-class: StudentdisplayGPA
and Academic
() recordAttendance()

Dr A.Kyriakidou
Object Oriented Approach Principles
Polymorphism
 General characteristics of a class can be inherited but overridden if need be.
 Allowing operations of different object classes to have the same name, whilst the
details of the actual operation carried out may be different.
• E.g. “Close method” a door can “swing shut” a window can “slide
downwards”

How is polymorphism related to message sending between objects?

 The requesting object knows what behaviour(method) to request and from
which object but does not need to worry about how that behaviour is
accomplished.

PRINT TEXT object

30000

PRINT
25000 BLUE SKY A
20000 I R L I N E S Sales

GRAPH object
15000 Report January

10000
5000 BLUE SKY A
I R L I N E S Sales
0
Report February
North South East West

PRINT IMAGE object

Inheritance and polymorphism may improve reuse.

This reduces design, programming and validation costs. Dr A.Kyriakidou
Creating Conceptual Class
Diagrams
Object Modelling- Conceptual Class diagram
Visualises a system’s static structure - a model of the problem domain.

• Classes ( Entity/Business Classes)

represent the types of objects
• Associations
represent relations (interaction) between classes
• Attributes
are simple data (that we would like to store) found in classes and their
instances. Each attribute name may be followed by optional details such as
type and default value.
• Operations/Methods
the functions performed by the classes and their instances. What objects of
the class can do. What objects of the class will respond to.
• Generalisations/Specialisations
group classes into inheritance hierarchies

Dr A.Kyriakidou
Classes – Entity or Business Classes
• Things that have common, similar attributes, behaviours, and
common semantics (eg. People, Product)

• Occurrences or events that are part of the information domain for the problem
(eg. payroll system initiating bank transfers)

• Roles played by people who interact with the system (eg. managers, students)

• Organisational units (eg. working teams, department) that are relevant to the
system under development

• Places (eg. a manufacturing floor) that establish the context of the problem and
the overall function of the system

• Structures that define a class (eg. vehicles, building, book/chapters)

Dr A.Kyriakidou
Identifying Entity classes
Application domain – Use-case diagrams
• Use-cases are the best place to look for entity classes/objects.
• Think about interactions between objects that support a use-case
• Draw upon the use-case diagram and use case scenario descriptions to find a
set of classes that can interact in order to realise that use-case
• For each use case and use case scenario find “nouns” that correspond to
business events. Nouns correspond to classes. Verbs offer clues about the
methods.
Place new Nouns: member, order
member Verbs: place_order
order

Specification from clients

Observation, from deliberation and role playing (CRC cards)

Dr A.Kyriakidou
CRC cards
• Object Oriented analysis technique that Class Name
includes users and developers Responsibility Collaborator
– A brainstorming technique for
identifying objects/classes, their
behaviour and their associations

• 3 basic parts: Class Mailbox

– Class: name goes at the top of the card

Dr A.Kyriakidou
Responsibility Collaborator
– one card per class
– Responsibilities: something that the - Keep new and
saved messages MessageQueue
class knows (keeps track of) or does). - Manage the class
High level responsibilities only recorded greeting
– Collaborator: another class that the
current class has to work with to To successfully keep new and saved
complete its responsibilities messages – need to send them to
– A class that has information we MessageQueue to be stored
need
– That helps perform a task
Pruning unsuitable classes
Redundant Classes Some potential classes differ only in name.

Irrelevant Classes Classes that have nothing to do with the system.

Example: computer connection.

Vague Classes Classes whose meaning is not clear at all. Examples:

system and software.

Specific Classes Model classes rather than instances e.g. supplier instead
of Andrew.

Dr A.Kyriakidou
Attributes Some nouns in the list above are likely to be modelled as
attributes rather as classes. Examples: author

Operations Some nouns are likely to be operations rather than

classes. Example: book search.

Roles Some nouns are roles of objects involved in associations

rather than classes.

Implementation Anything that is not part of the real-world problem.

Constructs
Dr A.Kyriakidou
Conceptual Class Diagram Relationships
Represent connections between multiple classes or a class and itself

3 basic categories:
 Association relationships

 Generalisation/Specialisation relationships (inheritance)

 Aggregation/composition relationships

Dr A.Kyriakidou
Associations
An association is a relationship between classes (instances of those classes)
that indicates some meaningful connection
 Show how two classes are related to each other
 A usage relation indicating some interaction between two classes
(they can initiate each others’ behaviour)

Criteria:
 to identify check description of the problem domain (or use case
scenarios)
 identify any verbs that might describe relevant relationships
between classes.

Dr A.Kyriakidou
Associations
 An association is represented as a line between classes with an
association name
has-a
Association from Class A Class B
A to B means
that A uses B
directly (by calling its methods for example)

˃ Each association should be labelled in a verb noun phrase, to make

explicit the nature of the association
˃ Associations are inherently bidirectional – ie. from instances of either
class, logical traversal to the other is possible

has-a
This traversal is Faculty Department
belongs to
purely abstract;
it is not a statement
about connections between software
entities
Dr A.Kyriakidou
Associations - Multiplicity
The ends of an association may contain a multiplicity expression indicating the
numerical relationship between instances of the classes. Denotes the minimum ..
maximum number of instances a class association can have.

A PA works for 1 manager

A manager may have many Pas
Personal * 1
Manager
Assistant works for

An order contains many products

and a product belong to many different orders
* *
Order Product
contains belongs to
0..* or 0..m or * Zero or more
1..* or 1..m One or more
0..1 Zero or one
2..4 Specified range
1..3, 5 Multiple, disjoint ranges
1 or no number or range Exactly one Dr A.Kyriakidou
Associations: Avoid many to many multiplicity

Order * * Products

 It’s good practice to eliminate many to many associations

˃ introduce an association class in between the two classes instead
˃ the association class contains attribute(s) that concerns two

Dr A.Kyriakidou
associated classes that cannot be placed in either of the classes
˃ the relationship then becomes one-to-many and many-to-one

Order
1 * OrderLine * 1 Products

Dr A.Kyriakidou
Aggregation
 Introduces no new rules - it just adds vocabulary to notation provides
clarity for design and implementation
˃ Aggregations are special associations that represent ‘whole-part’
relation. The ‘whole’ side is often called the assembly or the aggregate the
‘part’ side is-part-of the ‘whole’
 Aggregation in UML means ‘has-a’ or ‘is-part-of ’
Between 1 and 6 modules are part of 1 or more program

Dr A.Kyriakidou
1..6 1..*
Module Program

Study Pack

1 1
1..* 1..*
Lecture Notes Assignments

A study pack contains 1 or more lecture notes and assignments

lecture notes and assignments can exist independently
Composition
 Represented by a solid diamond at the side of the ‘whole’
˃ The symbol is shorthand notation for ‘is-part-of’ but ‘cannot-exist-
without’ relations
˃ Composition introduces new rules as the objects are tied together -
“contains”/”belongs to” . E.g. Order contains Purchase items

ClassA ClassB

Dr A.Kyriakidou
˃ Class A (composite class - whole) is responsible for creating and
destroying Class B (the composed class’s object - Part) create/add () and
delete() methods included in the composite class

1 *
Building Room

˃ A building may have 0-to-many rooms and a room can

belong to only one building. If building is destroyed room is too. A room
cannot exist on its own but a building can (open plan)
Dr A.Kyriakidou
Identifying Entity Classes, methods, attributes etc.

Part of speech Model component Examples

Proper noun Instance (object) Alice, Ace of Hearts
Field Officer,
Common noun Class (or attribute)
PlayingCard, Value, Staff
Creates, submits,
Doing verb Operation
shuffles, registers

Dr A.Kyriakidou
A relationship between
an object and its class Is a kind of, is one of
Being verb
(defines type of object) either
Inheritance
Aggregation/
Has-a, consists of,
Having verb Association/
includes
Composition
Modal verb Constraint Must be
Helps identify an
Adjective a yellow ball (i.e. color)
attribute
Pioneered by Russell Abbott (1983), popularized by Grady Booch
 Online Book store example

Order Basket
1 0..1 creationDate: Date
creationDate: Date
status: String has qty: int
addOrderLine() totalQty: int
delOrderLine() totalPrice: Real addBasket()
delBasket ()
tackOrder()
editBasket ()
checkStatus()
checkout()

Dr A.Kyriakidou
calculateGrandTotal()
delOrder()
addOrder()
Book Book editOrder() CreditCard
title: String display()
title: StringOrderLine cardHolderName: String
author: String author: String * 1 1 expieryDate: Date
isbn: String isbn: creationDate:
String Date
genre : String cSC: int
genrestatus: String
: String cccNumber: int
qty: int 1 qty:
* intquantity: int * *
addBook()
price: Real
hasaddBook() hashas Is paid 1 validate()
addOrderLine() display()
delBook () delBook ()
delOrderLine() addCCard()
updateInventory() updateInventory()
calculateSubTotal() delCCard()
checkAvailability() checkAvailability()
getPrice() editCCard()
browseBook() browseBook()
editQty()

Dr A.Kyriakidou
Case study Example: Travel Company
 A travel bus company known for their day tours in central London owns a
number of buses.
 The smallest bus has 20 seats.
 Each bus carries out a number of tours.
 When a new tour is scheduled, the company assigns a bus to it and issues
one ticket for each seat on the bus.
 Customers buy tickets for a tour. In order to travel, each customer must
have a valid ticket.
 Some popular tours are totally booked, but on some less popular ones a
bus may travel with some empty seats.

Dr A.Kyriakidou
Travel Company Sample Solution

Customer
name: String
address: String
password: String
user_name: String
addCustomer()
delCustomer()
Tour

Solution ?
editCustomer()

Dr A.Kyriakidou
name: String login()
logout()
Bus description: String displayProfile()
1 *
coachAvailability: Bool 1 Seat
coachCaoacity : Int add_Trip()
delete_Tript() * seatNumber: int
check_Avail() Ticket
add_Coach()
assign_Coach
get_price() 1 1
create_ticket() name: String applySeatPref()
checkSeatAvail()
1 1 get_ticket()
* set_ticket() *
print_ticket()

Dr A.Kyriakidou
Wrap Up – Building Conceptual Class Diagrams
Step 1: Find the potential classes/objects.
review each use-case and its description to find “nouns” that correspond
to business entities

Step 2: Select the proposed classes/objects.

prune list from Step 1

Step 3: Identify possible attributes and methods for each class. Use language helpers

Step 4: Identify associations and multiplicity between the classes

Step 5: Identify generalisation/specialisation relationships

look for objects that have common attributes and
behaviour

Step 6: Identify aggregation/composition relationships

look for any objects that can be part of the others

Step 7: Put all these components in a Conceptual Class diagram

Dr A.Kyriakidou
Readings
• Object-Oriented Systems Analysis and Design Using UML
Bennet St, Farmer R., and McRobb S. 2010 - Chapter 4 & 7
Important to read

Dr A.Kyriakidou