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

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

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

March 15, 2006© USC-CSE 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

March 15, 2006© USC-CSE 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 ”

March 15, 2006© USC-CSE 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

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

March 15, 2006© USC-CSE OTS Integration Framework

March 15, 2006© USC-CSE 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

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

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

March 15, 2006© USC-CSE 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

March 15, 2006© USC-CSE 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