1. International Workshop on Incorporating COTS-Software into Software Systems: Tools and Techniques (IWICSS) Alexander Egyed (Teknowledge Corporation) Dewayne Perry (University of Texas at Austin) (chairs) February 1, 2004

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

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

4. Participation Accepted 6 papers Accepted 6 papers Had 30+ attendees Had 30+ attendees

5. Program

6. Tools for Commercial Component Assembly Francis Bordeleau (Zeligsoft/Carleton University) Mark Vigder (National Research Council Canada) Roles of concern: Roles of concern: Assembler: assemble commercial components into new applications or new COTS products Assembler: assemble commercial components into new applications or new COTS products Application deployer: deploy application within a specific environment Application deployer: deploy application within a specific environment Issues: Issues: Configuring, assembling, deploying components often requires highly skilled, expensive engineers 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 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 Generation and evolution of the data is tedious, error prone, and difficult to validate Directions Directions Standards are evolving that enable the possibility of tools for generation, evolution and validation of assembly, configuration, and deployment data Standards are evolving that enable the possibility of tools for generation, evolution and validation of assembly, configuration, and deployment data

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

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

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

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

11. Black-box Testing for Evolving COTS-Based Software Ye Wu (George Mason University) Challenges: What should COTS-users do if COTS products are changed? Challenges: What should COTS-users do if COTS products are changed? Changes are analyzed and classified into: generalization, specialization and reconstruction modifications. 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 Adjusted black-box testing techniques are provided to adequately reassure the quality of the evolving COTS-based software

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

13. COTS Vendor Package software for becoming better COTS products (guides for developers) 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 Specifications, documentation, interface, model, testing, proper use, etc What are the dependencies What are the dependencies What are the quality of service factors What are the quality of service factors Feature-based installation, customization Feature-based installation, customization Where to get help? Where to get help?

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

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

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

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

18. http:// www.tuisr.utulsa.edu/iwicss / GOOGLE: “IWICSS” aegyed@teknowledge.com Slides and Presentations at

19. Paul Grünbacher Johannes Kepler University, Austria Virginie Wiels ONERA, France Kurt Stirewalt Michigan State University, USA

20. Technical Program Key Dates: Paper submission: April 9, 2004 Author notification:June 11, 2004 Camera-ready papers: July 2, 2004 http://www.ase-conference.org