23. Actjon-Oriented Design Methods 1) Action-Oriented Design Prof. - - PowerPoint PPT Presentation

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

• 23. Actjon-Oriented Design Methods

1) 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/s wt2 Version 15-1.1, 06.01.16

S

• f

t w a r e t e c h n

• l
• g

i e I I

Obligatory Reading

• Balzert, Kap. 14
• Ghezzi Ch. 3.3, 4.1-4, 5.5
• Pfmeeger 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. Verifjcation of workfmow 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/

S

• f

t w a r e t e c h n

• l
• g

i e I I

Other Literature

• Wesley M. Johnston and J.R. Paul Hanna and Richard J. Millar. Advances in Datafmow

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-fmow 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 Actjon-Oriented Design

S

• f

t w a r e t e c h n

• l
• g

i e I I

23.1 Actjon-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: fjnding 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 Actjon-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

S

• f

t w a r e t e c h n

• l
• g

i e I I

Structured Analysis and Design (SA/SD)

• Structured Analysis (SA) is a specifjc variant of action-oriented design with processes

(process-oriented design, data-fmow based design)

• [DeMarco, T. Structured Analysis and System Specifjcation, Englewood Cliffs: Yourdon Press,

1978]

• Notations of SA:
• Function trees (action trees, process trees): decomposition of system functions
• Data fmow diagrams (DFD), in which the actions are called processes
• Data dictionary (context-free grammar) describes the structure of the data that fmow

through a DFD

• Alternatively, class diagrams can be used
• Pseudocode (minispecs) describes central algorithms (state-based)
• Decision Table and Trees describes conditions (see later)

S

• f

t w a r e t e c h n

• l
• g

i e I I

Why SA is Important

• Usually, action-oriented design is structured, i.e., based on hierarchical stepwise

refjnement.

• 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-fmow 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 workfmow layer
• Service layer

S

• f

t w a r e t e c h n

• l
• g

i e I I

Structured Analysis and Design (SA/SD) – The Development Process

• On the highest abstraction level, defjne the context diagram:

–

Elaboration: Defjne 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

• Refjnement: Decompose function tree hierarchically
• Change Representation: transform action tree into process diagram (action/data fmow)
• Elaboration: Defjne the structure of the fmowing data in the Data Dictionary
• Check consistency of the diagrams
• Elaboration: Minispecs in pseudocode

S

• f

t w a r e t e c h n

• l
• g

i e I I

Data-Flow Diagrams (Datenfmussdiagramme, DFD)

• DFD are a special form of Petri nets (see Chapter on Petri nets)
• They are also special workfmow languages without repository and global state

–

DFD use local stores for data, no global store

–

Less confmicts on data for parallel processes

• Good method to model parallel systems

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Modeling with DFD

Symbols (SA/Balzert): name nr. Process (Activity) Data fmow channel (also bidirectional) (name) Terminator (Quelle/Senke) name Store (fjle, repository, Speicher) name

• A data-fmow 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 refjned
• Child diagrams are refjned processes
• Refjnement can be syntactic or semantic
• Data dictionary contains types for the data on the channels
• Mini-specs (Minispezifjkationendienen) specify the atomic processes and their

transformationen

–

with Pseudocode or other high-level languages

name nr. name Symbols (UML):

• Prof. U. Aßmann, Softwaretechnologie II

13

UML-CD “Doctor's Shop”

Patient Doctor Treatment Date WaitingRoom Client Database

treats reserved waits uses 1 0..n 1 0..1 1..n 0..m 1 1 1..n

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Ex.: DFD "treat_Patjent"

S y m p t

• m

s

• UML uses ovals for activities

accept _patient 1.31

Patient

Call_in_ _patient 1.32 investigate _patient 1.33 write _report 1.34

Sickness certifjcate

Patient

Call

Treat_patient 1

Recipe

Patient Date Date

WaitingList

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Ex.: DFD "treat_Patjent" (Original SA Notatjon)

unter- suchen _Patient 1.33 schreiben _Unterlagen 1.34 Termine Patient

B e s c h w e r d e n

Warteliste

• SA uses circles for activities

Patient

empfangen _Patient 1.31 aufrufen _Patient 1.32

S

• f

t w a r e t e c h n

• l
• g

i e I I

Functjon Trees, Actjon 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

fetch tea from tea box

• pen

TeaPot close TeaPot

put tea in TeaPot wait add boiling water TeaPot Cup

S

• f

t w a r e t e c h n

• l
• g

i e I I

Pointwise Refjnement of Actjons

• 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 datafmow

–

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

• pen

TeaPot TeaPot close TeaPot fetch tea from tea box

S

• f

t w a r e t e c h n

• l
• g

i e I I

Typing Edges with Types from the Data Dictjonary

