UoL CS Notes
Menu

System Models (Process Models, Data Flow & State Machines)

COMP201 Lectures

System models are abstract descriptions of systems. They explain the details of a system in a more technical way.

  • System representations maintain all the information of a system.
  • A system abstraction deliberately simplifies the system and picks the most important characteristics.

System Model Weaknesses

There are several weaknesses of system models:

  • They do not model non-functional requirements
  • They do not usually include information about whether a method is appropriate for a given problem.
  • They may produce to much documentation.
  • They are sometime too detailed and difficult to read to be useful.

Class Diagram

Here is an example of a class diagram:

classDiagram
direction LR
CourseOffering "0..*" -- "1..1" Professor: teaches
CourseOffering "0..*" -- "0..*" Student: takes
Student --|> Person: extends
Professor --|> Person: extends
class CourseOffering{
	-int sectionNo
	-Course course
	-Professor instructor
	-String schedule
	-String location
	-int maxEnrollment
	-int enrollment
	-Set prerequisites
	+CourseOffering()
	+setSectionNo() void
	+setCourse() void
	+setInstructor() void
	+setSchedule() void
	+setLocation() void
	+setMaxEnrollment() void
	+get...()
	+calcAvailable() int
}
class Student{
	-String major
	-String classStanding
	-float graph
	+setMajor() void
	+setClassStanding() void
	+computeGpa void
}
class Professor{
	-String rank
	-Date tenureDate
	-String department
	+Professor()
	+setRank() void
	+setTenureDate() void
	+getRank() String
	+getTenureDate() Date
	+getDepartment() String
}
class Person{
	#String name
	#String ssn
	#Date dob
	#Person spouse
	#Set children
	+Person()
	+setName() void
	+setSsn() void
	+setDob() void
	+setSpouse() void
	+setChildren() Set
	+getName() String
	+getSsn() String
	+getDob() Date
	+getSpouse() Person
	+getChildren() Set
	+getAge() int
}

The information in this diagram would be significantly harder to explain in natural language.

Model Types

The following models have their own respective purposes:

  • Data Processing Model - Showing how that data is processed at different stages.
  • Composition Model - Showing how entities are composed of other entities.
  • Architectural Model - Showing principle sub-systems and relationships with other systems.
  • Classification Model - Showing how entities have common characteristics.
  • Stimulus/Response Model - Showing the system’s reaction to events.
  • Context Models - Are used to illustrate the boundaries of a system.
    • Social and organisation concerns may affect the decision on where to position system boundaries.

Architectural Model of an ATM System

@startwbs
* ATM System
** Security System
** Account Database
** Usage Database
** Maintenance System
** Branch Counter System
** Branch Accounting System
@endwbs

Process Models

There are several different types of data processing models:

  • Process Models - Show the overall process and the processes that are supported by the system.
    • In process models it is implicit one process is completed before another process begins.
    • Process models are similar to flow charts.
  • Data Flow Models - Are used to show the processes and the flow of information from one process to another.
    • In data flow models it is implicit that processes will happen in parallel.

Example Process Model

This is an example of the equipment procurement process:

flowchart
1[Specify Equipment Required] -->|Equipment Spec| 2[Validate Specification] & 3[Find Suppliers]
4[(Supplier Database)] --> 3
3 -->|Supplier List| 5[Get Cost Estimates]
2 -->|Checked Spec| 5
5 -->|Spec, Suppliers & Estimate| 6[Choose Supplier]
6 -->|Order Details & Bank Order Form| 7[Place Equipment Order]
7 -->|Checked & Signed Order Form| 8[ ]
7 -->|Order Notification| 9[Accept Delivery of Equipment]
10[ ] -->|Delivery Note| 9
9 -->|Delivery Note| 11[Check Delivered Items]
11 -->|Installation Instructions| 12[Install Equipment]
12 -->|Installation Acceptance| 13[Accept Delivered Equipment]
13 -->|Equiptment Details| 14[(Equipment Database)]
subgraph System Boundary
3
4
5
6
7
9
end

