Alexander Egyed (Teknowledge Corporation)
Dewayne Perry (University of Texas at Austin)
(chairs)
February 1, 2004


Technologies for “plugging” COTS software into software systems

Safely and predictably

Design, implement, and test

Software engineering principles
=> Several times more difficult than ordinary application code









 how to write glue code how to implement data and control dependencies how to make the COTS software aware of its surroundings how to resolve stumbling blocks and risks how to integrate user interfaces how to handle new COTS releases and other maintenance issues how to reverse engineer how to design product lines with COTS software how to test COTS-based systems



Accepted 6 papers
Had 30+ attendees

1.00 – 1.20 Tools for Commercial Component
Assembly
1.20 – 1.40 Discussion
1:40 – 2.00 Container-Managed Exception
Handling Framework
2.00 – 2.20 Discussion
2:20 – 2.40 Dynamism Gloom and Doom?
2:40 – 3.00 Break
3.00 – 3.20 Discussion
3.20 – 3.40 Reengineering Large-Scale Polylingual
Systems
Francis Bordeleau
Mark Vigder
Kevin Simons
Judith Stafford
T. Gamble
D.Flagg
R. Baird
Rose Gamble
Mark Grechanik
Dewayne E. Perry
Don Batory
3.40 – 4.00 Discussion
4.00 – 4.20 State Consistency Strategies for COTS
Integration
4.20 – 4.40 Discussion
4.40 – 5.00 Break
5.00 – 5.20 Black-box Testing of Evolving COT-
Based Systems
5.20 – 5.40 Discussion
5.40>> Brainstorming on research directives
Sven Johann
Alexander Egyed
Ye Wu

Francis Bordeleau (Zeligsoft/Carleton University)
Mark Vigder (National Research Council Canada)

Roles of concern:

Assembler: assemble commercial components into new applications or new
COTS products

Application deployer: deploy application within a specific environment

Issues:

Configuring, assembling, deploying components often requires highly skilled, expensive engineers


Large amounts of configuration and deployment data required, usually in the form of XML files
Generation and evolution of the data is tedious, error prone, and difficult to validate

Directions

Standards are evolving that enable the possibility of tools for generation, evolution and validation of assembly, configuration, and deployment data

Kevin Simons and Judith Stafford
Tufts University, USA

COTS software not aware of system and its feedback need

How to interpret COTS software exceptions in context of the system

How to avoid exceptions

How to generate exceptions in COTS software if the system requires it

How to recover the state of a COTS software after an exception

Work based on infrastructure that mediates communication between COTS software and system

T. Gamble, D. Flagg, R. Baird, and R. Gamble
University of Tulsa, USA

Commercial middleware is still not prepared to support dynamism

Sets impractical expectations for component interaction that impedes dynamism

Much a priori knowledge is needed by the

Component being inserted


Established middleware
Other components interacting with the system

A priori knowledge should be reduced without forfeiting control



Develop and use standards
Allow middleware to have designated wrappers for certain component functionality
Design adaptable component connectors gamble@utulsa.edu
, www.seat.utulsa.edu

Mark Grechanik, Dewayne E. Perry, and Don Batory
University of Texas, Austin

 architecture in polylingual system

How to have many different component interact with one another

N 2 problem provide a generic language for interacting with components (including COTS)
 components use generic language

Forward and reverse engineering process based on FOREL and ROOF


FOREL; reifies foreign type systems
ROOF: generalizes type systems to graphs and provides virtual machine over APIs and frameworks

Sven Johann (University of Mannheim, Germany)
Alexander Egyed (Teknowledge Corporation)

Instant change notification

Making COTS aware of other software components to notify them instantly about state (data and control) changes

E.g., Rational Rose notifies model analysis component about UML changes.

Incremental analysis and transformation



Batch transformation and analysis are very time and resource consuming
Incremental transformation and analysis focuses on changes only
COTS issue: when and where is data changed?

Semantic differences

Maintaining the system state consistent with COTS software state is still not trivial if semantic differences exist

Transforming Rose change notifications into system change notifications

Ye Wu (George Mason University)

Challenges: What should COTS-users do if COTS products are changed?

Changes are analyzed and classified into: generalization, specialization and reconstruction modifications.

Adjusted black-box testing techniques are provided to adequately reassure the quality of the evolving COTS-based software





Critical problem: matching COTS features to business model and processes



Often inadequate functional support need to design system around COTS software
Not good to change business practice to accommodate
COTS software
Architectural mismatches
COTS software works well for what it was designed for

Our risk to take it out of context?
We just use a portion of COTS functionality but pay the full price

COTS footprint is increasing; many unnecessary features


Package software for becoming better COTS products (guides for developers)
What does COTS need to make explicit;
What does COTS reuser need to know

Specifications, documentation, interface, model, testing, proper use, etc




What are the dependencies
What are the quality of service factors
Feature-based installation, customization
Where to get help?



Industry provides COTS; industry consumes COTS; what can we do?



Standards, mechanisms for implementing the standards
Requires industry participation; technical and not marketing
Industry agree-on

Standard interfaces


Component descriptions
Deployment framework
CMM – COTS Maturity Model; COTS Level 5 is better than 3?


How well does it satisfy packaging requirements?
How reusable is it?


Holy Book of Patterns for COTS Integration

Assembly and Deployment

Modeling

Testing

Product-Lines

Configuration Management





What can we learn from successful COTS software?

Operating system/databases are stable COTS?


Well defined interfaces
Is there a difference between legacy reuse/open source and
COTS?
Relationship between Non-developmental items (NDI) and COTS?
Is there difference between reusing small/big COTS into small/big system



What is size?
Its all about semantics: how well you understand it, how complex the interactions are
Traditional notion of size is changed
Special Issue on this topic in journal (IEEE TSE)










Francis Bordeleau (Carleton University, Canada)
Lisa Brownsword (Software Engineering Institute, USA)
Rose Gamble (University of Tulsa, USA)
Anna Liu (Microsoft Research, USA)
Nenad Medvidovic (University of Southern California, USA)
Maurizio Morisio (Politecnico di Torino, Italy)
Judith Stafford (Tufts University, USA)
Tarja Systa (Tampere University of Technology, Finland)
Ye Wu (George Mason University, USA)

Slides and Presentations at http://
/
GOOGLE: “IWICSS” aegyed@teknowledge.com

19 th IEEE International Conference on
Linz, Austria
September 20-25, 2004
Paul Grünbacher
Johannes Kepler
University, Austria
Virginie Wiels
ONERA, France
Kurt Stirewalt
Michigan State
University, USA

Key Dates:
Paper submission: April 9, 2004
Author notification: June 11, 2004
Camera-ready papers: July 2, 2004