Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Preparation and Planning for ICSE 2006 (28th International Conference on Software Engineering)

Similar presentations


Presentation on theme: "Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Preparation and Planning for ICSE 2006 (28th International Conference on Software Engineering)"— Presentation transcript:

1 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Preparation and Planning for ICSE 2006 (28th International Conference on Software Engineering) Leon J. Osterweil (ljo@cs.umass.edu) University of Massachusetts Amherst, MA 01003 USA SinoSoft 2003 Beijing, China 3 December 2003

2 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Who am I? Professor of Computer Science –University of Massachusetts, Amherst Software Engineering Researcher –Software Process Definition –Software Analysis Dean, College of Natural Sciences & Mathematics General Chair, ICSE 2006 –28th Int’l. Conference on Software Engineering

3 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Why Are We (with Mary Lou Soffa) Here? Plan for ICSE 2006 Meet Research colleagues Plan events leading up to ICSE 2006 Support Chinese initiatives in software engineering

4 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 What is ICSE? Largest, most important, meeting on Software Engineering Research –Also covers practice, history, future Actually a set of colocated meetings –Many accompanying workshops –Many tutorials Usually 1000-1500 attendees Held annually around the world –In US in odd-numbered years –In Europe every four years Previous Asian meetings –Tokyo, Osaka, Singapore

5 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Past ICSEs Washington San Francisco Atlanta San Diego Orlando Monterey, CA Pittsburgh Austin Baltimore Seattle Boston Los Angeles Portland St. Louis (2005) Munich, Germany Tokyo, Japan London, England Singapore Nice, France Melbourne, Australia Sorrento, Italy Berlin, Germany Osaka, Japan Limerick, Ireland Toronto, Canada Edinburgh, Scotland (2004)

6 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 ICSE 2006 In Shanghai –First time on Asian continental mainland General Chair –Leon J. Osterweil Program CoChairs –Mary Lou Soffa –Dieter Rombach Organizer –Prof. Dehua Ju

7 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Component Structure of ICSE Main Conference –Three days, 4-5 parallel tracks Satellite conferences –2-3 smaller ones, both before and after ICSE Many workshops –12-15, mostly one or two days before ICSE –30-60 attendees Many tutorials –As many as 25 –Both before and after ICSE Tools/trade exposition (?) –If there is interest

8 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Possible Events Prior to 2006 In 2005 –One large (200 attendees?) conference in Shanghai –One or more workshops around China In 2004 –Research seminars in Beijing and Shanghai –Research tutorial series around China –Workshop somewhere in China

9 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 What are our research interests? Leon Osterweil –Software Process –Software Analysis Mary Lou Soffa –Software Analysis, Testing, and Debugging –Compilers and Optimizers Dieter Rombach –Empirical Methods –Reviews and Walkthroughs

10 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Research Interests Leon J. Osterweil

11 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 What do I 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

12 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 My interest in process: Reasoning to assure quality products and services Superior quality products from superior processes –Build quality in, don’t “test in” quality (manufacturing) –Many observed “process errors” Real processes are intricate Automation can help/support Reasoning to assure quality in processes –Simulations support reasoning –Other approaches too (eg. static analysis)

13 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Other Reasons for Interest in Process Communication Coordination Intuitive understanding Prediction/projection Verification Training Automation Deep understanding Etc.

14 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Appropriate Modeling 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 which kinds of reasoning?

15 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Processes are software

16 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Processes are software They should be Engineered

17 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Processes are software They should be Engineered Using appropriate languages

18 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Directly analogous to product definition approaches Different approaches for different Phases Purposes Process Definition Approaches Natural language Structured Natural Language Pictorial representations –DFDs –FSAs –Petri Nets Object Technologies Programming languages

19 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Process definition language issues Blending proactive and reactive control Coordinating human and automated agents –Without favoring either Specification of resources Exception management Real time specification

20 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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”

21 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Little-JIL Example: “Smart” Regression Test Process RegressionTest GetArtifacts GetExecutable GetTest Cases PerformTest ExecuteTest Report Failure SelectTests Stop ReportResults Get Input Data Get Expected Output Data Run Test Compare Results NoteFailure

22 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 The “Step” is the central Little-JIL abstraction TheStepName Interface Badge (includes resource specs) Prerequisite Badge Postrequisite Badge Substep sequencing Handlers X Z Reactions

23 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Trivial SW Development Process

24 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Trivial Example Elaboration of Requirements Step

25 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Trivial Example Elaboration of Design Step

26 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Requirements Rework

27 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Requirements Rework Invocation of step originally defined as substep of Requirements

28 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Requirements Rework Invocation of step originally defined as substep of Requirements Same exception thrown

