preparation and planning for icse 2006 (28th international conference on software engineering)

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 ([email protected])University of MassachusettsAmherst, MA 01003 USA

SinoSoft 2003Beijing, China

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


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


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


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)


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


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


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


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


Research Interests

Leon J. Osterweil


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


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)


Other Reasons for Interest in Process

• Communication• Coordination • Intuitive understanding• Prediction/projection• Verification• Training• Automation• Deep understanding• Etc.


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?


Processes are software



They should be Engineered



They should be Engineered

Using appropriate languages


Directly analogous to product definition approachesDifferent approaches for different

PhasesPurposes

Process Definition Approaches

• Natural language• Structured Natural Language• Pictorial representations

– DFDs– FSAs– Petri Nets

• Object Technologies• Programming languages


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


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”


Little-JIL Example:“Smart” Regression Test Process

RegressionTest

GetArtifacts

GetExecutable GetTest Cases

PerformTest

PerformTestExecuteTest Report Failure

SelectTests

Stop

StopReportResults

Get Input Data

Get Expected Output Data

Run TestCompare Results

NoteFailure


The “Step” is the central Little-JIL abstraction

TheStepName

Interface Badge(includes resource specs)

Prerequisite Badge Postrequisite Badge

Substep sequencingHandlers

XZ

Reactions


Trivial SW Development Process


Trivial Example Elaboration of Requirements Step


Trivial Example Elaboration of Design Step


Requirements Rework


Requirements Rework

Invocation of step originally defined as substep of Requirements


Requirements Rework


Same exceptionthrown


Requirements Rework


Same exceptionthrown

Different invocationcontext -> differentresponse


What does this tell us?

• Abstraction/reinstantiation is necessary– For an adequately articulate language– For clear understanding of “rework”

Other language features similarly motivatedBy specific examples and experiences


Iteration usually through recursionAlternation 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


Example of Choice and Try Step Kinds

Implement

Look_for_Inheritance

Look_for_Objects_to_Delegate_to

Look_for_Parameterized_Class

Custom_ImplementationReuse_Implementation

Main Goal: Support Human flexibility


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


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


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)


Resource Model: Requires andWhole-Part Relationships

Resource

Human HardwareSoftwareData

Manager Designer

PC Sparc

Design Team

Bob Carol Ted Alice


Resource Request Example

IdentifyRelationships

SpecifyRelationships RefineRelationships

Agent: OODDesigner;experttool: ClassDiagramEditorartifact: DiagramReposLock

Resource request is a query on theResource specification repository


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


Achieving Product QualityThrough 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


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 problemsStatic analysis can verify for all executions


The Capability Maturity Model (CMM)is a Specific Approach to

Software Process Improvement




It is a test plan for black box testing of processes




It is a test plan for black box testing of processes

Can’t test quality into software process products either


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


Robot Coordination Process


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”


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…

Mosaic 3D ModelFly-Over DataFly-Over DataFly-Over DataFly-Over Data


Medical/Nursing Processes

• Defining procedures, protocols, formally, rigorously, completely– Complicated by exceptions

• Traces provide audit trails • Analysis can find flaws, omissions, etc.


Top Level Medical Process:Blood Transfusion


Collect Blood Substep


Process Blood Substep


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 – ….

Open-Cry Auction

Close Auction Accept Bids From Bidder

Accept Bids From BidderAccept One Bid

Submit Bid Update Best Bid Accept One Bid

Open Cry Auction Step Decomposition

Open-Cry Auction



Submit BidUpdate Best Bid Accept One Bid

With Exceptions

NoMoreBidders

NoMoreBidders

AuctionClosed

AuctionClosedBidNotHigher

BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

Open-Cry Auction




With Resources

NoMoreBidders

NoMoreBidders

AuctionClosed


BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

bidder:Bidder

Auctioneer

Auctioneer

agent:Auctioneer

Auctioneer agent

agent bidder

agentauctioneer

Open-Cry Auction




With Artifact Flow

NoMoreBidders

NoMoreBidders

AuctionClosed


BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

best: BidReference

best: BidReference

best: BidReference

bid:Bid

deadline: Duration 1m

best: BidReference

bid:Bid

bid:Bid

Open-Cry Auction




Entire Auction

NoMoreBidders

NoMoreBidders

AuctionClosed


BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

best: BidReference

best: BidReference

best: BidReference

bid:Bid

deadline: Duration 1m

best: BidReference

bid:Bid

bid:Bid

agent:Auctioneer

bidder:BidderAuctioneer

Auctioneer agent

agent bidder

Auctioneer

agentauctioneer


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


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


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


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

preparation and planning for icse 2006 (28th international conference on software engineering)

Documents