“软件过程也是软件”

1. “软件过程也是软件” • 美国麻省 Amherst大学计算机科学系 奥斯特威尔教授（Prof. Leon Osterweil）和 他的夫人克拉尔克教授(Prof. Lori Clarke) 都是世界著名的软件工程专家。 • “软件过程也是软件”的名言就是他1987年在第九次世界软件工程学术会议上提出的。 • 我们通过日本岸田孝一先生（我校兼职教授）邀请他们今年 10月19日到我校作严格的软件过程定义和软件分析的学术报告，我校博、硕士研究生和高年级学生都可听讲，这对我校的研究工作会有重要的推动作用。

2. 奥斯特威尔教授Prof. Leon J. Osterweil美国麻萨诸塞大学(阿姆赫斯特)自然科学和数学院院长计算机科学系教授 Professor, Dept. of Computer Science Dean, College of Natural Sciences and Mathematics University of Massachusetts Amherst, MA 01003 USA ljo@cs.umass.edu URL: laser.cs.umass.edu

3. Automating and Reasoning AboutPrecise Process Definitions

4. What do we mean by “process” • Activities like development, verification, evolution, etc. of (eg.) software products • High level processes: • Develop requirements, Do Object Oriented Design, Formally verify • Low level processes • Archive test results, Verify a lemma • Often concurrent • Often coordinate people, automated systems • Often resource sensitive • Usually (regrettably) informal or undefined

5. My interest in process:Assuring quality products • Superior quality products from superior processes • Build quality in, don’t “test in” quality (manufacturing) • Many observed “process errors” • Real processes are intricate • Machines can help people with processes • Process effectiveness from human/machine synergy

6. Other Reasons for Interest in Process • Communication • Coordination • Intuitive understanding • Verification • Training • Automation • Deep understanding • Etc.

7. Appropriate Definition Notation is Key • Different formalism approaches support different goals • Formalisms vary in • Rigor • Precision (semantic detail) • Semantic scope • Clarity Which formalisms are effective in demonstrably supporting the building of quality into software products?

8. Processes are software

9. Processes are software They should be Engineered

10. Processes are software They should be Engineered Using appropriate languages

11. Software Processes as Software • Consist of: • Process Requirements, the basis for • Designing processes, Evaluation and improvement of process • Process Specification/Modeling/Design • Helps conceptualization, visualization • Process Code • Provides rigor and complete details • For execution and tool integration • Process Measurements and Evaluation • Basis for.… • Process Maintenance (Improvement) • Develop software processes using a(SW development process) development process

12. Process Definition Approaches • Natural language • Structured Natural Language • Pictorial representations • DFDs • FSAs • Petri Nets • Object Technologies • Programming languages Directly analogous to product definition approaches Different approaches for different Phases Purposes

13. Data Flow Diagram ofTraditional Waterfall Model Requirements High-LevelDesign Low-LevelDesign Code Provides useful intuition (?) Test

14. This Elaboration Raises OtherTypes of Questions Requirements High-LevelDesign Low-LevelDesign Code Test

15. The Trouble with Dataflow Diagrams Where does output go? Requirements What to do when reviews fail? What causes this rework? High-LevelDesign What portion of activity should bedone? Low-LevelDesign Code Test How do we break this cycle?

16. Defining Processes with Code • More traditional coding languages: --Procedural (Sutton's Appl/A) --Rule-based (Kaiser's Marvel) --Functional Hierarchy (Katayama’s HFSP) --Law based (Minsky) --Object Oriented (schema definition languages) Have all been tried each has strengths, weaknesses

17. Key Issue: What kind of Language? • Which formal approaches support which process goals? • Reasoning, verification • Automation • Human intuition • Are there abstractions that can support several or all? • Language(s) that exploit such abstractions

18. The Little-JIL Process Language • Vehicle for exploring language abstractions for • Reasoning (rigorously defined) • Automation (execution semantics) • Understandability (visual) • Supported by • Visual-JIL graphical editor • Juliette interpreter • Evaluation by application to broad domains • A third-generation process language • A “work in progress”

19. The “Step” is the central Little-JIL abstraction Interface Badge (includes resource specs) Prerequisite Badge Post requisite Badge TheStepName Z X Handlers Substep sequencing Reactions

20. RegressionTest GetArtifacts ReportResults Stop PerformTest SelectTests Stop PerformTest Report Failure ExecuteTest GetExecutable GetTest Cases NoteFailure Compare Results Get Input Data Run Test Get Expected Output Data Little-JIL Example:“Smart” Regression Test Process