• In an SA, the data dictionary collects data types describing the context free structure of

the data fmowing over the edges. To this end, a data defjnition language (DDL) is required:

• Grammar: For every edge in the DFDs, the context-free grammar contains a non-terminal that

describes the fmowing 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).

S

• f

t w a r e t e c h n

• l
• g

i e I I

Example Grammar in Data Dictjonary

DataInPot ::= TeaPortion WaterPortion. TeaAutomatonData ::= Tea | Water | TeaDrink. Tea ::= BlackTea | FruitTea | GreenTea. TeaPortion ::= { SpoonOfTea }. SpoonOfTea ::= Tea. WaterPortion ::= { Water }.

• Describes types for channels

E x c . R e a d e v e r y r u l e a l

• u

d !

S

• f

t w a r e t e c h n

• l
• g

i e I I

Adding Types to DFDs

• Nonterminals from the data dictionary become types on fmow 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

S

• f

t w a r e t e c h n

• l
• g

i e I I

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: specifjcation of the minispec attachment process:

procedure: AddMinispecsToDFDNodes target.bubble := select DFD node; do while target-bubble needs refinement if target.bubble is multi-functional then decompose as required; select new target.bubble; add pseudocode to target.bubble; else no further refinement needed endif enddo end procedure: AddMinispecsToDFDNodes target.bubble := select DFD node; do while target-bubble needs refinement if target.bubble is multi-functional then decompose as required; select new target.bubble; add pseudocode to target.bubble; else no further refinement needed endif enddo end

S

• f

t w a r e t e c h n

• l
• g

i e I I

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 identifjers 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

S

• f

t w a r e t e c h n

• l
• g

i e I I

Structured Analysis and Design (SA/SD) - Heuristjcs

• 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

• Verifjcation

–

Point-wise refjnement can be proven to be correct by bisimulations of the original and refjned net

• Advantage of SA

–

Hierarchical refjnement: The actions in the DFD can be refjned, I.e., the DFD is a reducible graph

–

SA leads to a hierarchical design (a component-based system)

S

• f

t w a r e t e c h n

• l
• g

i e I I

Difgerence to Functjonal and Modular Design

• SA focusses on actions (parallel activities, processes), not functions

–

Describe the continuous data-fmow through a system

–

Describe stream-based systems with pipe-and-fjlter 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

S

• f

t w a r e t e c h n

• l
• g

i e I I

Implementatjon 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

S

• f

t w a r e t e c h n

• l
• g

i e I I

Result: Data-Flow-Based Architectural Style

• SA/SD design leads to datafmow-based architectural style
• Processes exchanging streams of data
• Data fmow forward through the system
• Components are called fjlters, connections are pipes (channels, streams)

Filter Filter Filter System pipe pipe

S

• f

t w a r e t e c h n

• l
• g

i e I I

Applicatjon Areas are Manifold

• Shell programming with pipes-and-fjlters

–

tcsh, bash, zsh (Linux)

–

Microsoft Powershell

• Image processing systems

–

Image operators are fjlters in image data-fmow 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 workfmows for data-intensive business applications

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

23.3 Workfmow Nets and Modern Workfmow Languages

S

• f

t w a r e t e c h n

• l
• g

i e I I

Workfmow Nets and Modern Workfmow Languages

• In general, workfmows are executable sequences of actions, sharing data from several

repositories or communicating with streams.

• Workfmow nets are reducible with single sources and single sinks (single-entry/single-

exit), so that only reducible nets can be specifjed

–

Data-fmow is expressed with messages

–

They extend DFD with control fmow edges and synchronization

• They provide richer synchronization operators (AND, XOR, OR), inhibitor arcs, and

synchronization protocols

–

They avoid global repositories and global state

• Workfmow nets can be compiled to Petri Nets
• Further, specialized workfmow languages exist, such as

–

YAWL Yet another workfmow language

–

BPMN Business Process Modeling Notation

–

BPEL Business Process Execution Language

–

For checking of wellformedness constraints, they are reduced to PN

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Rpt.: Complex Transitjon Operators in Workfmow 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 fjlled

(disjunctive output)

• Some out of n outgoing places are fjlled

(selective output)

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Inhibitor Arcs

AND

• An inhibitor arc prevents the fjring of an operator or transition

IP IP A B

• Transition only fjres if inhibiting place IP is

not ready.

• AND-Operator only fjres if IP is not ready.

A B

S

• f

t w a r e t e c h n

• l
• g

i e I I

Implementatjon Hints For Workfmow 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 workfmow engine (workfmow interpreter) of a current workfmow

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 Workfmow 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

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Semantjcally Open Operators for Synchronizatjon and Splittjng

• f Control Flow

OR XOR

