Data Flow Diagram" Answering many of these questions can be facilitated by allowing hierarchical decomposition"

Transcription

1 Computer Science 520/620 Spring 2011 Prof. L. Osterweil" Software Models and Representations" Part 2" Consistency is a principal concern" Are the diagrams consistent with each other?" Top view consistent with elaborations?" Arrows consistent" Data flows consistent" Other semantics?" Invitation to subtle errors" An Example: Elevator Software Representation" Modern elevators are controlled using software" Software is usually complex" Some issues the software must deal with:" Functionality"» Respond to all calls"» Coordination of multiple elevators"» Treat all calls fairly; donʼt make anyone wait too long" Speed"» Donʼt spend too much time optimizing"» Donʼt send people in the wrong direction" Safety"» Donʼt move elevator with doors open" What Representations Support Answering These Stakeholder Concerns" Buyer (Elevator Company)" Before development: What should it do?"» What does it mean to be fair to all riders?" During development: What will it do?"» What scheduling algorithm to use?"» How to coordinate multiple elevators?"» Is the project on time?" After development, before delivery: What does it do?"» Does it do what it was intended to do?" Software developer: How should it be developed?"» What is the system architecture?"» What scheduling algorithm to use?" User (rider): Why does it take so long? act so weird?" Safety Inspector: Is it safe?" Data Flow Diagram" Answering many of these questions can be facilitated by allowing hierarchical decomposition" Current Select New New Move Elevator New Get copy of Request List Request List Delete Request Just Satisfied Light New Request date Request List Button Press Turn on Light

2 Current Direction Hierarchical Elaboration (of Select New )" s in the right direction Process Request List Find Nearest New Rejection Consider Other Cars Request List Delete Selected Do dates to Move to New Status height" width" Simplified Case" height" width" width" >0" Check" args." Check args." valid" width" " args OK" valid" height" height" >0" " args t OK" height" > width" " valid pair" args OK" args t OK" Consistency is a principal concern" Are the diagrams consistent with each other?" Top view consistent with elaborations?" Arrows consistent" Data flows consistent" Other semantics?" Invitation to subtle errors" Service *" Service Oriented Software " Service Science" Service-based Development" ----" Service *" Service *" Service Oriented Software " Service Science" Service-based Development" ----" Service Oriented Software " Service Science" Service-based Development" ----" What do these things mean?" What do these things mean?" What are the problems in doing them?"

3 Consistency definitions" Data Flow Diagram" Let NodeAntation(n, somede) for some n N, where ParentGraph = (N, E)" Let somede = (Nʼ, Eʼ) " This is the DFG elaborating on somede " Some consistency properties" If {(mi, n)}, mi, n N, "then INPUT(somede) 0" If {(n, mi)}, mi, n N, "then OUTPUT(somede) 0" Maybe some others(?)" If {(mi, n)} = k, mi, n N, "then INPUT(somede) = k" If {(n, mi)} = k, mi, n N, "then OUTPUT(somede) = k" Current Button Press Select New Get copy of Request List New Request New Request List date Request List Move Elevator Delete Request Just Satisfied Turn on Light New Light Elaboration of Select New Suggests Artifact Issues" Current Direction Process Request List Find Nearest s in the right direction New Rejection Consider Other Cars Request List Delete Selected Do dates to Move to New Status Data needs precise specification too" DFD's focus on functionality, using data as a vehicle" Data shown as unstructured atomic units--usually unrealistic Complex functions cant be adequately defined without" delving into the details of how they handle structured data" Sub-DFD's can show how the high level data that high " level DFD's deal with is decomposed" --But this is implicit data definition" --Can be hard to read/inconsistent" Data specification is worth doing explicitly, carefully" Usually using Disciplined Natural Language--eg. templates" --Hierarchical relations" --Function(s) creating and using data" --Possible other attributes: " " "persistent? where? encoding?... " IDEF0" Commercial DFD formalism" Some formality and rigor behind it" Primarily pictorial" In wide use" Additional semantics in IDEF1, IDEF2, etc."

4 Note: The edges here do t comprise a set They comprise a collection." Broadening DFG Semantics" Node cant begin until data arrives along all in-edges" DFGNODE is set of des, {dfgdei} such that dfgdei is a function defined on the set of all artifacts IAi = {iai}, such that iai is an antation on an edge (dfgdej, dfgdei)" How to adapt this for " any semantics? " for output semantics?" exactly one Output de " Etc." More Broadening" Use of "open boxes" to indicate data store" --A different set, with different semantics" --Not a computation function" --Methods are: put, get, search(?)" Buy" LIBRARY" new" book" books" new " books" Borrow" a" book" These sorts of constraints can support additional types of reasoning: Eg. about parallelism

