Training of master Trainers Workshop

10 – 15 November 2012

e-Services Design and Delivery

Module VII

Emilio Bugli Innocenti

 e-Services Design & Delivery

Contents of MODULE VII – “e-Services Design &

Delivery”

Data Modeling: Entity Relationship Diagrams

System Modeling: Unified Modeling Language
Example/Case Study: The KIWI Project
 e- Service Design & Delivery: the Technical
Perspective
DATA SET DESIGN: ENTITY-RELATIONSHIP DIAGRAM

Data modeling – a technique for organizing and documenting

a system’s data. Sometimes called database modeling.

Entity relationship diagram (ERD) – a data model utilizing

several notations to depict data in terms of the entities and
relationships described by that data
 e- Service Design & Delivery: the Technical
Perspective
Data Modelling Concept: Entity

Entity – a class of persons, places, objects, events, or

concepts about which we need to capture and store data.
Named by a singular noun
 Places: sales region, building, room,
branch office, campus.
 Objects: book, machine, part, product, raw material, software
license, software package, tool, vehicle model, vehicle.
 Events: application, award, cancellation, class, flight, invoice,
order, registration, renewal, requisition, reservation, sale, trip.
 Persons: agency, contractor, customer,
department, division, employee,
instructor, student, supplier.
 Concepts: account, block of time, bond, course, fund,
qualification, stock.
 e- Service Design & Delivery: the Technical
Perspective
Data Modelling Concept: Attribute
Attribute – a descriptive
property or characteristic of an
entity. Synonyms include
element, property, and field.
– Just as a physical student
can have attributes, such as
hair color, height, etc., data
entity has data attributes

Compound attribute – an
attribute that consists of other
attributes. Synonyms in different
data modeling languages are
numerous: concatenated
attribute, composite attribute,
and data structure.
 e- Service Design & Delivery: the Technical
Perspective
Data Modelling Concept: Identification
Key – an attribute, or a group of attributes, that
assumes a unique value for each entity instance.
It is sometimes called an identifier.
– Concatenated key - group of attributes
that uniquely identifies an instance.
Synonyms: composite key, compound
key.
– Candidate key – one of a number of
keys that may serve as the primary key.
Synonym: candidate identifier.
– Primary key – a candidate key used to
uniquely identify a single entity
instance.
– Alternate key – a candidate key not
selected to become the primary key.
Synonym: secondary key.
 e- Service Design & Delivery: the Technical
Perspective
Data Modelling Concept: Relationship

Relationship – a natural business association

that exists between one or more entities.
The relationship may represent an event that
links the entities or merely a logical affinity that
exists between the entities.
 e- Service Design & Delivery: the Technical
Perspective
Data Modelling Concept: Cardinality
Cardinality – the minimum and maximum number of
occurrences of one entity that may be related to a single
occurrence of the other entity.
Because all relationships are bidirectional,
cardinality must be defined in both directions for
every relationship.
 e- Service Design & Delivery: the Technical
Perspective

Data Modelling Concept: Degree

Degree – the number of entities that participate in the
relationship.
A relationship between two entities is called a binary
relationship.
A relationship between three entities is called a 3-ary or
ternary relationship.
A relationship between different instances of the same
entity is called a recursive relationship.
 e- Service Design & Delivery: the Technical
Perspective

Logical System Models

• Logical models remove biases that are the result of the way
the system is currently implemented, or the way that any
one person thinks the system might be implemented.

• Logical models reduce the risk of missing business

requirements because we are too preoccupied with
technical results.

• Logical models allow us to communicate with end-users in

nontechnical or less technical languages.
 e- Service Design & Delivery: the Technical
Perspective

Difference between DFDs and Flowcharts

• Processes on DFDs can operate in parallel (at-the-same-time)
– Processes on flowcharts execute one at a time

• DFDs show the flow of data through a system

– Flowcharts show the flow of control (sequence and transfer of control)

