17
The Trouble with Dataflow Diagrams Requirements Low-Level Design Code Test High-Level Design Where does output go? What causes this rework? What portion of activity should be done? How do we break this cycle? What to do when reviews fail?

25
Questions Requirements Low-Level Design Code Test High-Level Design Where does output go? What causes this rework? What portion of activity should be done? How do we break this cycle? What to do when reviews fail?

29
The BOOD (Booch OO-Design) Process as an example Notation –Class diagrams, state transition diagrams, interaction diagrams,... Method: –Identify classes and objects –Identify semantics of classes and objects –Identify relationships between classes and objects –Specify the interface and implementation of the classes and objects What BOOD is:

30
What BOOD Doesn’t Address Only describes the “nominal” process –Doesn’t address how to handle non-nominal conditions (exceptions) Only describes “design-in-the-small” –Design “in the large” is not addressed General lack of precision Does not address collaboration –Much design is done by teams Does not address configuration management –How to handle design evolution

35
Four different continuations on exception handlers Complete –Handler was a “fixup” and now it is OK to go back Continue –Handler brought step to an acceptable postcondition state and it is OK to go on Restart –SNAFU. Handler cleaned up mess, now OK to redo Rethrow –Go up to parent and hope the parent knows what to do

36
Prerequisites and Postrequisites Test before/after execution of a step Requisites are themselves entire steps Program what to look for, in what order, and distinguish among responses for various contingencies Uses exception handling to respond to failures

37
Assessing Milestones Using Postrequisites In BOOD, defined as conditions on the product In Little-JIL, represented with postrequisites on steps DevelopInterfaceFiles InterfaceFilesCompile InterfaceFilesDo ntCompile

38
Real Time Specification Each step may have a deadline specification Exception thrown when step execution exceeds deadline Scheduling algorithms can detect when a step’s substep structure is unschedulable –Exception is thrown

39
Examples of Resources Input artifacts: requirements document, locks on key artifacts People: designers with varying skills Tools: ROSE Agents: Each step has a distinctly identified unique resource responsible for execution of the step (and all of its substeps)

46
Requirements Low-Level Design Code Test High-Level Design Where does output go? What causes this rework? What portion of activity should be done? How do we break this cycle? What to do when reviews fail? Remember These Questions

52
Process Execution Often (unfortunately) referred to as process enactment One clear goal of process implementation (coding) --although not the only goal Execution is on a "virtual machine" consisting of --process program code --software tools --humans Process execution tends to run for a very long time --Months or years Process code changes itself as it executes Process execution is different from product execution in interesting ways (eg. assumptions about the underlying machines have to be different)

53
Process Execution Support With Process Centered Environments Code processes in executable languages –Code in flexibility, freedom for humans as desired Compile and execute them Support from a (distributed, concurrent) environment infrastructure and toolset –The process as an integration rationale Can the process really help humans by –taking onerous work off our backs? –leaving us more free to do what we do best? –providing support and direction as desired?

55
Process Maintenance (Process Improvement) Process maintenance takes place over an extended period of time--can be expected to be more costly and important than process development Improvement efforts should always be relative to stated goals Process Improvement aimed at progress towards process requirements and improvement goals Improvement progress must be measured to assure progress is made and improvement is underway These argue for the importance of process requirements specification and precise process measurement Greater rigor can lead to more effective improvement

59
Focus on Process Quality Is the process correct? –Errors will happen very fast –When will humans notice/correct them? Is the implementation in code correct? How fast will the process run? How to be sure that humans perform their jobs? –Train them, monitor their participation Are resources adequate, efficiently used? How to improve the process –And be sure that changes are improvements?

62
Process Precision is Key to Determining /Assuring Quality Precise process definitions can be: –Analyzed To prove desired properties ( they are correct) To find flaws (or prove there are none) To compare them to competing processes –Repeated Aid in training –Improved Not just changed –Used to integrate new agents and subprocesses –Automated as desired

72
Results Modeling Little-JIL step semantics was complex in some cases (eg. the choice step kind) Modeling dataflow and resource specification was subtle at times Process flowgraphs were large and complex FLAVERS was quite capable of performing analyses