5 Still More Broadening" Kepler--Ather DFG Techlogy" Different shapes of boxes" Different pictures instead of boxes" Different colors" Different lines"." Central questions: What are the semantics? Does this really help? Or confuse? Data Flow diagram tation" Has hierarchical decomposition" Capability for specifying DFD semantics" For each diagram" Can be different at each level of hierarchy (!)" Based on Ptolemy II system" P. Baldwin, S. Kohli, E.A. Lee, X. Liu, and Y. Zhao. Modeling of Sensor Nets in Ptolemy II. in Proc. of Information Processing in Sensor Networks, (IPSN), April 26-27, 2004, pp What kinds of questions are well addressed by DFGs?" Overall structure of functional capabilities" What does this piece do?" System outputs and inputs" How might changes be made?" What functions create what data entities" Given that Precision is essential" What about the other three dimensions?" Detail" Gained from hierarchical elaboration" Breadth" Comes from different (sub)types of DFG" Clarity" Seems to be reduced by increased Detail and Breadth" With the need for Precision" Clarity helps appeal to diverse stakeholders" Users" Developers" Managers" Evolvers" Bystanders (?)" Final observations" Very primitive representation" "--very limited semantics" But actually more a family of model types" "--different sets of semantics" The actual relation(s) are rarely made clear and precise" Powerful aid to intuition and efficiency of communication" --Clear advantages over natural language" But is intuition misled by ambiguity, misinterpretation?" Does t help explain HOW things get done"

