Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II
23. Action-Oriented Design Methods1) Action-Oriented Design
2) Structured Analysis/Design (SA/SD)
3) More on workflow nets
A1) Structured Analysis and Design Technique (SADT)
Prof. Dr. Uwe Aßmann
Technische Universität Dresden
Institut für Software- und Multimediatechnik
http://st.inf.tu-dresden.de/teaching/swt2Version 15-1.1, 06.01.16
Softwaretechnologie II
Obligatory Reading
● Balzert, Kap. 14
● Ghezzi Ch. 3.3, 4.1-4, 5.5
● Pfleeger Ch. 4.1-4.4, 5
● http://www.omg.org/cgi-bin/doc?dtc/10-06-02 BPMN by example
● W.M.P. van der Aalst and A.H.M. ter Hofstede. Verification of workflow task structures: A petri-net-based approach. Information Systems, 25(1): 43-69, 2000.
● Web portal “Petri Net World” http://www.informatik.uni-hamburg.de/TGI/PetriNets/
Softwaretechnologie II
Other Literature
● Wesley M. Johnston and J.R. Paul Hanna and Richard J. Millar. Advances in Dataflow Programming Languages. Computing Surveys, ACM, vol 36 (1), pages 1-34, 2004.
● The commercial language LabView/G (National Instruments) has a big user community for data-flow programming
– http://www.ni.com/labview/d/
Relationship of PN and other Behavioral Models
● P.D. Bruza, Th. P. van der Weide. The Semantics of Data-Flow Diagrams. Int. Conf. on the Management of Data. 1989
– http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.9398
● Matthias Weske. Business Process Modeling. Springer-Verlag.
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II
23.1 Action-Oriented Design
Softwaretechnologie II
23.1 Action-Oriented Design
Action-oriented design is similar to function-oriented design, but admits that the system has states.
It asks for the internals of the system
Actions require state on which they are performed (imperative, state-oriented style)
Actions are running in parallel
Decomposition strategy:
• Divide: finding subactions
• Conquer: grouping to modules and processes
• Result: reducible action system
Example: all function-oriented design methods can be made to action-oriented ones, if state is added
• State machine based design for embedded systems; Petrinet based design (with distributed state)
• Imperative programming
What are the actions the system should perform?What are the subactions of an action?Which state does an action change?
What are the actions the system should perform?What are the subactions of an action?Which state does an action change?
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II
23.2 Action-Oriented Design with SA/SD
Data-flow connects processes (parallel actions)State is implicit in the atomic processes, not explicit in the global, architectural specifications
Softwaretechnologie II
Structured Analysis and Design (SA/SD)
Structured Analysis (SA) is a specific variant of action-oriented design with processes (process-oriented design, data-flow based design)
• [DeMarco, T. Structured Analysis and System Specification, Englewood Cliffs: Yourdon Press, 1978]
Notations of SA:
Function trees (action trees, process trees): decomposition of system functions
Data flow diagrams (DFD), in which the actions are called processes
Data dictionary (context-free grammar) describes the structure of the data that flow through a DFD
Alternatively, class diagrams can be used
Pseudocode (minispecs) describes central algorithms (state-based)
Decision Table and Trees describes conditions (see later)
Softwaretechnologie II
Why SA is Important
Usually, action-oriented design is structured, i.e., based on hierarchical stepwise refinement.
Resulting systems are reducible, i.e., all results of the graph-reducibility techniques apply.
parallel, because processes talk with streams
locality, because processes write to local shared memory
easy to distribute, because no global memory exists
SA and SADT are important for
• Embedded systems because resulting systems are parallel and hierarchic
• Web engineering: Mashups are web-based data-flow diagrams and can be developed by SA (see course Softwarewerkzeuge)
• Software architecture: Modern service-oriented architectures (SOA) split the application logic into two layers:
Architectural workflow layer
Service layer
Softwaretechnologie II
Structured Analysis and Design (SA/SD) – The Development Process
● On the highest abstraction level, define the context diagram:
– Elaboration: Define interfaces of entire system by a top-level function (action) tree
– Elaboration: Identify the input-output streams most up in the function (action) hierarchy
– Elaboration: Identify the highest level processes
– Elaboration: Identify stores
● Refinement: Decompose function tree hierarchically
● Change Representation: transform action tree into process diagram (action/data flow)
● Elaboration: Define the structure of the flowing data in the Data Dictionary
● Check consistency of the diagrams
● Elaboration: Minispecs in pseudocode
Softwaretechnologie II
Data-Flow Diagrams (Datenflussdiagramme, DFD)
● DFD are a special form of Petri nets (see Chapter on Petri nets)
● They are also special workflow languages without repository and global state
– DFD use local stores for data, no global store
– Less conflicts on data for parallel processes
● Good method to model parallel systems
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Modeling with DFD
Symbols (SA/Balzert):
namenr.Process (Activity)
Data flow channel
(also bidirectional)
(name)
Terminator(Quelle/Senke)
nameStore(file, repository,Speicher)
name
● A data-flow diagram is a reducible (hierarchic) nets of processes linked by channels (streams, pipes)
● Context diagram: top-level, with terminators
● Parent diagrams, in which processes are point-wise refined
● Child diagrams are refined processes
● Refinement can be syntactic or semantic
● Data dictionary contains types for the data on the channels
● Mini-specs (Minispezifikationendienen) specify the atomic processes and their transformationen
– with Pseudocode or other high-level languages
namenr.
name
Symbols (UML):
Pro
f. U
. Aß
ma
nn, S
oftw
a ret
ech
no
logi
e I
I
13
UML-CD “Doctor's Shop”
Patient Doctor
Treatment
Date WaitingRoomClient
Database
treats
reserved waits uses
1
0..n 1
0..1
1..n
0..m
1 1
1..n
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Ex.: DFD "treat_Patient"
Symptoms
● UML uses ovals for activities
accept_patient
1.31Patient
Call_in__patient
1.32
investigate_patient
1.33
write_report
1.34
Sickness certificate
Patient
Call
Treat_patient1
Recipe
Patient DateDate
WaitingList
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Ex.: DFD "treat_Patient" (Original SA Notation)
unter-suchen_Patient
1.33
schreiben_Unterlagen
1.34
TerminePatient
Beschwerden
Warteliste
● SA uses circles for activities
Patient
empfangen_Patient
1.31
aufrufen_Patient
1.32
Softwaretechnologie II
Function Trees, Action Trees and DFDs
Action trees can be derived from function trees and function nets DFD are homomorphic to Action trees, but add stores and streams
RepresentationChange: Construct an action tree and transform it to the processes of a DFD
produce tea
put tea in TeaPot
add boiling water
wait
composition
produce tea
store/file
action
fetchtea fromtea box
open TeaPot
closeTeaPot
put tea in TeaPot
wait
add boiling
water
TeaPot
Cup
Softwaretechnologie II
Pointwise Refinement of Actions
● Subtrees in the function tree lead to reducible subgraphs in the DFD
● UML action trees can be formed from activities and aggregation
● Activity diagrams can specify dataflow
– UML 2.0 offers reducible activity diagrams
Fetch tea from tea box
Open TeaPot
Close TeaPot
put tea in TeaPot
TeaPot
put tea in TeaPot
TeaPot
put tea in TeaPot
open TeaPot
TeaPot
closeTeaPot
fetchtea fromtea box
Softwaretechnologie II
Typing Edges with Types from the Data Dictionary
In an SA, the data dictionary collects data types describing the context free structure of the data flowing over the edges. To this end, a data definition language (DDL) is required:
• Grammar: For every edge in the DFDs, the context-free grammar contains a non-terminal that describes the flowing data items
• Entity-Relationship Diagram (or its object-oriented variant MOF)
• UML class diagram: classes describe the data items
Grammars are written in Extended Backus-Naur Form (EBNF) with the following rules:
Notation Meaning Example
::= or = Consists of A ::= B.
Sequence + Concatenation A ::= B+C.
Sequence <blank> Concatenation A ::= B C.
Selection I or [ | ] Alternative A ::= [ B | C ].
Repetition { }^n A ::= { B }^n.
Limited repetition m { } n Repetition from m to n A ::= 1{ B }10.
Option ( ) Optional part A ::= B (C).
Softwaretechnologie II
Example Grammar in Data Dictionary
DataInPot ::= TeaPortion WaterPortion.TeaAutomatonData ::= Tea | Water | TeaDrink.Tea ::= BlackTea | FruitTea | GreenTea.TeaPortion ::= { SpoonOfTea }.SpoonOfTea ::= Tea.WaterPortion ::= { Water }.
● Describes types for channels
Exc. Read every rule aloud!
Softwaretechnologie II
Adding Types to DFDs
● Nonterminals from the data dictionary become types on flow edges
● Alternatively, classes from a UML class diagram can be annotated
Tea
TeaDrink
Fetch tea from tea box
Open TeaPot
Close TeaPot
put tea in TeaPot
TeaPot
TeaPot
Water
Softwaretechnologie II
Minispecs in Pseudocode
Minispecs describes the processes in the nodes of the DFD in pseudo code. They describe the data transformation of every process
Here: specification of the minispec attachment process:
procedure: AddMinispecsToDFDNodestarget.bubble := select DFD node;do while target-bubble needs refinement
if target.bubble is multi-functionalthen decompose as required; select new target.bubble;
add pseudocode to target.bubble;else no further refinement needed
endifenddo
end
procedure: AddMinispecsToDFDNodestarget.bubble := select DFD node;do while target-bubble needs refinement
if target.bubble is multi-functionalthen decompose as required; select new target.bubble;
add pseudocode to target.bubble;else no further refinement needed
endifenddo
end
Softwaretechnologie II
Good Languages for Pseudocode
SETL (Schwartz, New York University) Dynamic sets, mappings, Iterators
– http://en.wikipedia.org/wiki/SETL
– http://randoom.org/Software/SetlX
PIKE (pike.ida.liu.se) Dynamic arrays, sets, relations, mappings
Iterators
ELAN (Koster, GMD Berlin) Natural language as identifiers of procedures
– http://en.wikipedia.org/wiki/ELAN_(programming_language)
– One of the sources of our TUD OS L4: http://os.inf.tu-dresden.de/L4/l3elan.html
Smalltalk (Goldberg et.al, Parc)
Attempto Controlled English (ACE, Prof. Fuchs, Zurich) A restricted form of English, easy to parse
Softwaretechnologie II
Structured Analysis and Design (SA/SD) - Heuristics
● Consistency checks between the different notations
– Isomorphism rule (1:1 mapping) between diagrams (e.g., between function trees and DFD)
– Corrections necessary in case of structure clash between input and output formats
● Verification
– Point-wise refinement can be proven to be correct by bisimulations of the original and refined net
● Advantage of SA
– Hierarchical refinement: The actions in the DFD can be refined, I.e., the DFD is a reducible graph
– SA leads to a hierarchical design (a component-based system)
Softwaretechnologie II
Difference to Functional and Modular Design
● SA focusses on actions (parallel activities, processes), not functions
– Describe the continuous data-flow through a system
– Describe stream-based systems with pipe-and-filter architectures
● Actions are parallel processes
– SA and SADT can easily describe parallel systems
● Function trees are interpreted as action trees (process trees) that treat streams of data
Softwaretechnologie II
Implementation Hints for DFD
● Channels (streams): implement with Design Pattern Channel (ST-1)
● Processes:
– Ada-82-03 has parallel processes and channels
● Interpretation:
– If actions should be undone (in interactive editing), or replayed, they can be encapsulated into Command objects (see design patterns Command and Interpreter)
● If actions work on a data structure, design pattern Visitor allows for extensible action command objects
Softwaretechnologie II
Result: Data-Flow-Based Architectural Style
● SA/SD design leads to dataflow-based architectural style
● Processes exchanging streams of data
● Data flow forward through the system
● Components are called filters, connections are pipes (channels, streams)
Filter
Filter
Filter
System pipe
pipe
Softwaretechnologie II
Application Areas are Manifold
● Shell programming with pipes-and-filters
– tcsh, bash, zsh (Linux)
– Microsoft Powershell
● Image processing systems
– Image operators are filters in image data-flow diagrams
● Signal processing systems (DSP-based embedded systems)
– The satellite radio
– Video processing systems
– Car control
– Process systems (powerplants, production control, …)
● Content management systems (CMS)
– Content data is piped through XML operators until a html page is produced
● Stream-based business workflows for data-intensive business applications
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II
23.3 Workflow Nets and Modern Workflow Languages
Softwaretechnologie II
Workflow Nets and Modern Workflow Languages
● In general, workflows are executable sequences of actions, sharing data from several repositories or communicating with streams.
● Workflow nets are reducible with single sources and single sinks (single-entry/single-exit), so that only reducible nets can be specified
– Data-flow is expressed with messages
– They extend DFD with control flow edges and synchronization
● They provide richer synchronization operators (AND, XOR, OR), inhibitor arcs, and synchronization protocols
– They avoid global repositories and global state
● Workflow nets can be compiled to Petri Nets
● Further, specialized workflow languages exist, such as
– YAWL Yet another workflow language
– BPMN Business Process Modeling Notation
– BPEL Business Process Execution Language
– For checking of wellformedness constraints, they are reduced to PN
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Rpt.: Complex Transition Operators in Workflow Nets: Join and Split Operators of YAWL
OR
XOR
AND AND
XOR
OR
● All incoming places are ready (conjunctive input, AND-join)
● One out of n incoming places are ready (disjunctive input)
● Some out of n incoming places are ready (selective input)
● All outgoing places are filled (conjunctive output, AND-split)
● One out of n outgoing places are filled (disjunctive output)
● Some out of n outgoing places are filled (selective output)
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Inhibitor Arcs
AND
● An inhibitor arc prevents the firing of an operator or transition
IP IP
A
B
● Transition only fires if inhibiting place IP is not ready.
● AND-Operator only fires if IP is not ready.
A
B
Softwaretechnologie II
Implementation Hints For Workflow Nets
● Edges become channels (streams): implement with Design Pattern Channel (ST-1)
● Places: Heap, Repositories, Files
● Transition operators: use a synchronization protocol such as Barrier or Monitor
● Leave the execution to a workflow engine (workflow interpreter) of a current workflow language:
– JBPM
– BPMN www.bpmn.org
– BPEL
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II
(c) Prof. U. Aßmann Model Structurings
23.4.2 Extensibility of Workflow Nets
● The design of Software Product Lines (SPL) requires that core workflows are extended by plugins.
● Data-flow diagrams and workflow nets are easy to extend, because they have open operators
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Semantically Open Operators for Synchronization and Splitting of Control Flow
OR XOR
● Some operators in workflow nets, e.g., the OR and XOR join- and split-operators, are semantically open, i.e., can be extended by incoming resp. outgoing edges without violating the contract of the operator
– Reason: they are OR-composition operators
● Extensions of these operators are harmless, i.e., retain the behavior of the core workflow
● Open OR-Join:
● Some out of n incoming places are ready
● Open XOR-Join:
● One out of n incoming places are ready
XOR OR
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
● The COPY-AND-split operator copies an incoming token to all its out-places.
CP-OR
CP-AND
Other Open Operators
● The COPY-OR-split operator copies an incoming token to some of its out-places.
CP-AND
CP-OR
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Syntactically Open Operators
XOR OR
● Other operators in workflow nets are only syntactically open, i.e., can be extended by incoming resp. outgoing edges but change the contract of the operator
– Reason: they are indeterministic
● Extensions of these operators are not harmless, i.e., do not retain the behavior of the core workflow
● Open OR-Split:
● Some out of n outgoing places are filled
● Open XOR-Split:
● One out of n outgoing places are filled
XOR OR
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Workflows with Harmless Extensions
● If edges are added to an open operator, they enrich the semantics of the net, but do not destroy or change it (monotonic extension)
● Therefore, adding an edge retains the contracts, i.e., basic assumptions, of a workflow net.
Extending the semantically open operators of a core workflow does not change the contracts of it.
Extending the semantically open operators of a core workflow does not change the contracts of it.
A workflow plugin extends a core workflow with an extension slice.A workflow plugin extends a core workflow with an extension slice.
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II
(c) Prof. U. Aßmann Model Structurings
23.4.3 Architectures with Workflows
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Rpt. from ST-1: 4-Tier Web System (Thick Client)
Data Repository Layer (database, memory)
Middleware
Graphical user interface
Application logic (business logic)
● Workflow specifications are for the application logic layer
<<boundary>><<page>>
<<control>><<applet>>
<<entity>>Data access object (DAO)
<<database>>
Server
Client
http
Workflow
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
5-Tier with Workflow Language (Service-Oriented Architecture)
Data Repository Layer (database, memory)
Graphical user interface
Application logic (business logic)
● In a Workflow Architectural Style (service-oriented architecture), a workflow in a language (BPMN, BPEL, WF Nets) specifies the application architecture
– All services and underlying components are called by the workflow
– The workflow is executed by a special workflow engine
<<boundary>><<page>>
<<control>>
<<entity>>
<<database>>
Server
Client
Workflow-based Architecture
Services, components
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Application logic (business logic)
5-Tier with Workflow Language and Web Services
Data Repository Layer (database, memory)
Graphical user interface
Application logic (business logic)
● Workflow languages (BPMN, BPEL, WF Nets) describe the top-level of the application architecture
– Services and components are called by the workflow via SOAP protocol
<<boundary>><<page>>
<<control>>
<<entity>>data access object (DAO)
<<database>>
Server
Client
Workflow
Web services
SOAP
SOAP
Softwaretechnologie II
(c)
Pro
f. U
. A
ßm
an
n
Model Structurings
Extensibility of Workflow-Based Architectures
● From the semantics of open operators, extensibility criterion can be derived.
A workflow-based architecture has extension points at all employments of open operators.
A workflow-based architecture has extension points at all employments of open operators.
A workflow plugin can extend a core workflow of a workflow-based architecture with an extension slice.
A workflow plugin can extend a core workflow of a workflow-based architecture with an extension slice.
Softwaretechnologie II
What Have We Learned
● Besides object-oriented design, structured, action-oriented design is a major design technique
– It will not vanish, but always exist for certain application areas
– If the system will be based on stream processing, system-oriented design methods are appropriate
– System-oriented design methods lead to reducible systems
● Don't restrict yourself to object-oriented design
● Workflow languages extend DFD with control flow and can be compiled to Petri nets
● In a Workflow-Based Architecture, all services are described by architectural workflows
Softwaretechnologie II
AppendixPossible Exam Questions
● Which advantages has the reducibility of the SA DFD specification?
● Show a refinement of a DFD, starting from a given function tree
● Which relation has a DFD and a CPN?
● How would you implement a DFD specification?
● What is the unique characterization of a workflow-based architecture?
● How to extend a workflow net?
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II
23.A1. SADT
Softwaretechnologie II
Structured Analysis and Design Technique (SADT)
● SADT is a action- and data-flow-oriented method
● Reducible graphs with 2 main forms of diagrams:
– Activity diagrams: Nodes are activities, edges are data flow (like DFD)
● Data flow architectures result
– Data diagrams: Nodes are data (stores) and edges are activities
– Layout constraint: edges go always from left to right, top to bottom
● Companies used to have standardized forms, marked with author, date, version, name, etc..
ActivityInputData
OutputData
Control Data
Mechanism/responsible
DataGeneratingActivity
ConsumingActivity
Control Activity
Store
Softwaretechnologie II
Maintenance
Example: The Waterfall Software Model with Activity Diagram of SADT
Activity Diagrams SADT – Special DFD, with read direction left to right, top to bottom
With designation of responsible
CollectRequirements
Design
DesignerImplementation
RequirementsEngineer
Programmer
Maintener
WaterfallSoftwareConstruction
SRS
SD
Program
Softwaretechnologie II
Point-Wise Refinement of Nodes
Prof. U. Aßmann Action Oriented Design
ArchitecturalDesign
DetailedDesign
Designer
Architect
Design
DetailedDesignDocument
ArchitecturalDesign
Requirements
● Refinement must preserve input-output channels
Softwaretechnologie II
SADT Data Diagram of a Copmiler
Characters
Tokens
SyntaxTree
IntermediateCode
Machine code
Buffer
Pipe
Memory
File
Lex. Grammar Grammar Tree Mapping
Compiler
Softwaretechnologie II
Prof. U. Aßmann Action Oriented Design
Softwaretechnologie II
Comparison SADT vs SA/SD
SADT, SA/SD are system-oriented methods, known in other disciplines Action-oriented methods
they only distinguish between actions (processes) and data
Stream-oriented, i.e., model streams of data flowing through the system
System-oriented, know the concept of a subsystem
SA-DFDs are more flexible as SADT actitity diagrams, since the layout is not constrained Function trees and DDs may be coupled with SADT
Prof. U. Aßmann Action Oriented Design
Softwaretechnologie II
Why are the Data-Flow Methods SA and SADT Important?
They lead to component-based systems (hierarchical systems) Component-based systems are ubiquituous for many areas
Object-orientation is not needed everywhere
Other engineers use SADT also
SA and SADT can easily describe parallel systems in a structured way
SA and SADT are stream-based, i.e., for stream-based applications. When your context model has streams in its interfaces, SA and SADT might be applicable
Use case actions can be refined similarly as SA and SADT actions!
Mashups are web-based data-flow diagrams (see course Softwarewerkzeuge)