1 Modeldrevet softwareudvikling – 16. november 2004 Design Methods for Reactive Systems, R.J. Wieringa Part IV: Software Specification Methods Jens Bæk Jørgensen, Aarhus Universitet

2 Postmodern structured analysis – notations zEnvironment yContext diagram yERD of subject domain yEvent-action lists of desired subject domain behaviour yEvent-action lists of assumed subject domain behaviour zRequirements yMission statement yFunction refinement tree yService descriptions yStimulus-response list of desired system behaviour zSuD decomposition yDFD SuD decomposition ySTTs or STDs of control processes zDictionary

3 Postmodern structured analysis – coherence rules zEnvironment models yContext diagram shows relevant communication paths between SuD and subject domain yEvent-action pairs refer to subject domain entities involved zRequirement specifications yMission statement = root of function refinement tree yService descriptions = leaves of function refinement tree yEach function is triggered by stimulus in stimulus-response list yEach stimulus-response pair is part of a function z SuD decomposition specifications yEach control process is specified by a behavior description yEach behavior description describes a process in the DFD

4 Postmodern structured analysis – coherence example Statechart behaviour description Part of DFD (control process)

5 Postmodern structured analysis – coherence across models zEnvironment and requirements yEvent -> stimulus -> response -> action yEach of these chains is a path in the context diagram zRequirements and SuD decomposition yFor each stimulus-response pair, there is a path through the DFD zSuD decomposition and environment. yContext diagram is abstraction from DFD zDictionary yDefines at least the relevant subject domain terms for entities and events

6 UML (Unified Modeling Language) – basics zAttempted unification of notations for object-oriented software design zBooch, Rumbaugh, Jacobson 1997 zIndustrial standard defined by the OMG zStandard is still being updated; UML 2.0 coming soon zWieringa treats only a light-weight version, expected to be consistent with future versions

7 UML – notations zUse case diagrams zActivity diagrams zStatic structure diagrams zStatecharts zSequence diagrams zCollaboration diagrams zComponent diagrams zDeployment diagrams

8 UML – activity diagrams zUsed to describe workflows zDiagram constructs to represent yWait states and activity states ySequence yHierarchy yParallelism yChoice

9 UML – activity diagram example

10 UML – static structure diagrams (SSDs) zAlso known as class diagrams zSSDs have notable similarities with ERDs, but usage and terminology are different zAn SSD shows which classes of objects can exist in the software system, and how many of them can exist zAttributes represent the observable state of an object zServices can be operations or signal receptions yOperation = computation performed by object ySignal = named data structure that can be sent as a message to objects zAssociations 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 zStart from yContext diagram ySubject domain ERD yCommunication diagram of requirements-level architecture zThe 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 zPredict properties of a product before it is built zFeed-forward versus feedback loop zPossible ways to argue yEngineering knowledge / experience yThrow-away prototyping yModel execution yModel checking yTheorem-proving

24 Not Yet Another Method – formality and precision zA description is precise if it expresses as briefly as possible what is intended zIt is formal if it uses a language for which formal, meaning-preserving manipulation rules have been defined zFormal descriptions can be very imprecise: Statechart with superfluous transitions and states zPrecise descriptions can be very informal: Function descriptions zThe attempt to be precise has priority over the attempt to be formal

25 Summary zPostmodern structured analysis zUML zNot Yet Another Method