Mariani-COTS-IEEES-2007

Mariani-COTS-IEEES-2007 - focus 2 software composition...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
76 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/07/$25.00 © 2007 IEEE components took 10 person-years (rather than the one planned person-year), mainly because of integration problems. 1 According to Barry Boehm and Chris Abts, three of the four main problems with reusing COTS products are ab- sence of control over their functionality, ab- sence of control over their evolution, and lack of design for interoperability. 2 Traditional integration testing techniques incrementally validate the integration of the modules that compose the system being tested. Test designers can derive test cases from both the source code and the specifications. 3,4 Un- fortunately, COTS components are often dis- tributed without the source code and with in- complete specifications. Moreover, developers can use them in ways that the original design didn’t predict. So, testers must test them in the contexts in which they’re used. Our proposed technique, called behavior capture and test , detects COTS component incompatibilities by dynamically analyzing component behavior. BCT incrementally builds behavioral models of components and compares them with the behavior the components display when reused in new contexts. This lets us iden- tify incompatibilities, unexpected interactions, untested behaviors, and dangerous side effects. How BCT works BCT builds two kinds of models for each service the components offer. I/O models are Boolean expressions describing the relations between the values that components exchange. Interaction models are finite-state automata (FSA) representing the sequences of interac- tions triggered by invoking the services. The models are built automatically and describe the components’ behavior in different contexts. For example, we can build behavioral models during testing (unit, integration, and system testing) or while using the components in the field under different operative conditions. When components are reused in new con- texts—for example, for building new systems or updating obsolete components—we auto- focus 2 Dynamic Detection of COTS Component Incompatibility T he development of COTS-based systems shifts the focus of testing and verification from single components to component integration. Independent teams and organizations develop COTS components without referring to specific systems or interaction patterns. Devel- oping systems that reuse COTS components (even high-quality ones) therefore presents new compatibility problems. David Garlan, Robert Allen, and John Ockerbloom reported that in their experience, integrating four COTS software composition Leonardo Mariani and Mauro Pezzè, University of Milan Bicocca Developing component- based systems introduces new compatibility problems, which an analysis technique can reveal by automatically deriving and dynamically checking behavioral models.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
matically compare their interactions in the new contexts with the behavioral models built into former executions to identify new behaviors.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 02/24/2012 for the course CSE 503 taught by Professor Davidnotikin during the Spring '11 term at University of Washington.

Page1 / 10

Mariani-COTS-IEEES-2007 - focus 2 software composition...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online