Behavioural Models

These are used to describe the overall behaviour of the system. There are two types of behavioural model:

  • Data Processing Models - Show how data is processed as it moves through the system.
  • State Machine Models - Show the systems response to events.

Both of these models are required for a description of the system’s behaviour.

Data-Processing Models

Data flow diagrams are used to model the system’s data processing. These show the processing steps as data flows through a system. They should:

  • Be simple and intuitive to understand.
  • Show end-to-end processing os data.

This is part of many analysis methods.

Data flow diagrams can also used to show data exchange between a system and other systems in its environment.

Data flow diagrams show a functional perspective where each transformation represents a single function or process. This is useful for requirements analysis as it shows end-to-end processing.

Example Data Flow Diagram

This is an example of order processing:

flowchart
1[ ] -->|Order Details & Bank Order Form| 2[Complete Order Form]
2 -->|Completed Order Form| 3[Validate Order]
3 -->|Signed Order Form| 4[Record Order]
4 -->|Order Details| 5([Orders File])
4 -->|Signed Order Form| 6[Send to Supplier]
4 -->|Signed Order Form| 7[Adjust Available Budget]
6 -->|Checked and Signed Order & Order Notification| 8[ ]
7 -->|Order Amount & Account Details| 9([Budget File])
Example Data Flow Diagram (DFD) Context Diagram
flowchart LR
dmc((Drinks Machine Controller)) .->|"Heating Element (on/off)"| hws[Hot Water System]
dmc .->|"Hot Water Valve (open/close)"| hws
hws ==>|Hot Water Temperature| dmc
dmc .->|"Holding Vessel Valve (open/close)"| hv[Holding Vessel]
csm[Coin Sense Mechanism] -->|Coin Codes| dmc
dmc .->|"Stirrer (on/off)"| s[Stirrer]
dmc -->|Service Request| Modem
dmc -->|Pricing, Availability and Service Information| ad[Alphanumeric Display]
dmc .->|"Cup Solenoid (on/off)"| pcm[Paper Cup Mechanism]
pcm .->|Cup in Place| dmc
nkp[Numeric Key Pad] -->|Key Codes & Drink Choice| dmc
dih[Dried Ingredients Hopper] .->|Hopper Low Signal| dmc
dmc .->|"Hopper (on/off)"| dih

The hot water temperature (in bold) is a continuous input. It should have a double arrowhead but I can’t do that.

  • Solid lines are information flows.
  • Dotted lines are control flows.
  • Double arrow heads are continuous data.
  • Single arrow heads are discrete data.
Level 0 DFD

This is the top level that represents all the systems in the machine:

flowchart
1[ ] ==>|Hot Water Temperature| tc((Temperature Control)) 
tc .->|"Hot Water Element (on/off)"| 2[ ]
3[ ] .->|"Service Door (open/closed)"| oc((Operation Control))
cm[Coin Mechanism] -->|Coin Codes| oc
mdc((Make Drinks Control)) .->|Drink Made Status| oc
5[ ] .->|Cup in Place?| mdc
dr[(Drink Recipes)] -->|Recipe Data| mdc
oc -->|Drink Code| mdc
mdc .->|"Cup Solenoid (on/off)"| 4[ ]

mdc .->|"Hopper Motors (on/off)"| 6[ ]
mdc .->|"Hot Water Valve (on/off)"| 7[ ]

mdc .->|Holding Vessel Control| 8[ ]
mdc -->|Drink Sales Data| sl[(Sales Log)]
sl -->|Sales Data| mmc((Maintenance Mode Control))
oc .->|"(on/off)"| mmc
oc --> |Engineering Codes| mmc
kp[Key Pad] -->|Key Codes| oc
sl -->|Sales Data| csr
Hoppers .->|Hopper Low?| oc & csr((Control Service Request))
oc -->|Price & Availability| ad[Alpha Display]
csr -->|Service Data| Modem
Level 1 DFD - Operation Control

