1

Modeldrevet softwareudvikling – 16. november 2004

Design Methods for Reactive Systems, R.J. WieringaPart IV: Software Specification Methods

Jens Bæk Jørgensen, Aarhus Universitet

2

Postmodern structured analysis – notations

Environment Context diagram ERD of subject domain Event-action lists of desired subject domain behaviour Event-action lists of assumed subject domain behaviour

Requirements Mission statement Function refinement tree Service descriptions Stimulus-response list of desired system behaviour

SuD decomposition DFD SuD decomposition STTs or STDs of control processes

Dictionary

3

Postmodern structured analysis – coherence rules

Environment models Context diagram shows relevant communication paths between SuD

and subject domain Event-action pairs refer to subject domain entities involved

Requirement specifications Mission statement = root of function refinement tree Service descriptions = leaves of function refinement tree Each function is triggered by stimulus in stimulus-response list Each stimulus-response pair is part of a function

SuD decomposition specifications Each control process is specified by a behavior description Each behavior description describes a process in the DFD

4

Postmodern structured analysis – coherence example

Statechart behaviourdescription

Part of DFD (control process)

5

Postmodern structured analysis – coherence across models

Environment and requirements Event -> stimulus -> response -> action Each of these chains is a path in the context diagram

Requirements and SuD decomposition For each stimulus-response pair, there is a path through

the DFDSuD decomposition and environment.

Context diagram is abstraction from DFDDictionary

Defines at least the relevant subject domain terms for entities and events

6

UML (Unified Modeling Language) – basics

Attempted unification of notations for object-oriented software design

Booch, Rumbaugh, Jacobson 1997 Industrial standard defined by the OMGStandard is still being updated; UML 2.0 coming

soonWieringa treats only a light-weight version, expected

to be consistent with future versions

7

UML – notations

Use case diagramsActivity diagramsStatic structure diagramsStatechartsSequence diagramsCollaboration diagramsComponent diagramsDeployment diagrams

8

UML – activity diagrams

Used to describe workflowsDiagram constructs to represent

Wait states and activity states Sequence Hierarchy Parallelism Choice

9

UML – activity diagram example

10

UML – static structure diagrams (SSDs)

Also known as class diagrams SSDs have notable similarities with ERDs, but usage and

terminology are different An SSD shows which classes of objects can exist in the

software system, and how many of them can exist Attributes represent the observable state of an object Services can be operations or signal receptions

Operation = computation performed by object Signal = named data structure that can be sent as a message to

objects

Associations are access paths

11

UML – SSD for heating controller

12

UML – ERD for heating controller (to compare with SSD)

13

UML – statechart for heating controller

14

UML – coherence between SSD and statechart for heating controller

15

UML – guidelines for finding an SSD

Start from Context diagram Subject domain ERD Communication diagram of requirements-level architecture

The SDD adds additional information to the communication diagram about object identification and access

16

UML – SDD guidelines; elevator controller communication diagram

17

UML – SDD guidelines; elevator controller SSD

18

UML – sequence diagram example

Collaboration diagrams are an alternative

19

Not Yet Another Method (NYAM) – notations

20

Not Yet Another Method – possible use of specification techniques

21

Not Yet Another Method – flyweight to heavyweight use of notations

22

Not Yet Another Method – ordering of design decisions

23

Not Yet Another Method – engineering arguments

Predict properties of a product before it is builtFeed-forward versus feedback loop Possible ways to argue

Engineering knowledge / experience Throw-away prototyping Model execution Model checking Theorem-proving

24

Not Yet Another Method – formality and precision

A description is precise if it expresses as briefly as possible what is intended

It is formal if it uses a language for which formal, meaning-preserving manipulation rules have been defined

Formal descriptions can be very imprecise: Statechart with superfluous transitions and states

Precise descriptions can be very informal: Function descriptions

The attempt to be precise has priority over the attempt to be formal

25

Summary

Postmodern structured analysisUMLNot Yet Another Method