Module P00801
E-Business Information Systems
March 2011
Lecture 6
E-Business Modelling with UML
Prof. Hong Zhu
Department of Computing and Electronics
P00801: E-Business Information Systems
1
Outline
 Principles
March 2011



Roles of models in e-business software development
Principles of object-oriented modelling
Types of models
 United

of Software Modelling
Modelling Language UML
Functional models
 Use case diagram
 Activity diagram

Structural models
 Class diagram
 Object diagram

Behaviour models
 Sequence diagrams
 Collaboration diagrams
 State machine
P00801: E-Business Information Systems
2
What is a Model
Irrelevant details are omitted.
 Model
March 2011
is an abstract description of a system under study
 In scientific disciplines, we often use a set of
statements
For example, Newtonian physics models objects by three
laws
 In
engineering disciplines, we often use small scale
objects (also in different material, etc.)
For example, in architecture design, architectures use
structural models of buildings
 For
software modelling, we often use a set of
diagrams
For example: SSADM uses dataflow diagrams, control
flow diagrams, entity relationship diagrams
P00801: E-Business Information Systems
3
Relationship between system and model
March 2011
 A system
is an instance of model, if the
description is correct
 the statements are true
 the structure and operation of the system is as
the meaning of the diagrams
 Model as the specification, system as the
implementation
 One
model, many instances
different ways of implementations
 One
system, many models
 different ways of abstraction
P00801: E-Business Information Systems
4
March 2011
Modelling in E-Business Software Development
Activity
Requirements
Elicitation
Requirements
Clarification
Roles of Modelling
Guide the analyst to obtain the information in the
process of model construction
Force the analyst to explicitly express obtained
information clearly in well-defined notations in
model construction
Req. & Design Represent information in the form of models in
Documentation well-defined notation without ambiguity
Validation,
Support VV&T by readable representations of
Verification and models at a suitable level of abstraction that are
Testing
easy to understand by users and developers
Analysis and
Support automated and semi-automated analysis
transformation and transformation by representing systems in
machine readable models
P00801: E-Business Information Systems
5
Model-Driven Software Development
Platform
Independent
Model (PIM)
General ideas:
March 2011
 Develop
a model is the
main goal of the
development at early stage;
 Use the model as the
baseline for later
development activities;
 Use automated tool to
construct analyse and
process models.
Use automated
modelling tool
Platform
Specific Model
(PSM)
P00801: E-Business Information Systems
Automated code
generation tool
Executable
code
6
Types of Models
March 2011
Type
What are modelled
Functional The functionality of the
models
SW as its roles in the
business process and its
interaction with the user
and environment
Structural The structure of the
models
data that supports the
business process in an
organisation and their
representation and
process in the SW
Behaviour The internal dynamic
models
aspects of an IS that
supports the business
processes in an
organisation
Focus
UML
How the system works Use case
from the external point diagram,
of view
activity diagram
The logic organisation
of data at RE and
technical details such
as how the data are
stored, created or
manipulated in design
and implementation
The internal logic of
processes and how the
processes are
implemented
P00801: E-Business Information Systems
Objects and
class diagrams
Packages,
deployment and
component
diagrams
Sequence,
communication,
behavioural
state machine
7
Relationships Between Types of Models
External view
March 2011
Functional
model
Use case
diagram
Activity
diagram
Internal view
Static view
Dynamic view
Structural
model
Behavioural
model
Class
Diagram
Sequence
diagram
Object
Diagram
Communication
diagram
Behavioural
state machine
P00801: E-Business Information Systems
Interaction
view
Individual
view
8
Underlying Principles of OO Modelling (1)
 An
March 2011
information system should be structured in
such a way that it reflects the structure of the real
world system
 Easier
to understand the information system
Metaphor: using the same vocabulary to describe the
entities in the information system as the users describes the
things, ideas and concepts in the real world
 Easier
to modify the information system
Users’ requirements tend to change much more frequently
than the structure of their organisation and the domain
Changes in organisation system can be relatively easily
reflected in the modification of the information system
P00801: E-Business Information Systems
9
Underlying Principles of OO Modelling (2)
 ‘Everything

March 2011


