1. OTS Integration Analysis using iStudio Jesal Bhuta, USC-CSE March 14, 2006

2. March 15, 2006© USC-CSE 20062 Outline Need for OTS Integration Analysis Components of Integration Analysis –OTS Definition Language –Framework for OTS Integration Analysis Example Current Status & Future Plans

3. March 15, 2006© USC-CSE 20063 Need for OTS Integration Analysis I

4. March 15, 2006© USC-CSE 20064 Need for OTS Integration Analysis II Identify and mitigate integration risks during the design phase Reduce rework occurring from integration incompatibilities Select a combination of OTS to minimize integration effort and schedule Detect architecture mismatches occurring due to assumptions made by OTS components Rapidly filter high-risk OTS combinations

5. March 15, 2006© USC-CSE 20065 OTS Integration Assessment – The Big Picture *Nikunj Mehta et al. “A Taxonomy of Software Connectors” **Christinia Gacek, “Detecting Architectural Mismatches During Systems Composition” +Chris Abts, “The COCOTS Model” ^Ye Yang et al, “Composable Process Elements for COTS-Based Applications ”

6. March 15, 2006© USC-CSE 20066 Integration Assessment Process Define OTS components using OTS definition language –XML based language structures to represent OTS components Use the OTS Analyzer tool to build high level deployment architecture interactions Analyze the architecture –Identify the commonly supported control and data interfaces –Estimate (based on past experience) the lines of code for developing the corresponding glue-code Input the estimate in COCOTS glue-code model to obtain cost & effort estimates

7. March 15, 2006© USC-CSE 20067 OTS Definition Language Attributes OTS Characteristics –Concurrency, Dynamism, Encapsulation, … OTS Interfaces –Inputs, Outputs, Protocols, … OTS Dependencies –Software(s) required to run the OTS product

8. March 15, 2006© USC-CSE 20068 OTS Integration Framework

9. March 15, 2006© USC-CSE 20069 iStudio Analysis Report Indicates if the architecture satisfies the dependencies of OTS products used Indicates the commonly supported connectors that could be used to ‘glue’ the OTS components –Where there are limited or no common connector styles indicates the type of custom connector that will be required Indicates architecture mismatches occurring due to various OTS interactions –E.g. Data connectors connecting control components that are not always active

10. March 15, 2006© USC-CSE 200610 Distributed Assessment of Risk Tool Pre-analysis Architecture

11. March 15, 2006© USC-CSE 200611 Distributed Assessment of Risk Tool Post-analysis Architecture

12. March 15, 2006© USC-CSE 200612 iStudio - Current Status A throw-away prototype developed for early experimentation and feedback Prototype capable of –performing initial interface analysis (identifies common connectors) –identifying architecture mismatches when using a specific connector –performing a dependency check Prototype shortcomings –Diagramming interface not user-friendly –No save feature –No remote data connectivity (users have to manually paste the component definitions) –No added recommendations for connectors required

13. March 15, 2006© USC-CSE 200613 iStudio - Future Plans Tool with a superior diagramming interface Capable of being extended to interface with special ‘level of service’ related connectors With a save feature Access to a remote directory of component definitions (automatic retrieval of component definitions) Added recommendations for the type of connectors and/or wrappers required to integrate the OTS components New tool to be completed by Aug 31, 2006