Winter exam

• https://examtimetable.brunel.ac.uk/
• Tuesday, 12 December
• 9:30-10:30am
– Be there at 9am
• On campus
• Bring your laptop
– On Wiseflow
– Charged
– Brunel wifi
CS1004 INFORMATION SYSTEMS &
ORGANISATIONS
LECTURE 13
STATES
 Previously in CS1004
Client

Use Cases
Analysis

ERDs
Design

Implementation

Validation

System
Maintenance
 Previously in CS1004
• Design the structure of the data
(database design)
– Explore what data needs to be stored
and how it will be stored
– Identify entities, their attributes and
relationships
 Plan for today
• Look at the ‘lifecycles’ of data entities
in business processes
• Understand Events
• Continue with system design
– And Create State Diagrams
 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)
 System design – what ERDs tell
us and what they don’t!

• ERDs only show a static picture (the structure) of

the data
• But they don’t show how data changes over time!
• We need another technique
• Let’s talk about events and states!
 Events cause Entities to change
State
• Identify the entity, its different states, and the events
that caused it to change states.

• Entity: Cup
• States: Full, Empty
• Events: Drink tea, Pour tea

• Entity: Door
• States: Closed, Open
• Events: Open, Close
 Events
• Something that happens in the
environment
• Events cause entities to change state
– In other words, an event causes a
transition from one state to another

• Need a response from the “system”

OR
• Need to be recorded by the “system”
OR
• Both
 ‘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
 States
• A recognisable period in the life of an
object (entity, system, etc).

• Different states mean:

– Different capabilities
– Different constraints
– Different characteristics

• The object will stay in a state until it is

triggered by an event to change state
State Diagram Notation (UML)
• Start point
– Exactly one

• State
State
– With name

• Transition
event
– With event

• End point
 States in an entity’s life ☺

Single Married Widowed

• What are the events and transitions?

 Examine the State Diagram
below:
• Which state is the system in after the
sequence of events: event1, event3,
event2?

1. StateD
2. StateA
3. StateB
4. StateC
 Examine the State Diagram
below:
• Which state is the system
Guard or in after Transition
Guarded the
sequence of events: event1,
[boolean event3,
expression] if it’s true,
event2? transition is allowed

1. StateD
2.Transient
StateAState or Pseudostate
3.NoStateB
name. Lasts 0 time
4. StateC
 Examine the State Diagram
below:
• Which state is the system in after the
sequence of events: event2, event3,
event2, with the var i equal to -2.

1. StateD
2. StateA
3. StateB
4. StateC
State diagram of system user

x
Not logged in logged in
[a]
[b]

• What are the events x, y that cause the state

changes?
• What are the guards [a] and [b]?
 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 staff Get next dispatch
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
Your state diagram?

go to class

[class
not over]

[class over]
 Summary
• We discussed events that change the
state of a data entity and how to model
that.

• Next lecture (Friday)

– We will look at ‘Activities’ & Activity Diagrams
– Friday is the last lecture of BLOCK 2
– We will talk about the exam
– Labs (Practice tests) on Monday