in the world is object’. Hence,
The real world can be modelled by objects
Everything in an information system should be an object in
order to satisfy principle 1
All information systems can be modelled in OO approach
Real
world
Analysis
phase
Semantic gap
Model of the
real world
P00801: E-Business Information Systems
World of
software
Model of the
SW world
Design
phase
10
The Meta-Model of Object-Orientation
 Object
March 2011
 A set
of attributes:
The states of real world objects are reflected by the
values of the attributes
 A set
of methods:
The changes of states are reflected in the collection of
methods that changes the states of objects
 The
set of attributes and the set of methods are
encapsulated into one computational entity
P00801: E-Business Information Systems
11
 Class
Class is called the classifier of
objects, similar to data type is the
classifier of data
March 2011
 The
similarity between objects is reflected by
classifying them into the same class.
 Objects are instances of classes
 Class is the template for a collection of objects that
have the same structure, i.e.
the same set of attributes, and
the same set of methods.
Class is an abstract thing that does not
actually exist in the system at runtime.
P00801: E-Business Information Systems
In mainstream OO
methodology, objects does
not change their
membership to the classes.
12
Relationships Between Objects
 Generalisation
March 2011

Definition:
Class A is a generalisation of class B, if every instance of
class A is also an instance of class B.
 Class A is called a super-class of B; class B is called a subclass of A.
 We also say that class B is a specialisation of A.
 A relationship between classes: the super-class /subclass relationship is
also called inheritance relation.
– Class B inherits the attributes and methods of A.

Example:
 Undergraduate Student is a subclass of Student;
 Postgraduate Student is a subclass of Student;
 Student is a subclass of Person;
 Lecturer is also a subclass of Person
P00801: E-Business Information Systems
It also allows B to
specialise the
attributes and
methods by giving a
new definition
while maintain the
same semantics
13
 Whole-part

relationships
Whole-part: Object A is a part of object B
 A wheel is a part of a car

Aggregation: an object consists of several other objects
 A car consists of 4 wheels, 1 engine, 1 steering wheel, …

Key features of whole-part relationship
March 2011
 Life-dependence: E.g. Heart is a part of human body.
– Whether a part object can exist without being a part of a whole
object
E.g. Your money is also mine.
 Shareability:
– Whether a part object can be a part of more than 1 object
 Cardinality: (also called multiplicity):
E.g. A bike has 2 wheels.
– How many part objects can be contained in 1 whole object

Types of whole-part relations in UML:
 Aggregate: shareable, but no life-dependence
 Composite: life-dependent and not shareable
P00801: E-Business Information Systems
14
 Association
object A affects another object B’s state, e.g.
object A can directly cause object B to change its
state (by invocation of object B’s method).
March 2011
 An
A doctor operates on a patient
Engine drives wheels
Steer wheel change the direction of wheels
object A monitors another object B’s state, e.g.
object A accesses B’s attributes.
 An
P00801: E-Business Information Systems
15
Functional Models

Describes the functionality of the SW

its roles in the business process
 its interaction with the user and environment
March 2011

What are the functions
 How the system works from the external point of view

UML’s support of functional modelling
 Use
case diagram
 Activity diagram
P00801: E-Business Information Systems
16
Use Case Diagrams
March 2011
 A use
case diagram
is a collection of
actors, use cases,
and their
communication
 Used during
requirements
elicitation to
represent the
functions of a
system from
external point of
view
P00801: E-Business Information Systems
17
The Notation of UML’s Use Case Diagrams

March 2011

Passenger

Actors represent roles, that is, a type of
user of the system
Use cases represent a sequence of
interaction for a type of functionality
<<Extend>> or <<Include>> relations
between use cases
<<Extend>>
PurchaseTicket
FindRoute
P00801: E-Business Information Systems
18
Actors
March 2011

Passenger


An actor models an external entity
which communicates with the system:
 User
 External system
 Another computer system
 Physical environment
An actor has a unique name and an
optional description.
Examples:
 Passenger: A traveller on the train
 GPS satellite: Provides the system
with GPS coordinates
P00801: E-Business Information Systems
19
Use Case
 A use
March 2011
PurchaseTicket
case represents a class of
functionality provided by the
system as an event flow.
 A use case consists of:

Purchase
Ticket