21. Use “classical” OO-Design in examples Assume “classical” OOD is: • Notation • Class, state transition, interaction diagrams, ... • Method: • Identify classes and objects • Identify semantics of classes and objects • Identify relationships between classes, objects • Specify the interface and implementation of the classes and objects

22. Usually not Addressed are-- • The non-nominal conditions (exceptions) • Only describes the “nominal” process • Design “in the large” • Only describes “design-in-the-small” • Specifics of collaboration • Much design is done by teams • Configuration management • How to handle design evolution • General lack of precision

23. Sequential In order, left to right Parallel Any order (or parallel) Choice Choose from Agenda Only one choice allowed Try In order, left to right Little-JIL Proactive Flow Specified by four Sequencing Kinds Iteration usually through recursion Alternation using pre/post requisites

24. Example of Choice and Try Step Kinds Implement Reuse_Implementation Custom_Implementation Look_for_Inheritance Look_for_Parameterized_Class Look_for_Objects_to_Delegate_to Main Goal: Support Human flexibility

25. Reactive Control through Scoped Exception Handing • Steps may have one or more exception handlers • React to exceptions thrown in descendent steps • Handlers are steps themselves InterfaceFilesDon’tCompile DevelopInterfaceFiles InterfaceFilesCompile

26. 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

27. 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)

28. Bob Resource Human Design Team Carol Hardware Ted Software Alice Data Manager PC Class Sparc Designer Schedulable Class Instance Resource Model:Is-A Relationships

29. Bob Resource Human Design Team Carol Hardware Ted Software Alice Data Manager PC Sparc Designer Resource Model:Requires Relationships

30. Bob Resource Human Design Team Carol Hardware Ted Software Alice Data Manager PC Sparc Designer Resource Model: Requires andWhole-Part Relationships

31. Resource Request Example Agent: OODDesigner;expert tool: ClassDiagramEditor artifact: DiagramReposLock IdentifyRelationships SpecifyRelationships RefineRelationships Resource request is a query on the Resource specification repository

32. Remember These Questions? Where does output go? Requirements What to do when reviews fail? What causes this rework? High-LevelDesign What portion of activity should bedone? Low-LevelDesign Code Test How do we break this cycle?

33. High-Level Process

34. Trivial Example Elaboration of Requirements Step

35. Trivial Example Elaboration of Design Step

36. Requirements Rework

37. Requirements Rework Invocation of step originally defined as substep of Requirements

38. Requirements Rework Same exception thrown Invocation of step originally defined as substep of Requirements

39. Requirements Rework Same exception thrown Invocation of step originally defined as substep of Requirements Different invocation context -> different response

40. Implications for Process Languages • Procedure invocation semantics needed • Define once, reuse in varying contexts • Use of abstraction • Can’t define “rework” without it • Rarely found in pictorial notations • Possible (ungainly) in UML

41. Juliette: The Little-JIL Interpreter • Juliette is distributed • Every step has its own interpreter • Interpreter executed on agent’s platform • Communication via Agendas • One for each agent and service • Services include: • Object Management • Resource Management • Step sequence Management • Agenda Management

42. Achieving Product QualityThrough Quality Processes • Rests upon the ability to reason about process characteristics effectively • Analogous to software product measurement and evaluation • Dynamic monitoring of process execution is analogous to interactive debugging of application software • Need static analysis of processes too

43. Process Reasoning Examples • Is the process correct (eg. consistent with rqts.)? • Important failures may happen very quickly • When will humans notice/correct them? • 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?

44. The Capability Maturity Model (CMM)is a Specific Approach to Software Process Improvement

45. The Capability Maturity Model (CMM)is a Specific Approach to Software Process Improvement It is a test plan for black box testing of processes

46. The Capability Maturity Model (CMM)is a Specific Approach to Software Process Improvement It is a test plan for black box testing of processes Can’t test quality into software process products either

47. Status • Little-JIL 1.0 described in a TR • V. 2.0 nearing completion • Visual-JIL relatively stable; distributable • Juliette: A research prototype; friends only • Resource manager prototype • Agenda system prototype • Automatic flowgrapher not implemented

48. Key Challenges • Process Language • Visualization • Clean definitions of abstractions • Process execution • Efficient, robust execution • Effective reasoning engines • Careful evaluation • Application in various domains • Measurement and evaluation