Preparation and Planning for
ICSE 2006
(28th International Conference on Software
Engineering)
Leon J. Osterweil ([email protected])
University of Massachusetts
Amherst, MA 01003 USA
SinoSoft 2003
Beijing, China
3 December 2003
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
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
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
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)
Copyright Leon J. Osterweil, All rights reserved
•
•
•
•
•
•
•
•
•
•
•
•
Munich, Germany
Tokyo, Japan
London, England
Singapore
Nice, France
Melbourne, Australia
Sorrento, Italy
Berlin, Germany
Osaka, Japan
Limerick, Ireland
Toronto, Canada
Edinburgh, Scotland (2004)
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
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
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
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
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Research Interests
Leon J. Osterweil
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
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)
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.
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?
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Processes are software
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Processes are software
They should be Engineered
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Processes are software
They should be Engineered
Using appropriate languages
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
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
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
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”
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Little-JIL Example:
“Smart” Regression Test Process
RegressionTest
GetArtifacts
SelectTests
PerformTest
ExecuteTest
GetExecutable GetTest Cases
ReportResults
PerformTest
Stop
Report Failure Stop
NoteFailure
Compare Results
Get Input
Data
Run Test
Get Expected
Output Data
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
The “Step” is the central Little-JIL
abstraction
Interface Badge
(includes resource specs)
Prerequisite Badge
Postrequisite Badge
TheStepName
Z
X
Handlers
Substep sequencing
Reactions
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Trivial SW Development Process
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Trivial Example Elaboration of
Requirements Step
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Trivial Example Elaboration of Design Step
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Requirements Rework
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Requirements Rework
Invocation of step
originally defined as
substep of Requirements
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Requirements Rework
Same exception
thrown
Invocation of step
originally defined as
substep of Requirements
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Requirements Rework
Same exception
thrown
Invocation of step
originally defined as
substep of Requirements
Copyright Leon J. Osterweil, All rights reserved
Different invocation
context -> different
response
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
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
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
Iteration usually through recursion
Alternation using pre/post requisites
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Example of Choice and Try Step Kinds
Implement
Reuse_Implementation
Look_for_Inheritance
Custom_Implementation
Look_for_Parameterized_Class
Look_for_Objects_to_Delegate_to
Main Goal: Support Human flexibility
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
InterfaceFilesDon’tCompile
DevelopInterfaceFiles
InterfaceFilesCompile
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
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)
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Resource Model: Requires and
Whole-Part Relationships
Resource
Human
Data
Software
PC
Manager
Hardware
Sparc
Designer
Design Team
Bob
Carol
Ted
Copyright Leon J. Osterweil, All rights reserved
Alice
3 December 2003
Resource Request Example
Agent: OODDesigner;expert
tool: ClassDiagramEditor
artifact: DiagramReposLock
IdentifyRelationships
SpecifyRelationships RefineRelationships
Resource request is a query on the
Resource specification repository
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
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
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
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
The Capability Maturity Model (CMM)
is a Specific Approach to
Software Process Improvement
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
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
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
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Robot Coordination Process
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”
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Produce a 3-D Forest Model
Fly-Over
Data
Fly-Over
Fly-Over
Data
Fly-OverData
Data
Creates “new” versions
of the fly-over data
Copyright Leon J. Osterweil, All rights reserved
Mosaic
3D Model
Maybe plan a fly-over,
maybe just get a
different dataset…
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.
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Top Level Medical Process:
Blood Transfusion
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Collect Blood Substep
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Process Blood Substep
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
– ….
Copyright Leon J. Osterweil, All rights reserved
3 December 2003
Open Cry Auction Step Decomposition
Open-Cry Auction
Accept Bids From Bidder
Accept One Bid
Submit Bid
Update Best Bid
Close Auction
Accept Bids From Bidder
Accept One Bid
With Exceptions
Open-Cry Auction
NoMoreBidders
Accept Bids From Bidder
Close Auction
NoMoreBidders
AuctionClosed
AuctionNotClosed
Accept One Bid
Accept Bids From Bidder
AuctionClosed
BidNotHigher
BidNotBetter
DeadlineExpired
Submit Bid
AuctionNotClosed
BidIsHigher
BidIsBetter
Update Best Bid
Accept One Bid
With Resources
agent:Auctioneer
Open-Cry Auction
bidder:Bidder
NoMoreBidders
Auctioneer
Auctioneer
agent
Accept Bids From Bidder
Close Auction
NoMoreBidders
AuctionClosed
Auctioneer
agent
bidder
AuctionNotClosed
Accept One Bid
Accept Bids From Bidder
AuctionClosed
BidNotHigher
BidNotBetter
DeadlineExpired
agent
auctioneer
Submit Bid
AuctionNotClosed
BidIsHigher
BidIsBetter
Update Best Bid
Accept One Bid
With Artifact Flow
best: BidReference
Open-Cry Auction
NoMoreBidders
best: BidReference
Accept Bids From Bidder
Close Auction
NoMoreBidders
AuctionClosed
best: BidReference
bid:Bid
AuctionNotClosed
Accept One Bid
bid:Bid
Accept Bids From Bidder
AuctionClosed
BidNotHigher
BidNotBetter
deadline: Duration 1m
DeadlineExpired
best: BidReference
bid:Bid
Submit Bid
AuctionNotClosed
BidIsHigher
BidIsBetter
Update Best Bid
Accept One Bid
Entire Auction
agent:Auctioneer
best: BidReference
Open-Cry Auction
bidder:Bidder
Auctioneer
NoMoreBidders
best: BidReference
Auctioneer
agent
Accept Bids From Bidder
Close Auction
NoMoreBidders
Auctioneer
best: BidReference
AuctionClosed
agent
bidder
bid:Bid
AuctionNotClosed
Accept One Bid
bid:Bid
Accept Bids From Bidder
AuctionClosed
BidNotHigher
BidNotBetter
deadline: Duration 1m
DeadlineExpired
best: BidReference
bid:Bid
Submit Bid
AuctionNotClosed
BidIsHigher
BidIsBetter
agent
auctioneer
Update Best Bid
Accept One Bid
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
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
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
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
Copyright Leon J. Osterweil, All rights reserved
3 December 2003