Unique name
Participating actors
Entry conditions
Flow of events
Exit conditions
Special requirements
P00801: E-Business Information Systems
20
March 2011
Example of Use Case Diagram
Flow of Events:
1. The seller selects an agent.
2. The system responds by assigning an agent and notifying
Seller
Buyer
Loan Adviser
the seller’s agent.
3. The seller lists the property to sell.
4. The system responds by displaying this property in the
System
property listing and linking it for searches.
Sell Property
5. The buyer selects an agent.
6. The buyer reviews the property listings by entering search
criteria.
7. The system responds by displaying properties that match
Use case name:
the buyer’s search criteria.
Sell Property
8. The buyer finds a property and makes an offer on it.
Participant:
9. The system responds by notifying the seller and the seller’s
Buyer, Seller,
agent.
Loan Adviser
10. The seller responds to the offer with a counteroffer.
Entry conditions:
11. The system responds by notifying the buyer and the buyer’s
…
agent.
Exit conditions:
12. The buyer and the seller agree to terms.
…
13. The system responds by recording the agreement.
Kulak, D and Guiney, E.,
14. The buyer indicates that a loan is required.
Use Cases: Requirements
15. The system responds by locating an appropriate loan
in Context, Addison
provider.
Wesley, 2000 (page 19016. The buyer and the loan provider agree to loan terms.
191)
17. The system responds by recording the terms of the loan.
18. The buyer and the seller close on the property.
P00801: E-Business
Systems by recording the details of the close.
19. TheInformation
system responds
21
Revised use case diagram
How to decompose long transactions into use cases?
System
March 2011
Request sell
Search for property
<<extend>>
Deal with offer
Make offer
Seller
Close sell
Request loan
Buyer
Recommend loan provider
Adviser
Pass offer to seller
Accept loan
Complete purchase
P00801: E-Business Information Systems
22
Notation of UML’s Activity Diagrams
Action
March 2011
Class name
Action/activity node: an action or an activity
Control flow
Object node: represent an object
Object flow
Initial node: beginning of a sequence of actions/activities
Final activity node: stop all control flows and object flows in an activity
Final flow node: stop a specific control flow or object flow
Decision node
Merge node
Fork node
Join node
P00801: E-Business Information Systems
Swim lane: break
up an activity
diagram into parts
to assign the
activities or actions
to the actors
23
Activity Diagram: the Underlying Concepts
 Action/Activity
March 2011
 Performed
for some specific business reason
 Can be manual or computerised behaviour
 Named by a verb with a noun, e.g.
Make payment arrangement
Book an air ticket
Enter delivery address
 Action:
simple, not decomposable
 Activity: can be further decomposed into a set of
actions or activities
P00801: E-Business Information Systems
24
Control Flow and Object Flow
 Control
flow
March 2011
 Model
the path of execution through a business
process
 Can only be attached to action/activity nodes
 Object
flow
 Model
flow of object through a business process
 Show the objects that flow into and out of the
actions or activities (i.e. passed between activities)
 Similar to dataflow in dataflow diagrams
 Attached to one action/activity node and an object
node
P00801: E-Business Information Systems
25
Example: Appointment
Decision node
March 2011
Object node
Get patient info
[old patient]
Appt request
form
Decision
condition
[New patient]
Create new patient record
Appt request
form
Make an appointment
Object flow
Appt
P00801: E-Business Information Systems
26
Swim Lanes
March 2011
 Breaking
up an activity diagram into parts by placing
activities/actions into the swim lane box
 Assigning responsibility to objects or individuals that
performs the activities/actions by assign a name of
object/individual to each swim lane
 Representing parallel and concurrency of executions
 Modelling a business workflow,


Describing ‘who is doing what’ using swim lanes
Describing ‘how they coordinate’ using synchronisation bar
P00801: E-Business Information Systems
27
Example: Make a School Lunch Box
Mother
Father
March 2011
Get jelly
Get bread
Get drink
Get dessert
Get peanut butter
Create sandwich
Get lunch box
Put lunch in box
P00801: E-Business Information Systems
28
Structural Models
General concept:
March 2011
 A structural model
describes a system in
terms of its constituent elements and their
interrelationship.
For
information systems:
 A structural
