SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 1 Software engineering for real-time systems Section

SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 1

Software engineering for real-time systems

Section 9

Diagramming and design notations


Objectives

To show:

The general role of diagrams as a design and modelling tool/language.

The diagrams used for structured/data flow and object-oriented design techniques.

The general syntax and semantics of commonly-used notations (specifically Yourdon and the Unified Modelling Language (UML).

Why extensions and modifications of basic diagram types are needed in certain real-time applications

Objectives


Part 1

The importance of diagrams

The importance of diagrams


Why usediagrams

As aMAINTENANCE

tool

As a DESIGNtool

As aDOCUMENTATION

technique

As aCOMMUNICATION

Medium

• Diagrams can be put to good use in four main areas.

The role of diagrams in software development


• Diagrams “model” reality.

• They “abstract” reality from a particular domain to a model.

• BUT - the model has to be the right one for the domain.

• Fig.(a): Vehicle electrical system - maintenance domain.

• Fig (b): Vehicle electrical system - design domain

Domain-specific views

Fusebox

Generator

Fuel pump

Battery

Generator

Battery

Fusebox

Fuel pumpsystem

Stereo system

Stereosystem

(b)

(a)


High-level and low-level views


Thinks

As a design tool

• Producing a diagram requires an explicit action.

• Diagrams can’t “lie”. Implicit relationships cannot exist.

• There needs a clear understanding of the problem in order to express things graphically (in pictures).

Diagrams for design - Initial design


• To be effective diagrams must have an agreed set of rules - syntax (notation) and semantics (meaning).

• This introduces formality and rigour.

• It eliminates ambiguity and ambivalence.

• It facilitates peer review and assessment.

Diagrams for design - meaning and notation


Good, clear diagrams:

• Allow the design as a whole - and the component parts - to be reviewed and analysed.

• Highlight incorrect or illogical design feature.

• Enable errors to be corrected at an early stage.

Diagrams and design reviews


Diagram grouping

High-level view

WHAT are we doing?

Task oriented

Low-level view

HOW are we doing it

Solution oriented

Objective

Emphasis

Result

High-level diagrams:

• Show overall structure.

• Describe overall functioning.

• Show the interaction of the system with its environment.

• Describe the function and interactions of the sub-systems.

Low-level diagrams:

• Show detail.

• Emphasize internal information.

Diagrams for documentation


• The essential features of design documents.

• Extremely important in the post-design phase.

• Best done as an integral part of the design process.

Document requirements


Diagrams for communication

Used by

Designer

Designer

User Maintainer

4

12

3

Dialogue Main use

3

1

2

4

During tendering, design and systemacceptance.

During the design phase

On completion of design

Post-design service phase

• Different people use diagrams.

• Different people have differing needs. Diagrams are produced and used at various points in the project (or product) lifetime.

• “Pictures” enhance communication by eliminating ambiguity and ambivalence.

Diagrams for communication of information


• Diagrams bridge the gap between what is wanted and what is provided.

"control a Robot m odel"

Design diagram s

The software bridge

Problem

Solution

Lines of code

Why use diagrams when developing software systems?

Diagramming and software development


S P E C IF IC A TIO N(or, w ha t has to be

done)D iag ram s

P rob lemtransla tion

P rogramproduction

R E S U LTP rogram code

In te llectua lactiv ity

In te llectua lactiv ity

Specification to code - a two-stage process

Designing and modelling Implementing


S ystem con text

S ystem con figu ra tion

S ystem a rch itectu re

S ystem requ irem en ts/specif ica tions

System and softwaredesign

B lock d iag ram s

C ontro l systemd iag ram s

S O R

S ystem view po in tand use case

d iag ram s

S ystem usage

S ystem so ftw arestructu re

S ystem and so ftw arebehaviour

S o ftw are d istribu tion

Overall diagram set for real-time systems


Part 2

Diagrams for structured

anddata flow designs

Structured and data flow design


The systemsoftware

Externalitem 1

Externalitem 2

Externalitem 3

Externalitem 4

Data 1 in Data 3 out

Data 2 in Data 4 out(a) Basic context diagram

Anti-skidbrakingsystem

Speed sensor 1

Speed sensor 2

Tyre pressure 1

Tyre pressure 2

Valve 1

Valve 2

Vehicle dashdisplay

Wheel 1 speedWheel 2 speed

Tyre 1 pressure

Tyre 2 pressure

Valve 1 signal

Valve 2 signal

Display data

(b) Exam ple context diagram

Context diagram


C o ntro lpa ne l

C o ntro lle r M o to r

P o s itio ns e ns o r

F light de c kte mpe ra ture

s e ns o r

C o ntro lda ta

C o ntro ls igna ls

C o c kpitte mp.

M o nito rings igna ls

S ha ftpo s itio n

R e la tio ns hip E ntityD ia g ra m s ym b o ls

Entity relationship diagram


State transition diagram (part)

State1

State2

Event 1

Response 1

Event 2

Response 2

(a) Basic state transition diagram

Readyto

start

Startin progress

Start button pressedEnergize starter relay

(b) Example state transition diagram


Sonarechoreturn

Processsonarsignal

Evaluatethreat

Performspectralanalysis

Processedsonarsignal

Sonarspectral

dataThreatdata

(b) S im ple DFD exam ple

DT1

DT2

DT3

DT4

DT5

Data 1 in

Data 2 in

Data X

Data Y

Data Z

Data A

Data B

Data 3 out

Data 4 out

(a) DFD - general form

Basic data flow diagram


DT 1

DT 3

CT 1

E/D

E/D

E/D

Data transform ation enable/disable com m ands

Controltransform ation

DT 2

Loop: Enable DT1 W ait T im e T1 D isable DT1

Enable DT2 W ait T im e T2 D isable DT2

Enable DT3 W ait T im e 3 D isable DT3 End Loop

RunDT1

RunDT2

RunDT3Control

transform ationspecification

Combining data and control transformations


Set

motor

m ode

Manual

Auto

C ontro l

m otor

s peed

Speedd em and

Actualspeed

Set s peed

E/D

M anual Selected

Disable DT'Control

motor s peed'

Manual

mode

Auto

mode

Disable DT'Control

motor speed'

Auto Selected

Enable DT'Control

motor speed'

Reacting to external events


Processing

Processing

Processing

Processing

M essage arrivaland detection

M essage arrivaland detection

SendAcknowledgem ent

SendM essage

Processing

Task 1 Task 2TIM ET0

T 1

T 2

T3

T 4

Message sequence diagram


Run gas turbine control system(fuel control section)

Measureengine

param eters

Com puterequiredfuelling

Calculate fuelschedules

Com pute and sendout actual fuel

com m and

Com parerequired engine

fuelling withschedules

Set fuel outputon result ofcom parison

Do either Aor B

ReadPr,N 1,P 3 andFa 10 tim es

AOutput calculated

fuel com m and

Boutput fuel

schedule lim it

Top level

2nd level

3rd level

4th level

Branch

root

node

Top-to-bottom decomposition - basic structure


Alpha

x y zw

Alpha

x y zw

Execution: w,x,y,z Execution: w or x or y or zExecution: repeat z

n tim es (including zero,no operation)

Sequence IterationSelection

A lpha *

z

Jackson structure charts - basic constructs



Measureengine

param eters

Com puterequiredfuelling

Com putefuel

schedules

Com pute andsend out actual

output fuelcom m and

Com pare requiredengine fuellingwith schedules

Set fuel output onresult of

com parison

If fuelling is withinschedule then

output calculatedfuel com m and

Else output fuelschedule lim it

Read-in 10tim es

*

o oGetP r

GetN 1

GetP 3

GetF a

Sequence

Decom position

Jackson structure chart - gas turbine example


A

CB

Pressure

Fuelflow

Speed

Norm al

Modules

Data couple

Control couple

Yourdon structure chart - basic layout and components


Set fuel output

Outputcalculated fuel

com m and

Output fuelschedule lim it

Measure engineparam eters

A

B C

D E

DoFFT

SELECTION ITERATIO N

Com m on m odules

Librarym odules

Yourdon structure chart - additional components



Measureengine

parameters

Compute fuelschedules

Compute andsend out actual

output fuelcommand

Computerequiredfuelling

Get Pr

Get N1

Get P3

Get Fa Compare required

engine fuellingwith schedules

Set fuel output onresult of

comparison

Outputcalculated fuel

command

Output fuelschedule limit

Pr

N1P3

Fa

P3 Fa

Low lim

it (LL

)

High lim

it (HL)

LL HL Fr

Fc

N1

Pr N1 P3Fa

HL LL Fr L HHL LL

Fr

Fc LL HL

Nr

Yourdon structure chart - gas turbine example


Run gas turbine control system (fuel control section) SEQUENCE Outer Measure engine parameters ITERATION Alpha REPEAT 10 times Get Pr Get N1 Get P3 Get Fa END ITERATION Alpha Compute required fuelling Calculate fuel schedules Compute and send out actual output fuel command SEQUENCE Beta Compare required engine fuelling with schedules Set fuel output on results of comparison SELECTION Gamma IF fuelling is within schedule THEN Output calculated fuel command ELSE Output fuel schedule limit END IF END SELECTION Gamma END SEQUENCE Beta END SEQUENCE Outer

Structured text example


S ta rt s ta te Input (s igna l)S ta te O utput (s igna l)

D e c is io nc o ns truc t

Ta s k(pro c e s s ing)

S 1

SDL diagrams - telecommunications industriesSDL diagrams - telecommunications industries

• A diagramming method widely used in the telecommunications industry.

• Shows both state and processing information.

SDL diagram constructs

SDL process diagram constructs


ProcessA

T 0

T 2

T 1

State 1

State 3

State 2

State 1

S ignal A 1

Signal B 1

Signal A 2

Signal B 2

Signal A 3

Signal B 3

Tim e

ProcessB

(a) Message sequence chart

S tate 1

State 2

State 3

A 1/B 1

A 2/B 2

A 3/B 3

(b) STD for system B

Modelling the behaviour of interacting processes - sequence and state diagrams


State 2

State 2

State 3

State 3

State 1

State 1

A 1

Processing 1

B 1

A 2

B 2

Processing 2

Processing 3

A 3

?

Processing 4 Processing 5

B 3

SDL process diagrams for process B


Source Input event Processing Output response DestinationCruise selectswitch

Cruise controlSet on

Control vehiclespeed

Modulate fuelsettings

Enginemanagementunit

Specimen event-response list


Part 3

UML diagrams for object-oriented

designs

Outline of UML diagrams


Navigator

Pilot

Nav/Was system Air data system

Get NavigationWaypoints

Set AirfieldAltitude

Navigator

Pilot

(a) (b)

Each system is drawn as a rectangular box.

The relevant use cases are shown as ellipses inside them.

Outside the system boundary are the actors.

These are connected to (‘associated with’) the use cases using by drawing lines between them.

Detailing requirements - use case diagrams (recap)


Set airfieldaltitude

Set autopilotmode

Validatedata range

<<Include>>

<<Include>>

Check alarmstatus

Maintaingeneratingsystems

Set alarmlimits

<<Extend>>

<<Extend>>

The distinction between includes and extends.

Include use cases collect in one place behaviour which is : Either called on a number of times within one use case

and/or Is common to a number of base use cases (fig. (a)).

Extend use cases show variations on a theme (fig. (b)).

(b)(a)

The include and extend relationships


UML Deployment diagram

Lift node 1 Lift node 2

Landing node1

Radiocommsnetwork

Landing node2

Landing node4

Landing node3

Landing network

Lift network

Deployment diagrams are used to model the physical aspects of systems.

A deployment diagram is a “graph of nodes connected by communication associations”.

A node is a “run - time physical object that represents a processing resource”.

Node


• A package is nothing more than a holder for other items (e.g. objects, classes, other packages, etc.).

• The symbol is a “tabbed” rectangle.

• Its name is written either within the main area or the tab.

Pressurecontroller

Tem peraturecontroller

A larm andprotection

Oxygen plant

(b) Package containing packages

Oxygen plant

(a) Packagesym bol

The UML package diagram


• The dependency relationship shows that packages “welding controller” and “cutting sequencer” somehow depend on the package “system operating parameters”.

• It indicates that changes made within “system operating parameters” may have consequential effects on the other packages.

System operatingparam eters

Cuttingsequencer

W eldingcontroller

Dependencies

"C lient"packages

"Target"package

Package dependencies


In software terms:

• The class symbol translates to a source code declaration.

• It defines the form, content and behaviour of objects.

• Attributes become data items.

• Operations are implemented by subprograms.

SpeedSensor

WheelSpeed

SendWheelSpeed

Name of class

Attribute

Operation

UML class notation


System Manager

W heelSpeedsServoPositions

SetServoPosition

ServoPosition

ServoUnitAssociations

4

4

m anages

m anages

W heelSpeed

SpeedSensor

SendW heelSpeed

1

1

Example class diagram


Sensor

Laser Gyro

Speed

Digital E -M GyroAnalogue

AttitudeHeight

Superclass

Sub-subclasses

Subclasses

Class structuring and inheritance - subclasses and superclasses


H ardw aredes ign ers

P rojectm an ager

S of tw aredes ign ers

A project teamcons is ts of

C om pany project team struc tu res

S oftw are des igner

H ardw are des igner

P roject m anager

U M L m odel of the projec t team s truc tu res

P roject team

Structural modelsInformal

UML model - class diagram

• In UML the has-a relationship is called ‘aggregation’.

•The diamond symbol is used to denote aggregation.

•Thus a software designer object is part of a project team object.

Describing structures - aggregation


Objects and their collaborations - collaboration diagrams

2: Start

3: Stop

BeltController ConveyorBelt

Location

Startstop

1 2

(a) Class diagram - conveyor belt system

(b) Corresponding object diagram

HallControlller : BeltController

InputConveyorBelt : ConveyorBelt

OutputConveyorBelt : ConveyorBelt

Links

HallControlller : BeltController

InputConveyorBelt : ConveyorBelt

OutputConveyorBelt : ConveyorBelt

(c) Object collaboration diagram

1: Start4: Stop


• Setting the scene for UML work.

• Statecharts are based on the Mealy machine.

• “Conditions” denote values which may be modelled as being either true or false.

• Semantics: “IF” event E occurs AND condition G is true at that time THEN:

- action A is produced and

- the system changes state

Sta te 1

Sta te 2

Transition

E vent

C ond itio n(guard )

E [G ] / A

A ction

In itia ls ta te

Describing dynamic behaviour - the statechart (basic notation)


• Substates - a form of stepwise refinement in state diagrams.

• Helps to reduce diagram complexity.

• Without this we would have a six-state diagram.

Standby

Starting

Running

Top-level

state diagram Starting

Substate diagram

Checkinginterlocks

Priming fuelsystem

Accelerating toidle speed

Igniting fuel

Refinement and substates


• The issue: here we have a pump unit which is made up of separate parts

- but on the outside it is seen as a single unit.

• How do we model both the dynamics of the complete unit (a composite of parts) and

those of the individual parts?

• Two state models are needed, one for the composite and the other for its component parts.

Modelling composite unitsModelling composite units

Collaboration and state diagrams for a composite unit

On

Fuel

OffPurgemode

Injectmode

Controller

OnOffFuel

Object collaboration diagram

Thecomposite

unit

Pumpunit


• Here we model the component parts.

• Observe that these operate concurrently.

• But taken together they implement the behaviour of the overall (composite) unit.

IPNfeed

Isolate

Airfeed

Stopped

Running

Fuel/air valve IPN pump

On

Fuel

OffOnOff

Concurrent states


Ready toWeigh

Load on bridge (weight)Computing

Cost

Event Attribute

(b) Event-Attribute notation

Initialstate

State A

Event X [Guard G]/Action Y State B

State BEvent X

Outcome

(a) Basic UML Notation

(ii)

(iii)

(i)

Start/Illuminate 'Start in Progress' LampStandby

Running

entry / OpenFuelValve

Action(c) Action on entry to a state

do / MaintainSpeed

Running

Activity

(d) Activity within a state

Running

exit / ShutFuelValve Action

(a) Action on exit from a state

State A State BEvent X

Event Y / Action Z

Running

Increase SP / ShutFuelValve

ActionEvent name

(e) Internal action

(g) Self-transition

UML notation for statecharts (1)


UML notation for statecharts (2)

Substate A2

Event Z

Superstate A

Event X Event Y

Event W

Substate A1

(b) Substates and superstates - state generalization

State A State BEvent X

Event Y

(a) Sending an event to another object

Object 1

Object 2

Substate A2

Substate A1

Substate B2

Substate B1

Superstate Alpha

Event X

Event Y

(c) Concurrent states

State A

(d) States with history

Superstate Beta

Substate B2

Substate B1

HEvent X

Event Y


Object 1 Object 2Tim e

T 0

T 2

T 1

T 3

T 4

Processing

Sendm essage

Processing

Message arrivaland detection

Processing

Processing

Message arrivaland detection

Sendacknowledgem ent

Processing

Sequence diagram showing object interactions


Tim e elapses during m essaging

Nested flow of control

P rocedure return (optional)

T 0

T 1

Flat flow of control

Message notation


• An object is shown as a vertical dashed line (“lifeline”).

• The lifeline shows when the object exists.

• For a permanent or “static” object it goes from the top to the bottom of the page.

• For a “transient” object it starts when the object is created and finishes when (if) the object is destroyed.

• An object symbol is drawn at the head of the lifeline.

• Focus of control: when an object is performing an action. This is also called an activation.

• It is denoted by a tall, thin rectangle.

O bject 1 O bject 2

L ifeline forobject 1

L ifeline forobject 2

F ocusof

con trol

U M L sequence diagram s and focusof con trol

UML Sequence diagrams and focus of control


• Both objects can run simultaneously (concurrently).

• They are assumed to exist for the duration of the program.

• All communication is via message passing.

• It can be deduced that the first two messages must be asynchronous ones.

• The “OpenHatch” message must be a synchronous one.

• This ‘OpenHatch message depicts the use of a remote procedure call from object 1 to object 2.

Object 1 Object 2

StartMeasurem ents

StoreData

E levateMissile

PrepareForRun

OpenHatch

UML Sequence diagram - concurrent operations


• This introduces the “procedural” sequence diagram.

• Here a focus of control is when “an object is performing an action either directly or through a subordinate procedure”.

• In sequential programs one, and only one, object can be active at any one time.

• Thus all calls MUST be synchronous ones.

• NOTE: Procedure returns do not have to be shown; they can be IMPLICIT.

O bject 1 O b ject 2 O b ject 3

C om puteS peed

C om puteP osition

D oC oord ina teC onvers ion

UML Sequence diagram - procedural (sequential) operation


Action state

[Guard condition]

End stateStart state

Engage clutch

Action

Decision Merge

S ignal send S ignal receiptFork Join

Synchronizingstate

• ‘An activity diagram is a variation of a state machine’ (UML definition).

• ‘It represents the state machine of a procedure itself’ (UML definition).

• ‘The purpose of this diagram is to focus on flows driven by internal processing’ (UMLspeak writ large).

• The states represent processing operations.

• Transitions are triggered by completion of the processing.

UML Activity diagram constructs


Tim er expired

Stopm otor

Initializesystem

Read sensordata

Check status

Activate alarm

Updatedisplay

Read sensordata

Do spectralanalysis

Do systemidentification

Com putecontrol s ignal

Output signalto actuator

[In alarm ] [Norm al]

(b) Concurrent and sequential actions

(a) Sequential actions only

Example activity diagrams


Na me o fc o mpo ne nt

P ID c o ntro lle r

P ID c o ntro lle r

C o ntro l la wa lgo rithms

Anti-a lia s filte r

C o mpo ne nt

D e pe nde nc y

Inte rfa c e

(a ) C o mpo ne nt s y mbo l(b) C o mpo ne ntde pe nde nc ie s

(c ) C o mpo ne nt de pe nde nc ie sv ia inte rfa c e

UML component diagram

Software components

Source code components

Binary code components

Executable components

UML definition: ‘components are distributable items’.


Part 4

Extensions, variations and

project-specific diagrams

Non-standard diagrams


M O T O R

O N c o i lT r i p c o i lT r i p c o n t a c tO n / O ff c o n t a c t

L O A D E R

N o . 1 ( 5 0 % )N o . 2 ( 7 5 % )N o . 3 ( 1 0 0 % )

C H I L L E RV A L V E S

N o . 1N o . 2

S e r ia l d a t a l i n k

H a r d w i r e d

TEMPERATURESENSOR

Rem ote controlstation

L CC W C o n t r o l l e r

S u c t i o n p r e s s u r eD i s c h a r g e p r e s s u r eC W p r e s s u r eC W t e m p e r a t u r eO il p r e s s u r e

P L A N T

System configuration diagram


Machineryunit 1

Lift 1node

Userinterface 1

Lift 2node

Machineryunit 2

Userinterface 2

Radiocom m s

node

Rem otesystem

Lift netw ork

Landing 1 doorLanding1 node

Landing 1 UI

Landing3 node

Groundfloornode

Landing2 node

Landing netw ork

Car 1 node

Car 1network

Car 1UI

Car 1door

Car 2 node

Car 2network

Car 2UI

Car 2door

Landing 2 door

Landing 2 UI

Ground floor door

Ground floor U I

Landing 3 door

Landing 3 UI

System architecture diagram


System Software

Gas Inlet Valve

Gas Outlet Valve

R em ote

In d ica tion

P an el

Com pressor

Com pressor

Vent Valve

Com pressor

By-pass valve

P lant I/O

TankHP Local Operator

System Boundary

Loca l

In d ica tion

P an el

Production

System

Rem ote Operator

System scope diagram


Dispatchand controlprocessor

DigitalI/O

Networkinterface

processor

MMIinterface

Machineryunit

Liftnetwork

Landingnetwork

User interface

Keypad

LCD panel

RS422 Serialcom m s

interface Car network

Lift node

Node architecture diagram


M otor c ontactorON /O FF s w itch

P lant s ensors w itches

Start s w itch

C ontactor c o il

C ontactor t ripc oil

A larm c ancels w itch

Analogued ata

a cqu isitionb oard

Sw itchinputb oard

C ontactorc ontro lb oard

CPUb oard

Seria lc om m s

Sw itcho utputb oard

Powers w itchb oard

R C

M astera larm

Indiv iduala larm s

Stateindicators

M otor c ontactort rip s w itch

Loaderv alves

C hille rva lves

RS422Data Link

CONTROLLER

W atertem perature

s ensor

Processor architecture diagram


Tasking diagram

AlarmMonitoring

Task (AMT)

CompressorController

Task (CCT)

Display andCommunications

Task (DCT)

TimerTask (TT)

flag

flag

mailbox

channel

flag

flag

flag

channel

flag flag flag

inhibit LCFR

inhibit HOGP

inhibit LIGP

30s elapsed

40s elapsed

stop

start

180s elapsed

Real-worldTrips

Real-worldDevices

Networks


Memory map diagram


Review of section

You should now:

Appreciate that diagrams are an important part of the software design process.

Understand why, in practice, a range of diagrams is required.

Know what basic modelling features (e.g. system dynamics, messaging, structure, etc.) needto be supported by diagrams.

Have knowledge of the diagrams used when designing using both structured and OOmethods.

Be able to select the diagram set which best meet your own needs.

Realize that these, in many cases, are not sufficient; extensions or additions may be needed.

Realize that there isn’t a uniquely ‘right’ diagramming method.

END OF SECTION ‘Practical diagramming methods’

Review of ‘Diagramming and design notation’

Documents

SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 1 Software engineering for real-time systems Section