A level 1 DFD explores a discrete system from the level 0 DFD:

flowchart
1[ ] .->|"Service Door (closed/open)"| cmm((Control Maintenance Mode))
kp[Key Pad] -->|Key Codes| pkc((Process Key Codes))
cm[Coin Mechanism] -->|Coin Codes| cmr((Coin Mechanism Reader))
pkc .->|Password Received| cmm
pkc -->|Echo Key Codes| ad[Alpha Display]
pkc -->|Drink Code| dac
dac -->|Product Information & Availability| ad
dac -->|Available Drink Code| ddc((Drink Dispense Control))
ddc -->|Prompt for Payment| ad
cmr -->|Credit Update| cs[(Credit Store)]
cs -->|Current Credit| cmr
cs -->|Current Credit| ddc
Hoppers .->|Hopper Low?| dac((Drink Availability Checker))
dr[(Drink Recipes)] -->|Drink Data| dac
cmm .->|"Maintenance Mode (enable/disable)"| 3[ ]
ddc -->|Paid For Drink Code| dq[(Drink Queue)]
dq -->|Paid For Drink Code| 5[ ]
pkc -->|Engineering Codes| 2[ ]

State Machine Models

State machine models, also called state chart diagrams, show the behaviour of the system in response to external and internal events.

  • State-charts allows the decomposition of a model into sub-models.
  • A brief description of the action is required. (Do is optional).
  • Can be complemented by table describing the states and stimuli.

There are some additional hints for state machines:

  • All states need an exit.
  • Use an Idle state to show when the process isn’t active.
  • You don’t need to have a state chart as a sub-state of another state chart.
    • The system can be described by multiple state machines running concurrently.
  • Use multiple state charts to keep the design simple.
Example State Machine Model
stateDiagram-v2
state "do: Display Time" as w
state "do: Set power = 600" as fp
state "do: Set power = 300" as hp
state "do: get number, exit: set time" as st
state "do: Display 'Waiting'" as d
state "do: Display 'Ready'" as e
state "do: Operate Oven" as o
[*] --> w
w --> fp:Full Power
w --> hp:Half Power
fp --> hp:Half Power
hp --> fp:Full Power
fp --> st:Timer
hp --> st:Timer
st --> st:Number
st --> d:Door Open
st --> e:Door Closed
d --> e:Door Closed
e --> o:Start
o --> d:Door Open
o --> w:Cancel, Done

A state machine model does not show flow of data within the system.

This state graph has the associated stimuli table:

Stimulus Description
Half Power The user has pressed the half power button.
Full Power The use has pressed the full power button.
Timer The user has pressed one of the timer buttons.
Number Ther user has pressed a numeric key.
Door Open The oven door switch is not close.
Door Closed The oven door switch is closed.
Start The user has pressed the start button.
Cancel The user has pressed the cancel button.
State Diagram with Composite States

This diagram makes use of a couple of additional features:

  • Guard - On the arrows. Ensures that the system only moves from one state to the other if the expression is satisfied.
    • This can be a method as shown on this example.
  • Composite Sates - This is a state sub-diagram that models the states of a state.
stateDiagram-v2
ErrorState: printError()
SubsystemChecking: performCheck()
ErrorFound: printError()
state Running {
	[*] --> SystemOff
	SystemOff --> SystemOn: initiate() [canStart]
	SystemOff --> ErrorState: initate() [cannotStart]
	ErrorState --> [*]
}
state Maintenance {
	SubsystemChecking --> ErrorFound: errorReturned()
}
Running --> Maintenance: checkSystem() [notRunning]
Maintenance --> Running: printCheckReport()
Actions

You can put actions after the event using a /:

stateDiagram-v2
direction LR
OutOfInk --> Idle: Ink Available/Clear Display 
Idle --> OutOfInk: Ink Low/Show Error Message

Finite State Machines

Refer to notes on Deterministic Finite Automata (DFAs) for information about finite state machines.