model of an information system
describes the structure of the data and their
processing code by dividing them into
computational entities.
P00801: E-Business Information Systems
29
Structural Modelling at Different Phases
 At
analysis phase:
March 2011
 Shows
the logical organisation of the entities without
indicating how they are stored, created, or
manipulated
 Free from any implementation or technical details
 At
design phase:
 Reflects
how the objects will be organised in
databases and files
 Address implementation and technical issues, such as
redundancy in the storing of information,
ease of retrieval of stored information, etc.
P00801: E-Business Information Systems
30
March 2011
UML Class Diagram Notation
Class name
Class name
Attributes
Class node
without
compartments
Methods
Class node with
3 compartments
Aggregate
Composite
Inheritance
Association
P00801: E-Business Information Systems
31
Example: Inheritance Relation
March 2011
Vehicle
Buffalo cart
Truck
Jumbo-jet
P00801: E-Business Information Systems
Aircraft
Helicopter
32
Examples: Multiplicity
March 2011
Car
Wheel
A wheel is
a part of car
Car
Car
1
0..1
4
Wheel
4..5
Wheel
A car has 4 wheels. A car may have 4 or 5 wheels.
A wheel can be on 1
A wheel may be fixed on 1 car,
car at any time.
but it may also be not used by
any car.
P00801: E-Business Information Systems
33
Example: Hospital
Person
March 2011
Symptom 0..*
Employee
Patient
Schedules
1
0..*
0..*
Illness
Treatment
Appointment
0..*
1..*
Doctor
Has scheduled
1..*
Nurse
0..*
Administrative
staff
1
Leads to
0..*
Bill
0..1
*
Health Team
P00801: E-Business Information Systems
34
Example: Class Diagram with Attributes & Methods
Person
March 2011
-surname
-first name
-address
-telephone
-date of birth
-/age
Patient
-amount
…
+make appointment
…
Derived attribute:
Its value is calculated from other
attributes rather than stored.
P00801: E-Business Information Systems
35
Example: Class Diagram
schedules Appointment Has scheduled
1
0..*
0..*
1..*
-amount
-time
Doctor
+make appointment
-date
March 2011
Patient
0..*
1..*
suffer
Symptom
-name
-reason
+Cancel
P00801: E-Business Information Systems
36
Behavioural Models
March 2011
 Behavioural
models describe the internal dynamic
aspects of an information system that supports the
business processes in an organisation
 At requirements analysis stage


 At

Internal logic of the business processes
Without specifying how the system is implemented
design and implementation stage
Details of the designs of the system, such as
 the data types of the attributes
 the operations of the objects
P00801: E-Business Information Systems
Behaviour model describes the
‘journey between the towns’,
i.e. the interactions between
the objects to achieve the
functions of use cases.
37
Two Types of Behaviour Models
 Interaction
March 2011


models
Describe the collaboration between objects and actors in the
business process by describing how objects and actors in the
system communicate, cooperate and coordinates with each
other
In UML, they are described by sequence diagrams and
communication diagrams
 Individual models


Describe the behaviour of individual objects and actors by
describing how they change their states and the actions to be
taken in each state and the outside condition.
In UML, they are described by behavioural state machines
associated to classes
P00801: E-Business Information Systems
38
Interaction Diagrams
Basic concepts
 Object
OO Behaviour rule:
When an object receives a message, it
executes its corresponding method with
the parameters given in the message.
March 2011
Instances of classes
Consists of attributes and methods
 Operations
Attributes describe the information about the object
Operations (i.e. methods) are the actions that an object can
perform, which are essentially procedure/function
declarations that has attributes as global variables
 Messages
