CS1004 INFORMATION SYSTEMS &

ORGANISATIONS
LECTURE 14
ACTIVITIES
Your state diagram?

go to class

[class
not over]

[class over]
 State diagrams
• Used to represent the different states (in
the life) of a Data Entity
– For example, the Order entity
• Can also be used to describe all aspects
of the system’s behaviour and anything
that has sequences of events:
– From computer programs and
– User Interface dialogues
– … to business processes
• For example, the ‘sales order’ business process
 State diagrams
• State diagrams can get very
complicated!
• So make sure your state diagrams
focus on the important or significant
changes
– Next normal event is different
– Allowable changes are very different
 ‘Sales Order’
business process/business use case
Primary actor: Customer
Goal: To get some goods they need
Scope: ATOM business
Main Sequence:
Event
1.Customer rings up with order
2.ATOM dispatches the goods Response

3.Customer signs the delivery note Event

4.ATOM sends an invoice Response
5.Customer sends back payment
Event
 Order (Business level)
• In what states can an Order be in its
life?
– An Order can be…
• What are the events that cause the
states to change?
 Order (Business level)
• The order can be: Placed, Delivered,
Paid
• The events that caused the states to
change were: place (call with) order,
sign delivery note, send payment

Place order
Sign delivery note Send payment
Placed Delivered Paid
 Order (Business level)
• Remember different states mean that
entities have different behaviour and
constraints…
• What changes should we allow to the
data of the Order entity when its in the
Placed, Delivered and Paid states?
Place order
Sign delivery note Send payment
Placed Delivered Paid
 Order (Business level)
Place order
Sign delivery note Send payment
Placed Delivered Paid

• Placed
– Order can change (data like shipping
date/address, quantity, etc) or order be
cancelled
• Delivered
– Only price data can be changed (for example,
in case of problem)
– Cannot be cancelled
• Paid
– Nothing can be changed
✓ These constraints follow the ‘business rules’ of
the company
 Let’s now add more detail by
looking at our system use cases
Actors Goals
Customer Place an order
Pay an invoice
Warehouse Get next dispatch
staff
Driver Get delivery list
Record deliveries
Accounts Send invoices

System Use Cases can be Events

Order – add events and new states
Add (some of) these Events to the State Diagram

place get delivery send

an order list invoices

get next record pay an

dispatch deliveries invoice

Placed Delivered Paid

Are any new states triggered?

Order – add events and new states

get delivery [send

list invoices]

[get next
dispatch]

place
an order

Placed Delivered Paid

record pay an
get next deliveries send invoice
dispatch invoices

Dispatched Invoiced
 Order – add constraints
State What data are allowed to change?
Cancel Quantity Price Shipping Next state
Placed ✓ ✓ ✓ ✓ Dispatched
Dispatched * *✓ ✓  Delivered, Placed
Delivered   ✓  Invoiced
Invoiced     Paid
Paid     
place
an order

Placed Delivered Paid

record pay an
get next deliveries send invoice
dispatch invoices

Dispatched Invoiced
 System design
• A description of how the system should
be made
• We use diagrams, drawings and text
• We design all aspects of the system
– Overall architecture
– Database
– Interfaces
– Programs

• Taken together they communicate the

design
(let someone else perceive a whole design)
 Previously in CS1004

• ERDs only show a static picture/the structure of the data

(or the system)
• But they don’t show how data changes over time!
– We talked about events and how they cause state changes
– these states mean different constraints for the entity!
– Let’s now talk about activities!
 Plan for today
• Understand Activities
• Continue with system design
– And create Activity Diagrams
– To model from business processes to
system UI elements
Activities & Activity Diagrams
• An activity is an ongoing process of performing some
action
– An activity is a state of doing something

• We model activities using activity diagrams

– They are a variation of state diagrams
• An activity diagram shows the ordering of
activities and the transitions between them
– Concurrent activities, responsibilities and dataflows
too!

• Unlike in state diagrams, transitions are completion of

one activity and the start of another
• Transitions are timeless
– Can take no time or forever
 Uses of Activity Diagrams
• Sequencing of a Business Use Case
• Business Work Flows & Responsibilities

• Sequencing of System Use Cases

• Sequencing of UI dialogue elements or
screens within a System Use Case

• Data Flows within the System

 Notation (UML)
• Start point
– Exactly one

• Activity
– With name Name

• Transition (or flow)

– Usually no label Note semicircle
end not rounded
• Decision point corners

• End point
 Examine the activity diagram
Consider the following activity diagram. In this system
which activity will always occur after ActivityW?
a. ActivityY
b. ActivityW
c. ActivityZ
d. ActivityX
ATOM ‘Sales’ business process
Warehouse dispatch note Driver
& goods

Sales orders

Sales office

Invoices
(accounts receivable)

Payments

Accounts office
Using an activity diagram to model
the ‘Sales’ business process

Order Items

Load Items

Deliver Items

Send Invoice

Pay Bill
 Advanced Notation (UML)
• Work/Object/Data Flow
– Replaces a transition
– Names object passed to the
Name
next activity

• Responsibilities Sales Accounts

– Who performs it Xxxx
– Name the lane containing
the relevant activities
Yyyy

• Parallel Activity
– Activity that happens at the
same time
– Path splits and rejoins
Sequence of business process
Work Flow
Order Order Items Customer

Dispatch Note Load Items Warehouse

Delivery Note Deliver Items Driver

Invoice Send Invoice Accounts

Cheque Pay Bill Customer

Responsibility
Sequence of business process
Customer Warehouse Driver Accounts

Order Items

Load Items

Deliver Items

Send Invoice

Pay Bill
 ATOM System use cases
Actors Goals
Customer Place an order
Pay an invoice
Warehouse Get next dispatch
Driver Get delivery list
Record deliveries
Accounts Send invoice

Potential IS Use Cases – and Activities

Order these Use Cases into an Activity diagram

Sequence of System use cases

Place an Order

Get next Dispatch

Get Delivery List

Record Deliveries

Send Invoice

Pay an Invoice
‘Take order’ System Use Case
Primary actor: Sales Clerk
Goal: To take a telephone order
Scope: Sales Order System
Main Sequence:
1. Sales clerk enters customer number
2. IS displays Customer data
3. Sales clerk enters item number
4. IS displays Item data
5. Sales clerk enters quantity required
6. IS calculates price & VAT
7. Sales clerk repeats steps 2 to 6 for more items
8. IS displays total & possible delivery dates
9. Sales clerk selects a delivery date
10. IS confirms order taken
System Screen Sequence
 Examine the activity diagram
• Which of the following conditions will
lead to ActivityX to being executed?
a. sw=1 and x=1
b. sw=2 and x=0
c. sw=1 and x=0
d. sw=2 and x=1
 Summary
• We discussed Activities and Activity
Diagrams
• Block 2/4 done! ☺

• Labs on Monday – No lectures!

– Group Test during lab
– Individual Test at your own time before lab –
already on Brightspace
– All Practice Tests can be attempted unlimited
times after lab