• Some operators in workfmow 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 workfmow
• Open OR-Join:
• Some out of n incoming places are

ready

• Open XOR-Join:
• One out of n incoming places are ready

XOR OR

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

• 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

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Syntactjcally Open Operators

XOR OR

• Other operators in workfmow 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

workfmow

• Open OR-Split:
• Some out of n outgoing places are

fjlled

• Open XOR-Split:
• One out of n outgoing places

are filled

XOR OR

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Workfmows 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 workfmow

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 Workfmows

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

• Rpt. from ST-1: 4-Tier Web System (Thick Client)

Data Repository Layer (database, memory) Middleware Graphical user interface Application logic (business logic)

• Workfmow specifjcations are for the application logic layer

<<boundary>> <<page>> <<control>> <<applet>> <<entity>> Data access

• bject (DAO)

<<database>> Server Client http Workflow

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

5-Tier with Workfmow Language (Service-Oriented Architecture)

Data Repository Layer (database, memory) Graphical user interface Application logic (business logic)

• In a Workfmow Architectural Style (service-oriented architecture), a workfmow in a

language (BPMN, BPEL, WF Nets) specifjes the application architecture

–

All services and underlying components are called by the workfmow

–

The workfmow is executed by a special workfmow engine

<<boundary>> <<page>> <<control>> <<entity>> <<database>> Server Client Workflow-based Architecture Services, components

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Application logic (business logic)

5-Tier with Workfmow Language and Web Services

Data Repository Layer (database, memory) Graphical user interface Application logic (business logic)

• Workfmow languages (BPMN, BPEL, WF Nets) describe the top-level of the application

architecture

–

Services and components are called by the workfmow via SOAP protocol

<<boundary>> <<page>> <<control>> <<entity>> data access

• bject (DAO)

<<database>> Server Client Workflow Web services SOAP SOAP

S

• f

t w a r e t e c h n

• l
• g

i e I I

(c) Prof. U. Aßmann

Extensibility of Workfmow-Based Architectures

• From the semantics of open operators, extensibility criterion can be derived.

A workflow-based architecture has extension points at all employments

• f open operators.

A workflow-based architecture has extension points at all employments

• f 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.

S

• f

t w a r e t e c h n

• l
• g

i e I I

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
• Workfmow languages extend DFD with control fmow and can be compiled to Petri nets
• In a Workfmow-Based Architecture, all services are described by architectural workfmows

S

• f

t w a r e t e c h n

• l
• g

i e I I

Appendix Possible Exam Questjons

• Which advantages has the reducibility of the SA DFD specifjcation?
• Show a refjnement of a DFD, starting from a given function tree
• Which relation has a DFD and a CPN?
• How would you implement a DFD specifjcation?
• What is the unique characterization of a workfmow-based architecture?
• How to extend a workfmow net?

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

23.A1. SADT

S

• f

t w a r e t e c h n

• l
• g

i e I I

Structured Analysis and Design Technique (SADT)

• SADT is a action- and data-fmow-oriented method
• Reducible graphs with 2 main forms of diagrams:

–

Activity diagrams: Nodes are activities, edges are data fmow (like DFD)

• Data fmow 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..

Activity Input Data Output Data Control Data Mechanism/ responsible Data Generating Activity Consuming Activity Control Activity Store

S

• f

t w a r e t e c h n

• l
• g

i e I I

Maintenance

Example: The Waterfall Sofuware Model with Actjvity Diagram

• f SADT
• Activity Diagrams SADT – Special DFD, with read direction left to right, top to bottom
• With designation of responsible

Collect Requirements Design Designer Implementation Requirements Engineer Programmer Maintener Waterfall Software Construction SRS SD Program

S

• f

t w a r e t e c h n

• l
• g

i e I I

Point-Wise Refjnement of Nodes

• Prof. U. Aßmann

Action Oriented Design

Architectural Design Detailed Design Designer Architect Design Detailed Design Document Architectural Design Requirements

• Refjnement must preserve input-output channels

S

• f

t w a r e t e c h n

• l
• g

i e I I

SADT Data Diagram of a Copmiler

Characters Tokens Syntax Tree Intermediate Code Machine code Buffer Pipe Memory File

• Lex. Grammar

Grammar Tree Mapping Compiler

S

• f

t w a r e t e c h n

• l
• g

i e I I

• Prof. U. Aßmann

Action Oriented Design

S

• f

t w a r e t e c h n

• l
• g

i e I I

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 fmowing through the system
• System-oriented, know the concept of a subsystem
• SA-DFDs are more fmexible 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

S

• f

t w a r e t e c h n

• l
• g

i e I I

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 refjned similarly as SA and SADT actions!
• Mashups are web-based data-fmow diagrams (see course Softwarewerkzeuge)