Messages are information sent to objects to tell an object to
execute one of its operations
Messages are essentially procedure/function calls from one
object to another
P00801: E-Business Information Systems
39
Sequence Diagrams: Buying Book Online
:Bookshop
:ClientGUI
:Buyer
keywords
:Customer
Manager
keywords
March 2011
List of titles
List of titles
title
title available
title
title available
place order
objects
Two dimensions
time
request customer details
customer details
request credit details
credit details
customer details
credit details
purchase confirmed
P00801: E-Business Information Systems
40
Elements of Sequence Diagrams
March 2011
<<actor>>
Actor/Role
anObj:
Class
Actor: A person or system that derives
benefit from and is external to the system
Object: Participants in an interaction depicted in the
sequence diagram by sending and/or receiving messages
Lifeline: denotes the life
of an object during the
interaction depicted in
the sequence diagram
aMessage() Message: conveys
information from one
Return value object to another one
Execution occurrence:
denotes when an object is
sending and/or receiving
messages
P00801: E-Business Information Systems
Object destruction:
shows an object is
going out of existence
41
Message Flows
There is only ONE thread of execution, and
activity passes from one object to another.
Message flow annotation:
March 2011
Procedural or synchronous - a message is sent by one object to
another, and the first object WAITS until the resulting action has
completed.
Asynchronous - a message is sent by one object to another but the
first object does NOT wait until the resulting action has completed,
it carries on with the next step in its own sequence of actions.
Flat - each arrow shows a progression from one step to the next
in a sequence. Normally the message is asynchronous, but can be
used for both (sync. and async. modes)
Return - represents the explicit return of control from the
object to which the message was sent (optional).
More than one object can be active at any one time.
This would be the case in a multi-threaded system.
P00801: E-Business Information Systems
42
Example: Telephone Connection
March 2011
notation using
an object constraint
language
The objects are:
• sender (person)
• receiver (person)
• telecoms switch
• conversation
UML notation
for a note
P00801: E-Business Information Systems
43
March 2011
Loops and conditionals: UML 1.x
procedure dispatch
foreach (lineitem)
if (product.value > $10K)
careful.dispatch
else
regular.dispatch
end if
end for
if (needsConfirmation) messenger.confirm
end procedure
P00801: E-Business Information Systems
44
March 2011
Loops and conditionals: UML 2.0
P00801: E-Business Information Systems
45
March 2011
Common Operators for Interaction Frames
Operator
Meaning
alt
Alternative multiple fragments; only the one whose condition is true will
execute
opt
Optional; the fragment executes only if the supplied condition is true.
Equivalent to an alt with only one trace.
par
Parallel; each fragment is run in parallel.
loop
Loop; the fragment may execute multiple times, and the guard indicates
the basis of iteration
region
Critical region; the fragment can have only one thread executing it at
once.
neg
Negative; the fragment shows an invalid interaction.
ref
Reference; refers to an interaction defined on another diagram. The
frame is drawn to cover the lifelines involved in the interaction. You can
define parameters and a return value.
sd
Sequence diagram; used to surround an entire sequence diagram, if you
wish.
P00801: E-Business Information Systems
46
Behavioural State Machines

A dynamic model that shows


March 2011

the different states that a single object passes through during its life
its response to events with changes on its state and the actions.
Used for further definition of the behaviour of objects
Enters
Hospital
Waiting
Checks in
> 2 weeks
[Diagnosis
= healthy]
Released
Admitted
[Diagnosis
=Unhealthy]
Under
observation
P00801: E-Business Information Systems
[Diagnosis
= healthy]
47
Basic Concepts of State Machines

State:

The state of an object is defined by the values of its attributes and its relationships
with other objects at a particular point in time.
 E.g. a patient can be new, current, or former.

Event:

March 2011
Something that takes place at a certain point in time and changes a value of an
attribute.
 For example:
 A designated condition becoming true
 The receipt of a call for a method by an object
 Passage of a designated period of time

Transition:

A relationship that represents the movement of an object from one state to another
state.
 A transition is trigger by an event;
 A transition may be associated with an action/activity. The action/activity takes
place when the state transition happens
 A transition may have a guard condition, which is a Boolean expression. The
transition happens only when the guard condition is true
P00801: E-Business Information Systems
48
UML’s Notation of State Machines
March 2011
state
State node
Initial state
Final state
[guard condition]
Event/Action
State
transition
P00801: E-Business Information Systems
49
Further reading
March 2011
 Martin
Fowler, UML Distilled: A Brief Guide
to the Standard Object Modelling language,
Third Edition, Addison-Wesley, 2003.
 Michael P. Papazoglou and Pieter M. A.
Ribbers, E-Business: Organizational and
Technical Foundations, (Chapter 12: EBusiness Modelling, pp305-347)
P00801: E-Business Information Systems
50