Action-Oriented Design Methods

Transcription

1 Action-Oriented Design Methods Prof. Dr. U. Aßmann Technische Universität Dresden Institut für Software- und Multimediatechnik Gruppe Softwaretechnologie Softwaretechnologie II, Prof. Uwe Aßmann 1

2 Contents Use Cases Structured Analysis/Design (SA/SD) Structured Analysis and Design Technique (SADT) 2

3 Obligatory Reading Ghezzi Ch. 3.3, 4.1-4, 5.5 Pfleeger Ch , 5 3

4 Secondary Literature Usually, action-oriented design is structured, i.e., based on hierarchical refinement. Resulting systems are reducible, i.e., all results of the graph-reducibility techniques apply. 4

5 Action-oriented Design What are the actions the system should perform? Action-oriented design is similar to function-oriented design, but admits that the system has states. It asks more for the internals of the system Actions require state on which they are performed (imperative, stateoriented style) Divide: finding subactions Conquer: grouping to modules 5

6 Use Case Diagram (UCD) A Use Case Diagram consists of several use cases of a system A use case describes an application, a coarse-grain function or action of a system, in a certain relation with actors A use case contains a scenario sketch Pseudocode text which describes the functionality 6 6

7 Example Service Station A Service Station has 4 tasks [Pfleeger] Parking Refueling Maintenance Parking Preventive Maintainance Refueling Customer Maintenance Preventive Maintenance <<extends>> Manager 7 7

8 Questions for Use Cases What is the system/subsystem? Who is Actor? A user An active object A person A system Must be external to the described system What are the Applications/Uses? What are the relations among Use Cases Extends: Extend an existing use case (Inheritance) Uses: Reuse of an existing use case (Sharing) 8 8

9 Questions to help What Users External systems Use Need the system for which tasks? Are tasks or relations to complex? 9 9

10 Refinement Service Station We introduce an abstraction of the services Credit Card System Manager Customer Billing Services Preventive Maintenance Parking Refueling Maintenance 10 10

11 Second Refinement Service Station Customer Credit Card System Accounting Services Printer System Parking Billing Services Refueling Maintenance Manager Preventive Maintenance 11 11

12 Third Refinement Service Station The <<includes>> relationship allows for decomposition of a use case. <<includes>> is a form of <<part-of>> initiates Maintenance Inspection <<includes>> Manager Diagnosis Technician Therapy Accounting Services Recording Efforts Customer 12

13 Consistency Checking Check List Use Case Diagrams One diagram Clarity Simplicity Completeness Match the stories of the customer? Missing actors? Several diagrams Which actions occur in several diagrams? Are they specified consistently? Should actors from shared actions be replicated to other UCD? 13 13

14 How To Go On from a Use Case Diagram There are several ways how to reach a design from a use case diagram Hierarchical refinement of the actions into UCD of second level, yielding a reducible specification Disadvantage of UCD: Hierarchical refinement is sometimes difficult, because new actors have to be added Leads to a correction of the top-level UCD Action tree method: action-oriented method to refine the use case actions with an action tree Collaboration diagram method: object-oriented method to analyse paths in the use case diagram with communication (collaboration) diagrams (see later) 14

15 Hierarchical Refinement of a Use Case Often, new actors have to be added during refinement Diagnosis Technician Evaluate inspection data Consult other experts Consult manual Diagnosis new actor!! Technician 15

16 Deriving an Action Tree from a Use Case DomainTransformation: From a UCD, set up an action tree <<includes>> expresses a part-of hierarchy of actions Refinement: Refine the actions by decomposition Maintenance Inspection Diagnosis Therapy Recording Efforts Watching Inspect Error codes Combine inspection results Consult other experts..other.. 16

17 Benefits of Use Cases Use cases are good for Documentation Communication with customers and designers Are started for the first layout of the structural model To find classes, their actions, and relations In extreme Programming (XP), use cases are called stories which are written down on one muddy card collected and implemented one after the other XP does not look at all use cases together, but implements one after the other 17

18 Action-Oriented Design with SA/SD Softwaretechnologie II, Prof. Uwe Aßmann 18

19 Structured Analysis and Design (SA/SD) [DeMarco, T. Structured Analysis and System Specification, Englewood Cliffs: Yourdon Press, 1978] Representation Function 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 Pseudocode (minispecs) describes central algorithms Decision Table and Trees describes conditions (see later) 19