• Processes on a DFD can have dramatically different timing (daily,

weekly, on demand)
– Processes on flowcharts are part of a single program with consistent
timing
 e- Service Design & Delivery: the Technical
Perspective

System Design: UML - Unified Modeling Language

•It is a modeling language, not a process
•In 1996, work on the UML was begun by Rational
•UML is a robust notation that can express information gathered
throughout a project’s lifecycle.
•Adopting standard use of UML can improve communication
between clients and developers.
•UML can be used as an effective data modeling tool as well as
an object modeling tool.
 UML

UML Diagrams

1.Class Diagrams
2.Use Case Diagrams
3.Collaboration Diagrams
4.Sequence Diagrams
5.Package Diagrams
6.Component Diagrams
7.Deployment Diagrams
8.Activity Diagrams
9.State Diagrams
 UML

Class Diagrams

•Are the most fundamental UML Diagram.

•Describe the classes in the system, and the static relationships
between classes.
•Class diagrams are used during Analysis, Design and
Development
 UML
Customer
1

Class Diagrams
Rental Invoice

Rental Item 1..*

1 0..1

1
Checkout
CheckoutScreen
Screen
DVD Movie VHS Movie Video
Video Game
Game
 UML

Class Diagrams Multiplicity

Customer
1 Simple
Class Aggregation

Abstract Rental Invoice

Class

Rental Item 1..*

{abstract}
1 0..1
Composition
Simple
Generalization (Dependency)
Association

Checkout Screen
DVD Movie VHS Movie Video Game
 UML

Parts of a Class
• Classes can have MyClassName
four parts
+SomePublicAttribute : SomeType
– Name
-SomePrivateAttribute : SomeType
– Attributes #SomeProtectedAttribute : SomeType
– Operations
+ClassMethodOne()
– Responsibilities
+ClassMethodTwo()
• Classes can show
visibility and types. Responsibilities
• All parts but the -- can optionally be described here.

Name are optional.

 UML
Object Diagrams
• An Object is an
instance of a class.
• Object names are ThisOne : MyClassName
underlined.
• Object diagrams are +SomePublicAttribute : SomeType
-SomePrivateAttribute : SomeType
similar to class
#SomeProtectedAttribute : SomeType
diagrams. Many of
the same notations +ClassMethodOne()
are used. +ClassMethodTwo()

• Object diagrams
capture instances of
classes, and allow
the dynamic
relationships to be
shown.
 UML
Class Name Association Name

Customer Rental Item

+id:integer Rents
+name:string

Class Diagram
Attributes
Object Name

Joe: Customer Casablanca: Movie

+id:1667 +id:22340
+name:Joe Smith +released:1942

Object Diagram

Class and Object Diagram

 UML
Use Cases

•Describe interactions between users and computer systems

(both called actors) .
•Capture user-visible functions.
•Achieve discrete measurable goals.
•Are typically used during Analysis and Design.
 UML
Use Cases
Use Case
Actor

Identify Movie

Open Account
Customer Clerk

Return Movie

In-Store Telephone Review

Customer Customer Account Status
 UML
Use Case Report
• The Use Case Report •• Brief
Briefdescription
description
provides •• Precondition
Precondition
documentation for •• Flow
Flowofofevents
events
–– Main
Mainflow
flow
the Use Case. –– Subflows
Subflows
• A Use Case is not –– Alternate
Alternateflows
flows
complete without •• Postcondition
Postcondition
the report. •• Special
SpecialRequirements
Requirements
• The elements of the •• Enclosures
Enclosures
–– Diagrams
Diagrams
Use Case Report are –– Pictures
Picturesof
ofthe
theUI
UI
shown on the right.
 UML

Collaboration Diagrams

•Collaboration diagrams describe interactions and links

•Focus on exchange of messages between objects
•Appears during Analysis phase
•Enhanced during Design phase
 UML

Collaboration Diagrams – Rent a movie

