International Workshop on Incorporating COTS-Software into Software Systems: Tools and Techniques (IWICSS) Alexander Egyed (Teknowledge Corporation) Dewayne.

Slides:



Advertisements
Similar presentations
Object-Oriented Application Frameworks Much of the cost and effort stems from the continuous re- discovery and re-invention of core concepts and components.
Advertisements

Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Chapter 2 – Software Processes
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Software Reuse SEII-Lecture 28
Chapter 2 The Software Process
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
Building Enterprise Applications Using Visual Studio ®.NET Enterprise Architect.
Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California.
SE curriculum in CC2001 made by IEEE and ACM: Overview and Ideas for Our Work Katerina Zdravkova Institute of Informatics
Software Factory Assembling Applications with Models, Patterns, Frameworks and Tools Anna Liu Senior Architect Advisor Microsoft Australia.
1 Software Architecture: a Roadmap David Garlen Roshanak Roshandel Yulong Liu.
Software evolution.
Institute for Software Research©2001, University of California, Irvine Product-Line Architectures André van der Hoek Institute for Software Research University.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software maintenance Managing the processes of system change.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Chapter 3 Software Processes.
The Re-engineering and Reuse of Software
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements l.
Chapter : Software Process
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 18 Slide 1 Software Reuse.
Software Engineering Muhammad Fahad Khan
Software Reuse Prof. Ian Sommerville
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Design with Reuse l Building software from reusable components.
The Center for Advanced Research In Software Engineering (ARISE) The University of Texas at Austin Reengineering of Large-Scale Polylingual Systems Mark.
Guide to the Software Engineering Body of Knowledge Chapter 1 - Introduction.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Chapter 2 The process Process, Methods, and Tools
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Black-box Testing for Evolving COTS-Based Software
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
Software change  Managing the processes of software system change.
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 Tools for Commercial Component Assembly Francis Bordeleau, Zeligsoft/Carleton University Mark Vigder, National Research Council Canada.
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
Model-Driven Analysis Frameworks for Embedded Systems George Edwards USC Center for Systems and Software Engineering
COTS and OSS – What is it? M. Morisio, M. Torchiano Politecnico di Torino – Italy {morisio, Seminar on CBSE An industrial study in.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking.
Chapter 13: Software Life Cycle Models Omar Meqdadi SE 273 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Software Prototyping Rapid software development to validate requirements.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
© 2004 Teknowledge Corporation State Consistency Strategies for COTS Integration Sven Johann Teknowledge Corp. / University of Applied Sciences Mannheim.
Slide 1 Service-centric Software Engineering. Slide 2 Objectives To explain the notion of a reusable service, based on web service standards, that provides.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Software Engineering Introduction.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Software Engineering (CSI 321) Software Process: A Generic View 1.
Software change Software change is inevitable –New requirements emerge when the software is used –The business environment changes –Errors must be repaired.
EMEA Beat Schwegler Architect Microsoft EMEA HQ Ingo Rammer Principal Consultant thinktecture
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
©Ian Sommerville 2007COTS-based System Engineering Slide 1 COTS-based System Engineering.
George Edwards Computer Science Department Center for Systems and Software Engineering University of Southern California
Chapter 18 Maintaining Information Systems
Model-Driven Analysis Frameworks for Embedded Systems
CS310 Software Engineering Lecturer Dr.Doaa Sami
Automated Analysis and Code Generation for Domain-Specific Models
Presentation transcript:

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

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

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

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

Program

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

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

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

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

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

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

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

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?

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

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

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

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)

/ GOOGLE: “IWICSS” Slides and Presentations at

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

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