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 Prof. Dr. Uwe Aßmann 2) Structured Analysis/Design Technische Universität Dresden (SA/SD) Institut für Software- und 3) More on workflow nets Multimediatechnik A 1 ) S t r u c t u r e d A n a l y s i s a n d Design Technique (SADT) http://st.inf.tu-dresden.de/teaching/s wt2 Version 15-1.1, 06.01.16

Obligatory Reading S o f t w a r e t e c h n o l o g i e I I B a l z e r t , K a p . 1 4 ● Ghezzi Ch. 3.3, 4.1-4, 5.5 ● Pfmeeger Ch. 4.1-4.4, 5 ● h t t p : / / w w w . o m g . o r g / c g i - b i n / d o c ? d t c / 1 0 - 0 6 - 0 2 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/ ●

Other Literature S o f t w a r e t e c h n o l o g i e I I 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 h t t p : / / w w w . n i . c o m / l a b v i e w / 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

23.1 Actjon-Oriented Design S o f t w a r e t e c h n o l o g i e I I  A c t i o n - o r i e n t e d d e s i g n i s s i m i l a r t o f u n c t i o n - o r i e n t e d d e s i g n , b u t a d m i t s t h a t t h e s y s t e m 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  D e c o m p o s i t i o n s t r a t e g y : • D i v i d e : fj n d i n g s u b a c t i o n s • 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 actions the system should perform? What are the subactions of an action? What are the subactions of an action? Which state does an action change? 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

Structured Analysis and Design (SA/SD) S o f t w a r e t e c h n o l o g i e I I  Structured Analysis (SA) is a specifjc variant of action-oriented design with p r o c e s s e s (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)

Why SA is Important S o f t w a r e t e c h n o l o g i e I I  Usually, action-oriented design is structured , i.e., based on hierarchical stepwise refjnement.  Resulting systems are  r e d u c i b l e , 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 : M a s h u p s 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

Structured Analysis and Design (SA/SD) – The Development Process S o f t w a r e t e c h n o l o g i e I I On the highest abstraction level, defjne the c o n t e x t d i a g r a m : ● E l a b o r a t i o n : 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 ●

Data-Flow Diagrams (Datenfmussdiagramme, DFD) S o f t w a r e t e c h n o l o g i e I I 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 ●

Modeling with DFD S o f t w a r e t e c h n o l o g i e I I A d a t a - fm o w d i a g r a m is a reducible (hierarchic) nets of processes linked by channels ● (streams, pipes) Symbols (UML): C o n t e x t d i a g r a m : t o p - l e v e l , w i t h t e r m i n a t o r s ● name Parent diagrams, in which processes are point-wise refjned ● nr. Child diagrams are refjned processes ● Refjnement can be syntactic or semantic ● Data dictionary contains types for the data on the channels ● name Mini-specs (Minispezifjkationendienen) specify the atomic processes and their ● transformationen with Pseudocode or other high-level languages – Symbols (SA/Balzert): (name) name (c) Prof. U. Aßmann Data fmow channel Process (Activity) nr. (also bidirectional ) Terminator Store name name (fjle, repository, (Quelle/Senke) Speicher)

UML-CD “Doctor's Shop” 13 Treatment 1 0..n 1 Prof. U. Aßmann, Softwaretechnologie II treats Patient Doctor 0..1 0..m 1..n reserved waits uses 1 1..n 1 Client Date WaitingRoom Database

Ex.: DFD "treat_Patjent" S o f t w a r e t e c h n o l o g i e I I UML uses ovals for activities ● Treat_patient accept S y m p t o m s 1 _patient Patient 1.31 WaitingList Sickness certifjcate Patient Call_in_ Date Date _patient 1.32 Call write (c) Prof. U. Aßmann investigate _report Recipe _patient 1.34 1.33 Patient

Ex.: DFD "treat_Patjent" (Original SA Notatjon) S o f t w a r e t e c h n o l o g i e I I SA uses circles f o r a c t i v i t i e s ● empfangen B e s c h w e r d e n _Patient Patient Warteliste 1.31 aufrufen Patient Termine _Patient 1.32 schreiben (c) Prof. U. Aßmann unter- _Unterlagen suchen 1.34 _Patient 1.33

Functjon Trees, Actjon Trees and DFDs S o f t w a r e t e c h n o l o g i e I I  A c t i o n t r e e s c a n b e d e r i v e d f r o m f u n c t i o n t r e e s a n d f u n c t i o n n e t s  D F D a r e h o m o m o r p h i c t o A c t i o n t r e e s , b u t a d d s t o r e s a n d s t r e a m s  RepresentationChange : Construct an action tree and transform it to the processes of a DFD produce tea add boiling produce water tea put tea composition in TeaPot TeaPot store/file add put tea boiling wait in TeaPot water wait action fetch open close tea from TeaPot TeaPot tea box Cup

Pointwise Refjnement of Actjons S o f t w a r e t e c h n o l o g i e I I 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 ● put tea UML 2.0 offers reducible activity diagrams – in TeaPot Open TeaPot put tea put tea Fetch tea in TeaPot in TeaPot from tea box TeaPot fetch open close tea from Close TeaPot TeaPot tea box TeaPot TeaPot TeaPot