29 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Requirements Rework Invocation of step originally defined as substep of Requirements Same exception thrown Different invocation context -> different response

30 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 What does this tell us? Abstraction/reinstantiation is necessary –For an adequately articulate language –For clear understanding of “rework” Other language features similarly motivated By specific examples and experiences

31 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Iteration usually through recursion Alternation using pre/post requisites Little-JIL Proactive Flow Specified by four Sequencing Kinds 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

32 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Example of Choice and Try Step Kinds Implement Look_for_Inheritance Look_for_Objects_to_Delegate_to Look_for_Parameterized_Class Custom_Implementation Reuse_Implementation Main Goal: Support Human flexibility

33 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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 DevelopInterfaceFiles InterfaceFilesCompile InterfaceFilesDon’tCompile

34 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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

35 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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)

36 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Resource Model: Requires and Whole-Part Relationships Resource HumanHardwareSoftwareData Manager Designer PC Sparc Design Team BobCarolTedAlice

37 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Resource Request Example IdentifyRelationships SpecifyRelationshipsRefineRelationships Agent: OODDesigner;expert tool: ClassDiagramEditor artifact: DiagramReposLock Resource request is a query on the Resource specification repository

38 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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

39 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Achieving Product Quality Through Quality Processes Thru reasoning about process characteristics Analogous to software product measurement and evaluation –Dynamic monitoring of process execution like interactive debugging and tracing Simulations can be predictive Tracing provides audit trails –Need static analysis of processes too Prove absence of pathologies

40 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Process Reasoning Examples Is the process correct (eg. consistent with rqts.)? 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? Simulations can spot problems Static analysis can verify for all executions

41 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 The Capability Maturity Model (CMM) is a Specific Approach to Software Process Improvement

42 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 The Capability Maturity Model (CMM) is a Specific Approach to Software Process Improvement It is a test plan for black box testing of processes

43 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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

44 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Current Evaluation Projects Software Development: –Perpetual testing: Programming flexibly evolvable integrated testing and analysis –Configuration Management –Collaborative Object Oriented Design –Performing data flow analysis processes Robot coordination Distributed scientific statistical data processing Medical and Nursing processes Ecommerce processes such as auctions Egovernment processes

45 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Robot Coordination Process

46 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Scientific Statistical Data Processing How do scientists do their work? –Reproducing results is core of all science Should help in reproducing results Evidence this this has been done (dynamic) Determine if there are any statistical processing pathologies –Avoid false “findings”

47 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Produce a 3-D Forest Model Creates “new” versions of the fly-over data Maybe plan a fly-over, maybe just get a different dataset… Mosaic3D Model Fly-Over Data

48 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Medical/Nursing Processes Defining procedures, protocols, formally, rigorously, completely –Complicated by exceptions Traces provide audit trails Analysis can find flaws, omissions, etc.

49 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Top Level Medical Process: Blood Transfusion

50 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Collect Blood Substep

51 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Process Blood Substep

52 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Process Analysis: An Example A process: Open Cry (English) Auction –Ascending bids –Unlimited number of bidders –Auctioneer discretion in closing auction Some example properties of interest –No late bids accepted –All bids considered –No deadlocks, no race conditions –Highest bid always wins – ….

53 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid Open Cry Auction Step Decomposition

54 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid With Exceptions NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter

55 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid With Resources NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter bidder:Bidder Auctioneer agent:Auctioneer Auctioneer agent bidder agent auctioneer

56 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid With Artifact Flow NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter best: BidReference bid:Bid deadline: Duration 1m best: BidReference bid:Bid

57 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid Entire Auction NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter best: BidReference bid:Bid deadline: Duration 1m best: BidReference bid:Bid agent:Auctioneer bidder:Bidder Auctioneer agent bidder Auctioneer agent auctioneer

58 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Properties Checked No Late Bids Accepted –Checked on initial version –Inconclusive Results –Need to add an “AuctionNotClosed” prerequisite to “Update Best Bid” Highest Bid Always Wins –Checked on initial version –Inconclusive results –Assumed locking discipline on bid handling –Checked on the revised auction –Conclusive Results

59 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Results Flowgraph models of some Little-JIL steps (eg. choice) were large and complex –Suggests step is a good abstraction (?) Modeling dataflow and resource specification was subtle at times Process flowgraphs were large, complex, arcane –While Little-JIL was smaller, clearer –Effective use of abstraction (?) Our FLAVERS finite state verification system was quite capable of performing analyses

60 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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

61 Copyright Leon J. Osterweil, All rights reserved 3 December 2003 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


Download ppt "Copyright Leon J. Osterweil, All rights reserved 3 December 2003 Preparation and Planning for ICSE 2006 (28th International Conference on Software Engineering)"

Similar presentations


Ads by Google