20 Structured Analysis and Design (SA/SD) - Process On the highest abstraction level: Elaboration: Define interfaces of entire system by a top-level function tree Elaboration: Identify the input-output streams most up in the function hierarchy Elaboration: Identify the highest level processes Elaboration: Identify stores Refinement: Decompose function tree hierarchically ChangeRepresentation: transform function 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 (pseudocode) 20

21 Function Trees and DFDs RepresentationChange: Construct a function tree and transform it to the actions of a DFD put tea in pot produce tea add boiling water composition wait produce tea put tea in pot Pot add boiling water store/file fetch tea from tea box open pot close pot wait action Cup 21

22 Decomposition of DFDs and Actions put tea in pot put tea in pot put tea in pot Fetch tea from tea box Pot Open pot fetch tea from tea box open pot close pot Pot Close Pot Pot 22

23 Data Flow in UML UML activity diagrams can also specify dataflow, but use a different syntax. put tea in pot put tea in pot put tea in pot Fetch tea from tea box Pot Open pot fetch tea from tea box open pot close pot Pot Close Pot Pot 23

24 Data Dictionary with EBNF In an SA model, the data dictionary describes the context free structure of the data For every edge in the DFDs, it contains a context-free grammar that describes the flowing data items Notation is also called Extended Backus-Naur Form (EBNF) Notation Meaning Example ::= or = Consists of A ::= B. Sequence + Concatenation A ::= B+C. Sequence <blank> Concatenation A ::= B C. Selection [ ] 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). 24

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

26 Adding Types to DFDs Nonterminals from the data dictionary become types on flow edges (Alternatively, types from a UML class diagram can be annotated) produce tea put tea in pot GreenTea add boiling water Water Pot wait TeaDrink Cup 26

27 Minispecs in Pseudo Code 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: 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 27

28 Good Languages for Pseudocode SETL (Schwartz, New York University) Dynamic sets, mappings Iterators PIKE (pike.ida.liu.se) Dynamic arrays, sets, relations, mappings Iterators ELAN (Koster, GMD) Natural language as identifiers of procedures Smalltalk (Goldberg et.al, Parc) Attempto Controlled English (ACE, Prof. Fuchs, Zurich) A restricted form of English, easy to parse 28

29 Structured Analysis and Design (SA/SD) - Heuristics Consistency checks Several consistency rules between diagrams (e.g., between function trees and DFD) Corrections necessary in case of structure clash between input and output formats 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) 29

30 Difference to Functional and Modular Design SA and SADT focus on the data-flow through a system Not on calls of functions Describe stream-based systems Lead to pipe-and-filter architectures Actions are processes SA and SADT can easily describe parallel systems Function trees can be turned into action trees (process trees) that treat streams of data 30

31 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 filter, connections are pipes System pipe Filter pipe Filter Filter 31

32 Examples Shell pipes-and-filters Image processing systems Signal processing systems (DSP-based embedded systems) The satellite radio Video processing systems Car control Process systems (powerplants, production control,...) 32

33 SADT Softwaretechnologie II, Prof. Uwe Aßmann 33

34 SADT Structured Analysis and Design Technique (SADT) is a action- and data-oriented method Uses a notation based on hierarchical graphs with 2 main forms of diagrams: Activity diagrams: Nodes are activities, edges are data flow (like DFD in SA) Data flow architectures result Data diagrams: Nodes are data (stores) and edges are activities Edges go mainly from left to right, top to bottom Companies used to have standardized forms, marked with author, date, version, name, etc.. 34

35 Diagrams SADT Control Data Control Activity Input Data Activity Output Data Generating Activity Data Consuming Activity Mechanism/ responsible Store 35

36 Example: The Waterfall Software Model with Activity Diagram of SADT Activity Diagrams SADT Similar to DFD Read direction left to right, top to bottom With designation of responsible Collect Requirements Requirements Engineer SRS Design Designer SD Implementation Program Programmer Waterfall Software Construction Maintenance Maintener 36

37 Refinement of Nodes Requirements Design Requirements Architectural Design Architect Architecture Design Detailed Design SD Designer 37

38 Data Diagrams SADT Lex. Grammar Grammar Tree Mapping Characters Compiler Tokens Buffer Pipe Syntax Tree Intermediate Code Memory Machine code File 38

39 Comparison SADT vs SA/SD SADT and SA/SD are 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 System-oriented methods are known in every discipline Object-oriented ones are not! SA-DFDs are more flexible as SADT actitity diagrams since the edge types are not used in a constrained way Function trees and DDs may be coupled with SADT 39

40 Why are 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! 40

41 What Have We Learned Use case diagrams are an action-oriented diagram notation that can be coupled with several design methods (action trees, communication diagrams) 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 41

42 The End 42