Where Have We Been? Scheduling - Periodic Tasks Scheduling - Sporadic Tasks Communication and Synchronization What Now? Software Engineering Software Life Cycle Specification Methods Flowcharts State Transition Diagrams Data Flow Diagrams Structure Charts Petri Nets Software Engineering - 1 Real-Time Systems
Software Life Cycle (Software Engineering) Ideal Waterfall Model Concept Requirements Design Programming Test Maintenance Software Engineering - 2 Real-Time Systems
Software Life Cycle Phases Concept Phase need and goals management directive, customer input, technology, etc. features and feasibility (design and testing) Requirements Phase Software Specification timing, accuracy, user interface, etc. software/hardware interfaces testing plan budget and schedule Functional and Non-functional requirements Complete, correct, consistent, testable Software Engineering - 3 Real-Time Systems
Software Phases (cont.) Design Phase Convert Requirements to Detailed Design Spec. Module partitioning Programming Phase convert to code, incremental test, documentation Test Phase Formal test cases, meets the spec? Maintenance Phase customer support, bug fixes Software Engineering - 4 Real-Time Systems
The Real Software Life Cycle New Product Concept Phase Cannot Specify Maintenance Phase Testing Phase Programming Phase Requirements Phase Design Phase Feature not Feasible Feature not Feasible Feature not Feasible Error Detected in Concept Validate suspected problem Feature not Feasible Error Detected in Requirements Error in Design Design not Feasible Error in Coding Software Engineering - 5
Software Specification and Design Natural Languages Required, but should be redundant Mathematical Specification Precise, maps to code, provable (?) Flowcharts Well understood, but promotes use of GOTO Parallel flow interaction not easily represented Timing issues difficult to represent Software Engineering - 6 Real-Time Systems
Natural Language (Print Spooler) When started, the print spooler must first initialize a queue of print objects (file pointers) and check the print queue backup file in case there was a system crash or other exit condition. If the backup file is not empty, load the queue from the backup file, maintaining order. If the queue could not be initialized, alert operator and exit. If the printer is not busy, set the busy flag to false. Assume a semaphore mechanism exists and block. (This could be a polling loop testing some pre-defined operating system flags.) If it unblocks on a request to print, queue the job and update backup file. If printer is not busy, send the job to the printer, else block. If the queue is full, alert the requestor and block with no change to queue. If it unblocks on printer done, check the queue and either send the next job and update backup file or set busy false. If printer error, alert operator. All cases block. If unblock on exit request, quit. Software Engineering - 7
Flowchart (Print Spooler) Start Init Queue Load Queue no Queue OK? yes Backup Empty? yes Block on Semaphore no Update Backup unblock == done? no Dequeue Print unblock == exit? yes Enqueue Stop Software Engineering - 8
State Transition Diagrams State (circle) Represents equilibrium points of the system Transitions (arrow) Changes of state Occurs when condition is met Actions are taken during transition System must have Discrete States Determine What Events Cause Changes in State Mealy = output during transition Moore = output within state Software Engineering - 9
State Transition Diagram (Print Spooler) Start error Init success Wait queue error queued, busy print request Queue exit request error printer done no job, busy = false sent, busy=true Print queued, printer not busy Exit Software Engineering - 10
Structure Charts Calling Trees Left-to-Right implies: Execution order Top-to-Bottom implies: Increasing detail o - denotes conditional execution * - denotes repetitive execution Jackson Extensions Represents program flow, not data flow Example in [PL] text is poor Software Engineering - 11
Structure Chart (Beverage Vending) Dispense Beverage* on Demand Accept coins Accept choice Dispense cup Make Beverage Brew Beverage Dispense Additives o o o Coffee Decaf Tea Dispense Grounds Dispense Hot H2O Mix Software Engineering - 12
Where Have We Been? Scheduling Algorithms Communication and Synchronization Software Engineering ([PL] Chapter 5) Software Life Cycle Software Specification Natural Language Flowcharts State Transition Diagrams (FSM) Structure Charts Where are we headed? More Software Engineering Software Specification Dataflow Diagrams Petri Nets Statecharts Software Engineering - 13
The View from Above Informal Specification Methods Intuitive to non-technical people Difficult to prove anything Natural Language Flowcharts Structure Charts Semiformal Specification Methods Easy to learn, but requires training Some rigor Dataflow Diagrams ([PL] construction) Formal Specification Methods Difficult to learn Rigorous and provable State Transition Diagrams Petri Nets Statecharts Software Engineering - 14
Dataflow Diagrams Analyze Data Flow Through System and Determine Major Functions Emphasizes Flow of Data Shows Concurrency Explicitly Does Not Show Synchronization (implicit at best) Process Sink/Source Data Store Data Flow (Data Transformation) Software Engineering - 15
DFD Example [PL] Raw Comp. Comp. Gyro Raw Gyro Comp. Comp. Compensated Data Calc. Pos. Position Attitude Gyro Pos, Att,... Torque Gyro Data Update Display Gyro Cmds Position Attitude eration Screen Data Display and Gyro Compensation are Concurrent Synchronization of Comp. Data is only Implied Hierarchies of DFDs Provide Process Details Describes What the System Does, not When Software Engineering - 16
Improved DFD Example [PL & JC] Raw eration Update Display Screen Data Display Comp. Comp. Compensated Data Calc. Pos. Position Attitude Pos, Att Position Attitude Comp. Gyro Comp. Raw Gyro Gyro Data eration Torque Gyro Cmds Fixed some bugs in the [PL] diagram (magenta) Use of Data Stores more closely match [JC] definition Eliminated redundant stores eration input to Torque matches natural language spec. Software Engineering - 17
Doubly Improved DFD Example [PL & JC] Raw Comp. Comp. eration Compensated Data Calc. Pos. Position Attitude eration Position, Attitude Pos, Att Update Display Screen Data Position Attitude Display Comp. Gyro Comp. Raw Gyro Gyro Data eration Torque Gyro Cmds Added Likely Information to Better Justify Data Stores This info is not explicitly in the spec but it makes the meaning clearer (left out to simplify the example) Reinforces their existence as true Data Stores (not just temporary variables) Software Engineering - 18
Control Flow Diagrams Analyze Control Flow (Events and Actions) and Determine Their Dynamics Emphasizes Flow of Control Control Transformations Represented by Attached State Transition Diagrams Dynamic Behavior is Explicitly Indicated Control Transformation Events and Actions Control Store Software Engineering - 19
Real-Time DFD Link CFD with DFD Introduce Synchronization Prompts Enable/Disable Prompt - on until off ed Trigger Prompt - one shot Activator Prompt - active for duration of state L prompt label (E,T,A) Prompt (Note double-arrow meant continuous time in DFD) Prompts Couple CFD to DFD Software Engineering - 20
Real-Time DFD Example Raw Comp. Comp. T eration Compensated Data Calc. Pos. Position Attitude eration Position, Attitude Pos, Att Update Display Screen Data T Position Attitude Display Comp. Gyro Raw Gyro Comp. T T Gyro Data eration Torque Gyro Cmds 5ms Tick Compensate Gyro Control Transform Compensate Calculate Position Update Disp. Torque T STDs Software Engineering - 21
STDs for Real-Time DFD Example Count Ticks Modulo 8 8th Tick reset counter T: comp. accel. T: comp. gyro T: calc. pos. T: torque gyros Other Tick inc. counter T: comp. accel. 200th Tick reset counter T: update display Count Ticks Modulo 200 Other Tick inc. counter Other Topologies Possible Software Engineering - 22
Petri Nets Formal Method for Multitasking and Synchronization 2 Places Nodes Transitions Inputs Outputs Marks Tokens Initial Marking Indicates How the Net Starts P1 T1 T1 P1 P2 P2 2 1 Transitions Fire if all Inputs have a Token Tokens are Consumed and Produced by Transitions Software Engineering - 23
Petri Net Example [PL] P1 T1 T1 P2 P1 P2 Produced P1 T1 P2 Before Firing Table 1: Firing Table epoch P1 P2 m 0 2 1 m 1 1 1 m 2 Consumed After Firing All Transitions are Synchronized Transitions Triggered by Event such as Clock Software Engineering - 24
Multiple Transitions Example [PL] P1 1 P2 1 T1 T2 P3 T3 P4 2 0 Multiple Transitions are Enabled Simultaneously Evaluate All Transitions to See Which Fire Software Engineering - 25
Petri Nets Can Be Non-Deterministic P1 T1 P4 P2 T2 P5 T4 P7 P3 T3 P6 What Transitions are Enabled? Can Both T2 and T3 Fire? Beware the Errant Token Software Engineering - 26
Associating Entities with Tokens and Transitions [PL] a,a,a P1 Multiply T1 P4 2 P2 Multiply T2 P5 Add T4 P7 bi,bi,bi P3 Multiply T3 P6 Complex Multiplication: (a+bi)(a+bi) = a 2 - b 2 + 2abi Tokens: intermediate results (variables) Transitions: operations Creation of tokens tied to external event Software Engineering - 27
Escort Tokens and Inhibitors Basic production facility (conveyor contention) Loading Dock Staging Area Work Station Finished Inventory Staging Area Loading Dock unload truck transport assemble transport load (conveyor in) (conveyor out) truck Escort token to eliminate conveyor contention Loading Dock Staging Area Work Station Finished Inventory Staging Area Loading Dock unload truck transport assemble transport load (conveyor in) (conveyor out) truck Software Engineering - 28
Escort Tokens and Inhibitors (cont.) Inhibitor to protect only conveyor (not entire station) Loading Dock Staging Area Work Station Finished Invent. Staging Area Loading Dock unload truck transport assemble transport load (conveyor in) (conveyor out) truck To deal with finite time transitions, add done indicator that produces a token Loading Dock Unloading Truck Staging Area start unloading finish unloading Done Button Software Engineering - 29
Elements of Statecharts Finite State Automata Depth - states inside states (hierarchical) Orthogonality - concurrent processes Broadcast Communications - synchronization Software Engineering - 30 Real-Time Systems
Unified Modeling Language Aimed at Object-Oriented Systems Design Independent of Design Process Modeling Language (semantics and notation) Process of Application of that Language UML s Characteristics Semi-formal Language Discrete Systems (vs. continuous) based on finite state machines semantics ==> meaning syntax ==> representation of semantics Software Engineering - 31 Real-Time Systems
UML Components 3 Distinct Models Requirements Model Black box, hiding implementation Actors and use cases (external to system) Structural Model Classes and how they collaborate Associations among classes Components (executables) and nodes (CPUs, I/O, etc) Behavioral Model Statecharts Refs: Real-Time UML, Douglass, Addison Wesley UML for Systems Engineering, UML s Shortfalls in Modeling Complex Real-Time Systems, 11/98 Computer Design Software Engineering - 32