6 Control Flow Diagrams" Semantics are different from DFD's semantics" --Arrows represent flow of control, rather than flow of data" --Different shapes/types of boxes with different semantics" Basic control flow graph:" --Boxes represent functions" --Some other shape represents control flow alternation" --Arrows represent control flow: " If there is an arrow from circle A to circle B, it means" ImmFol: "the execution of B can immediately follow " the execution of A for some execution " --Different semantics for arrows between different shapes" --Still other shapes represent Start and Stop" --Use of hierarchy for elaborating boxes" Usual enhancements:" --Antate edges with predicates" --Special symbols for branching, concurrency control..." Control Flow Diagrams" Semantics are different from DFD's semantics" --Arrows represent flow of control, rather than flow of data" --Different shapes/types of boxes with different semantics" Basic control flow graph:" --Boxes represent functions" --Some other shape represents control flow alternation" --Arrows represent control flow: " If there is an arrow from circle A to circle B, it means" ImmFol: "the execution of B can immediately follow " the execution of A for some execution " --Different semantics for arrows between different shapes" --Still other shapes represent Start and Stop" --Use of hierarchy for elaborating boxes" Usual enhancements:" --Antate edges with predicates" --Special symbols for branching, concurrency control..." Control flow graphs also address questions like what does " " "this do and how does this do it " Example Control Flow Graph Semantics" Square boxes: Functions" Any number of inedges" One outedge" Edges: ImmFol relation" Function at head executes immediately after function at tail concludes" Round ovals: Branches/decisions" Each oval represents a Boolean function" For each oval there are exactly two outedges, labeled True and False" Example Control Flow Graph Semantics" FG = (FN, FE), where FN = OPS TEST and "OPS = {ops i } des where computation is done "TEST = {test i } des where tests are done" Edges: ImmFol relation "if (fe i, fe k ) FE then there is an execution path for which the execution of fe k immediately follows the execution of fe i " {(fe i, fe k } where fe i TEST = 2" {(fe i, fe k } where fe i OPS = 1" FG is a directed, connected graph" Maybe(?): FN = OPS TEST INPUT OUTPUT where" fn i OUTPUT ( fn i, fn k ) FE" fn i INPUT ( fn k, fn i, ) FE" Other semantics?" Read, Direction Control Flow Graph" DB_Read: curr-length, s(.), Directions(.) More Detail through Hierarchical Elaboration" incr <-- 1 Direction = N <-- ; increment N Directions[N] = incr? incr <-- -1 Complement Direction (Incr <-- -Incr) N out of bounds The challenges and solutions here are similar to those for DFGs" Need for consistency between levels" Semantics can be hard to define, stick to" other car is nearer? output new floor

7 More Breadth from more (sub)types of CFG" Concurrency graph with fork and join " T1" T2 Concurrency" Timing" 1" Data flow augmentations" Etc." 2" 3" call a" 4" 9 accept a Ra 5" Rendezvous Graph" Trace Flow Graph" T1! T2! " 8 3 Ra" 5 10" Rendezvous graph: RG = (N, E), where N = COMP SYNC" S SYNC S executes only after the execution of all C COMP such that (C, S) E" If (S, C) E, where S SYNC, then C cant execute until S has executed " T1! T2! " 8 3 Ra" 5 10" Explicitly represents interleaved execution " The green edges are the ImmFol relation" Double-headed arrows represent one arrow in each direction" Sync des are filled in black" Synch edges are blue Different variations to address different stakeholders and their needs" Focus on Clarity" More semantic issues" Different graph types for different issues " More detail" Hierarchy helps here" More clarity" Does more elaboration and more graph types help clarity or impede it?" CFG has more procedural detail" Does this help?" What about combining DFG and CFG?" Icography must be clear (?)"

8 Read, Direction Control Flow Graph" DB_Read: curr-length, s(.), Directions(.) Control Flow Graph with Data Flow" Read, Direction DB_Read: curr-length, s(.), Directions(.) Direction = Direction = incr <-- 1 N <-- ; incr <-- -1 incr <-- 1 N <-- ; incr <-- -1 increment N Complement Direction (Incr <-- -Incr) increment N Complement Direction (Incr <-- -Incr) Directions[N] = incr? N out of bounds Directions[N] = incr? N out of bounds other car is nearer? other car is nearer? output new floor output new floor Control Flow Graph with Data Flow" Read, Direction incr <-- 1 DB_Read: curr-length, s(.), Directions(.) Direction = N <-- ; increment N Directions[N] = incr? other car is nearer? incr <-- -1 Complement Direction (Incr <-- -Incr) N out of bounds What is Control Flow good/t good for?" Sense of what algorithms to use" Constraints on data appearing" eg. Assuming that the Request List is maintained in sorted order" Can estimate running speed" Can reason about functionality" Possible to strand requesters" Possible to take riders in the wrong direction" Drawbacks:" What about safety?" What about data?" output new floor Control Flow vs. Data Flow Graphs" What Stakeholders does this address?" Developers"???" Both shed light on similar questions" One focuses on data evolution, the other on functional development" Both are useful, neither removes the need for the other" Control flow graphs map closely to implementation code written in procedural languages. " Good basis for determining consistency of code with ideas exed as data flow" Data flow graphs focus more on the product itself, seem better at helping understand if and how it gets evolved" Seem better adapted to studying earlier formulations of the problem to be solved, and ways of solving it"

9 Finite State Machines (FSM's)" Finite State Machines (FSM's)" FSM = (Q, I, ), where" "Q = {qi}, the set of all possible system states" "I = {ij}, the set of all events that can affect the " " " "state of the system" " is a function, : Q x I Q such that if the system" " "is in state q and event i occurs, then the system" " "transitions to state (q, i)" Use of hierarchy can help add detail" "- But presents familiar consistency problems" Other definitions:" "Start state" "Accepting state" "Trap state" Why FSM's?" Primary appeal is visualizability--clarity" --Circles represent states" --(Curved) arrows represent transitions" --Arrows are antated with inputs" Intuitively: Can "watch" a stream of inputs "drive"" the behavior of the system as a sequence of movements" from state to state" Kinds of Questions FSMs seem adept at helping answer: What is a good way to think about the problem to be solved? What is the solution approach? How does this program work? No new request timeout Doors open, Elevator Stopped Finite State Machine" Doors Closed, Elevator Idle Request to Move to new floor Queue empty Request to Move to new floor Arrival at New Getting new floor request Doors closed Elevator in Motion Request to Move to new floor Doors open Elevator in Motion Request to Move to new floor Queueing new floor request Arrival at New Request to Move to new floor Finite State Machine for Digital Watch" Time display mode A Alarm display" mode" A A Datebook" mode" A Phone book" mode" Time set mode More Finite State Machine Details" B B Alarm set mode B B Time display mode A Alarm display" mode" A A Datebook" mode" A B Phone book" mode" Datebook set mode B C C B Phone book B C B Datebook query mode set mode B C Phone book query mode

10 More Complex FSMs" Statecharts: More Complex FSMs" State also specifies activities" Leans towards a CFG" Transition may involve computation" Considered to be instantaneous " Transition may be conditional" Event as well as a condition" Transition may emit events" To drive other FSMs" FSMs may be hierarchical" What exactly are semantics?" addstudent addstudent/ Initialize Open Unassigned numstudents = 0 do: Initialize course do: Assign professor entry: Register a object to course student registration closed[ registration closed[ numstudents < 3 ] Canceled numstudents > = 3 ] do: Send cancellation tices [ numstudents = 10 ] Closed do: Report RegistrationComplete course is full do: Generate class roster Statecharts: More Complex FSMs" Statecharts: More Complex FSMs" addstudent addstudent condition" on this" transition" Initialize do: Initialize course object Unassigned do: Assign professor to course addstudent/ numstudents = 0 Open entry: Register a student Initialize do: Initialize course object Unassigned do: Assign professor to course addstudent/ numstudents = 0 Open entry: Register a student Activity to be" performed in" this state" Canceled do: Send cancellation tices registration closed[ numstudents < 3 ] registration closed[ numstudents > = 3 ] Canceled do: Send cancellation tices registration closed[ numstudents < 3 ] registration closed[ numstudents > = 3 ] Closed do: Report course is full [ numstudents = 10 ] RegistrationComplete do: Generate class roster Closed do: Report course is full [ numstudents = 10 ] RegistrationComplete do: Generate class roster Statecharts: More Complex FSMs" Initialize do: Initialize course object Unassigned activity" on this" transition" do: Assign professor to course addstudent/ numstudents = 0 addstudent Open entry: Register a student Statechart with Nested States" superstate Initialize Register substate RegistrationComplete registration closed do: Generate class roster [ numstudents > = 3 ] Unassigned do: Assign professor to course Add student / numstudents = 0 Canceled registration closed[ numstudents < 3 ] registration closed[ numstudents > = 3 ] registration closed [ numstudents < 3 ] Open entry: Register a student addstudent do: Send cancellation tices [ numstudents = 10 ] Canceled Closed Closed do: Report course is full [ numstudents = 10 ] RegistrationComplete do: Generate class roster do: Report course is closed

11 What is FSM good/t good for?" Focus on specific issue: safety concern" Model unsafe state" Model state transitions" Can unsafe state be reached?" Drawbacks" No sense of functionality"» Unless additional semantics" No sense of how functionality achieved"» Except perhaps hierarchy" Hard to deal with concurrency"» Without additional semantics" Impossible to reason about timing" Petri Nets" More powerful and intuitive depiction of control flow strong on depiction of parallelism and concurrency" A Petri Net structurally consists of" A finite number of places" A finite number of transitions" A finite set of arrows that connect places to transitions (or vice versa)" If an arrow goes from a place to a transition, then place is said to be an input place of the transition." If an arrow goes from a transition to a place, then place is said to be an output place of the transition." Marking and Firing Petri Nets" A Petri Net place can be marked by the presence of a token" Any collection of places can be marked. " Any such marking is said to define a state of the Petri Net" Petri Nets proceed from one state to ather by means of a firing" Occurs only when every input place of a transition is marked with a token." The effect of the firing of a transition is to" Remove all of the tokens from the transition's input places" Put tokens in all of the transition's output places " Pressed Unmarked Petri Net" Not ed Pressed Petri Net Marked " With ed" Not ed Pressed Petri Net Marked " With ed" Not ed

12 Pressed Petri Net Marked " With ed" Not ed Unmarked n, going up Button n n, going up Car 1 Wins Race" n, going up Button n n, going up Car 1 Wins Race" n, going up Button n n, going up Car 1 Wins Race" n, going up Button n n, going up Car 1 Wins Race" n, going up Button n n, going up

13 Car 1 Wins Race" n, going up Button n n, going up Car 2 Wins Race" n, going up Button n n, going up Car 2 Wins Race" n, going up Button n n, going up Car 2 Wins Race" n, going up Button n n, going up Car 2 Wins Race" n, going up Button n n, going up Car 2 Wins Race" n, going up Button n n, going up

14 Petri Net for a Different Elevator" Marking for moving up to pick up a passenger" No Button No Button Move up to Nearest Button Move up to Nearest Button Down Down Marking for moving up to pick up a passenger" Marking for moving up to pick up a passenger" No Button No Button Move up to Nearest Button Move up to Nearest Button Down Down Marking for moving up to pick up a passenger" Marking for moving up to pick up a passenger" No Button Queues at places? No Button Move up to Nearest Button Move up to Nearest Button Down Down

15 Marking when passengers, but passenger " Marking when passengers, but passenger " No Button No Button Move up to Nearest Button Move up to Nearest Button Down Down Marking when passengers, but passenger " Marking for both up and down s" No Button No Button Move up to Nearest Button Move up to Nearest Button Down Visit floor Down Visit floor Marking for neither up r down s" Move up to Nearest Button Visit floor Down Visit floor No Button Evaluation of Petri Nets" What are Petri Net representations good for?: How do things get done?" Especially parallelism and ndeterminism" Helps spot races and deadlocks" What kinds of things are Petri Nets t good for? Too little focus on product (tokens represent it)" Many extensions:" --Hierarchical Petri Nets" --Colored tokens" --"Or" transitions" --Queues at places" Too many extensions confuse the picture? "

16 Combinations of Representations" Different representations give different views, support providing answers to different questions" But different views must all be consistent with each other" One way to assure this: superimpose different views atop each other" Control/Data flow diagrams" Call/control flow charts" FSMs with activities too" Diagrams augmented with natural language"» Example: RSL" Risk of too much clutter, Can be self defeating" Ather way: Coordinated sets of representations" Need to assure that all the different representations are consistent with each other--represent the same thing " Kepler--Ather DFG Techlogy" Data Flow diagram tation" Has hierarchical decomposition" Capability for specifying DFD semantics" For each diagram" Can be different at each level of hierarchy (!)" Based on Ptolemy II system" P. Baldwin, S. Kohli, E.A. Lee, X. Liu, and Y. Zhao. Modeling of Sensor Nets in Ptolemy II. in Proc. of Information Processing in Sensor Networks, (IPSN), April 26-27, 2004, pp A Kepler Example" Kepler Elaboration" Multirepresentation Systems" Have seen that different representations are of different uses" One diagram may be useful in different ways to different stakeholders" But most stakeholders require a variety of diagrams" Several different diagrams can be expected to be needed to satisfy the different stakeholders" Problems with different views/diagrams" Are they all representing the same software product?" How to assure that they are all consistent with each other?" If the product changes, then ALL views must change correspondingly" Multiple Views"

17 Platoʼs Cave" RSL/REVS" Reference: Bell, Bixler, Dyer, IEEE TSE SE-3 #1 pp " Enhanced DFD's (called RNET's)" --Functions called ALPHA's" --ALPHA's can be defined hierarchically" --Structured English as well as pictorial diagrams" --Diverse set of attributes used to enhance ALPHA defs." --Logical connectives on arrows" Balanced by facilities for defining data (called DATA's)" --Defined hierarchically" --Output from/input to specs are dual of ALPHA info." Supports consistency checking through redundancy" --Redundancy to check for consistency and quality" Designed to help specify reactive systems" --Dataflow diagrams are particularly good at that (?)" Other Features (more peripheral to this discussion)" --I/O specifications" --Requirements tracing (why is that requirement here?)" STATEMATE" Elaborate enhancement of FSM's" Augmented by other views (e.g. activity Diagrams)" Key feature is maintenance of consistency among views" Done by projecting views of text (language)-based model" References" Harel et al., "STATEMATE: A Working Environment for the Development of Complex Reactive Systems" Proc. 10th Int'l. Conf. on Software Engineering, Singapore, 1988, pp " Harel et al., STATEMATE: A Working Environment for the Development of Complex Reactive Systems:, IEEE Trans. On Software Engineering (IEEE TSE), v. 16, #4, April 1990, pp " Harel and Naamad, The STATEMATE Semantics of Statecharts, ACM Trans. On Software Engineering Methodology (TOSEM), v.5 #4, Oct " Commercially available software system" " Multiple Views in Statemate" Rationale for multiple views: Too much information in a" single diagram creates clutter, confusion, defeats clarity" Advantage of multiple views: Each represents a different" viewpoint, different model, with a different diagram--easier" to grasp the model" Disadvantage: Reader needs to synthesize views, assure" that they are really consistent with each other" Three views in Statemate:" --Module Charts (a hierarchy representing capabilities)" --Activity Charts (hierarchical dataflow charts)" --Statecharts (hierarchical finite state machines)" All charts are derived from textual input, facilitated by use of" tools prompting user via forms" Three Statemate views depict some different views, but also" overlap with each other: facilitates cross-checking for " consistency and easier comprehension" Multiple Views in Statemate" Activity view Multiple Views in Statemate" Module view Statechart view Module view Activity view Statechart view Textual view Textual view