:Rented
Items

5: add(customer, movies) Object

1: enter_customer()
8: generateRentalTotal()
3: enter_movies()
7: print invoice() 2: IsValidCust(CustId)

:Check-out :Customer
Manager

:Clerk

4:GetMovieByBarcode()

:Inventor Message
y
 UML

Sequence Diagrams

•Can be “morphed” from Collaboration Diagrams.

•Describe interactions between objects arranged in time
sequence
•Focus on objects and classes involved in the scenario and the
sequence of messages exchanged
•Associated with use cases
•Used heavily during Analysis phase and are enhanced and
refined during Design phase
 UML
Sequence Diagrams – Rent a Movie

:CheckoutMgr Cust:Customer :Inventory :RentedItems

: Employee

1: find customer()
2: search (string)

3: enter movie() 4: search (string) Object

Message Activation

5: rent (movie)
6: add(Cust, item)

Lifeline
7: printInvoice() 8: generateRentalTotal()
 UML
Package Diagrams

C le rk U s e r In te rfa c e

(to b u sin e s s
C u s to m e r D a ta « fa c a d e » s ys te m )
B u s in e s s
S ys te m
C lie n t

Class R e n ta l S c re e n
Package
 UML
Component Diagram
Component
«library»
D B S erver
Interface
(dbsvr.dll)

«library»
Interface
A pplication
F ram ew ork
(appfr.dll)
Dependency

«application»
V ideo
W orkstation Note S upplied by
(vstation.exe) M icrosoft
 UML
Deployment Diagram
Node

Communication :S tore S erver

Association

S erver
DB
P hone C lerk T erm inal
:C lerk C lient «T C P /IP »

S tore
C heck O ut T erm inal S erver
:C lerk C lient «T C P /IP » A pp
 UML
Activity Diagram Start State

Identify Action State

Caller

Decision
Obtain Name
Open
& Address
Account?
Current
[no]
Customer? [no]

[yes]
End State
[yes]
Create
Account
 UML
Customer Manager Walking Clerk
Identify
Movie Fork Point
Swimlanes and
Place
Fork/Join Points Order

Place
Order

Fill
Collect Order
Pay
Money

Pickup Deliver
Movie Movie Join Point
 UML
Guard

State Diagram Event

Transition
[m ore videos]
/get next video
custom er appears
Validate [account valid] Check-Out
do/check /get first video do/check-out Action
account video

[no m ore videos]

Activity
Check-Out
[account not Com plete
State
valid]
 UML

UML Diagrams Usage

Development UML Diagrams
Phase
Analysis Use Cases, Class Diagrams, Activity
Diagrams, Collaboration Diagrams,
Sequence Diagrams
Design Class Diagrams, Collaboration
Diagrams, Sequence Diagrams, State
Diagrams, Component Diagrams
Deployment Diagrams
Development Collaboration Diagrams, Sequence
Diagrams, Class Diagrams, State
Diagrams, Component Diagrams,
Deployment Diagrams
Implementation Package Diagrams, Deployment
Diagrams
 UML
CASE STUDY – The KIWI Project - Use Cases for Milan
Prefecture
Main Actors
 UML
CASE STUDY – The KIWI Project - Use Cases for Milan
Prefecture
External Actors

External User
(from Actors)

CSA - Administrative
Employer Foreign Employed Services Centre
Worker

Home Help and

Subordinate Work Assistant
 UML
CASE STUDY – The KIWI Project - Use Cases for Milan
Prefecture
Workflow on the fly
create the Workflow on the Fly
task force

delete a W orkflow on the Fly task

force

Prefecture U.T.G.
Responsible
(from Use Case View)
modify a Workflow on the Fly task

get the W orkflow on the Fly

members
 UML
CASE STUDY – The KIWI Project – Activity Diagram
Back End Process
 UML
CASE STUDY – The KIWI Project – Sequence Diagram
Workflow on the fly