A FRAMEWORK FOR INTELLIGENT ASSESSMENT AND RESOLUTION OF COMMERCIAL-OFF-THE- SHELF PRODUCT INCOMPATIBILITIES by Jesal Bhuta A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (COMPUTER SCIENCE) August 2007 Copyright 2007 Jesal Bhuta
262
Embed
A FRAMEWORK FOR INTELLIGENT ASSESSMENT …csse.usc.edu/TECHRPTS/PhD_Dissertations/files/Bhuta...Jesal Bhuta A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
A FRAMEWORK FOR INTELLIGENT ASSESSMENT
AND RESOLUTION OF COMMERCIAL-OFF-THE-
SHELF PRODUCT INCOMPATIBILITIES
by
Jesal Bhuta
A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the
Requirements for the Degree DOCTOR OF PHILOSOPHY
(COMPUTER SCIENCE)
August 2007
Copyright 2007 Jesal Bhuta
ii
To my parents
iii
Acknowledgements
This dissertation could not have been completed without the support of many minds.
I am especially indebted to my advisor Dr. Barry Boehm, for his guidance and support
throughout my academic program. I am grateful to the members of my dissertation
committee whose invaluable guidance and support made this work possible. I would
like to specially thank to Dr. Nenad Medvidovic for his support during
experimentation in the software architecture course; and Dr. Ricardo Valerdi who
spent hours with me over the telephone from across the country to help me excel in
this research.
I’ve had the pleasure of working with numerous outstanding colleagues during my
time at USC. These include Ye Yang who has been an excellent associate and a
wonderful friend; Apurva Jain and Steven Meyers who were excellent sound boards
for my ideas; Monvorath Phongpaibul who helped with empirical assessments; and
finally teaching assistants of the software engineering and software architecture
courses at USC who supported my experiments. I’d also specifically like to thank
Chris Mattmann for his collaboration and support in providing a ready extension to
this framework. Chris is an excellent friend with extremely interesting ideas and
inspiring research.
Last, but certainly not least, I would like to thank my family for their love and support
during my study. My parents have inspired me to always strive for the excellence
since childhood.
iv
Table of Contents
Acknowledgements............................................................................................... iii
List of Figures ........................................................................................................ vi
List of Tables ......................................................................................................... ix
List of Acronyms .................................................................................................. xv
Abstract .............................................................................................................. xvii
Interaction Type: Describes the manner of interaction. An interaction can be:
- a data interaction where components are exchanging data (e.g. data connector),
- a control interaction where components are exchanging control (e.g. spawn), or
- both data and control interaction where components are exchanging both (e.g. procedure call)
Direction of Interaction: Indicates if the interaction can be:
- unidirectional: data or control flow occurs in one direction only i.e. from A to B or from B to A but not both, or
- bidirectional: data and/or control flow occurs in both directions
Initiator: In several bidirectional interactions often times only one component is responsible for initiating the interaction (e.g. the web-browser [Microsoft Internet Explorer 2007] and web-server [Apache 1999] interaction is initiated by the browser). Initiator indicates the component that will be responsible for starting an interaction
Special Consideration: For certain mismatches to occur other specific conditions in addition to the basic mismatch identification rule must be true. Special consideration lists these specific conditions.
Mismatch Identification: Mismatch identification actually described the conditions that must hold for a mismatch to occur
Result: If a mismatch occurs, result indicates the its implications to the system
Resolution Techniques: Where possible strategies to resolve these mismatches have been listed
85
The remainder of this section presents these 3 groups of interoperability assessment
rules. Every rule is defined textually described followed by a table which contains a
detailed description of when such a mismatch can occur, how it can be identified
using this framework and if no steps have been taken to resolve the conflict what are
its implications to the functioning of the entire system. The information described in
these tables is illustrated in Table 7.
6.1 Interface Mismatch Analysis Rules
Interface mismatch analysis rules identify interoperability conflicts pertinent to
incompatible interface assumptions made by the two interacting COTS components.
The following sub-section lists these mismatches and corresponding rules utilized to
identify them in a COTS-based architecture.
IM1: Binding Mismatch
Binding mismatch occurs when two interacting components do not have any
common binding mechanisms through which they can establish communication.
Such a mismatch can be resolved by identifying a bridge connector which supports
binding mechanisms of both components. Another way to resolve this mismatch is to
utilize a bridge as the intermediate interaction mechanism. Alternately one could
build a wrapper around one of the two components and convert its binding
mechanism to one that is supported by the other component. Building a wrapper may
however significantly increase integration effort. A detailed description of this
mismatch and its preconditions are illustrated in Table 8.
86
Table 8: Binding Mismatch
Interaction Type: Data or Control
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: If components A and B are deployed on different nodes local binding mechanisms such static-binding and compile-time dynamic binding cannot constitute a common binding mechanism
Mismatch Identification: For every interaction in an architecture:
Identify common values for binding attribute in the definitions of the 2 products. If the components are deployed on multiple nodes discard the local binding techniques as possible mechanisms.
If no common binding methods are found a mismatch has occurred
Result: Communication cannot be established between components A and B
Resolution Techniques: Identify an online bridging connector which supports binding mechanisms of both components A and B, or
Build a wrapper around one component and convert its binding mechanism to one that is supported by the other component
IM2: Control Interaction Mismatch
Control interaction mismatch occurs when two components exchanging control do
not support any common control exchange connectors or protocols. Such mismatches
can either be resolved by a bridging connector that supports control exchange
mechanisms for both the interacting components. Alternately a mediator that
supports multiple control exchange mechanisms including those supported by the
interacting components can be used. Finally, if neither a bridge connector nor a
mediator is available, developers can extend one of the components’ to support to one
of the components or building a wrapper. A detailed description of this mismatch and
its preconditions are illustrated in Table 9.
87
Table 9: Control Interaction Mismatch
Interaction Type: Control
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: If components A and B are deployed on different nodes local control interaction mechanisms such procedure calls do not constitute common control exchange connectors
Mismatch Identification: For every control interaction in an architecture:
Identify common values for control output attribute of component A and control input attribute of component B (if direction of communication is from A to B); and vice versa (if direction of interaction is from B to A).
Identify common values for control transmission protocols of component A and control reception protocols of component B (if the direction of communication is from A to B); and vice versa (if direction of communication is from B to A).
If no common control exchange mechanisms or control protocols are found a mismatch has occurred.
Note: For bidirectional communication follow all the steps
Result: Control exchange is not possible
Resolution Techniques: Identify an online of offline bridging connector or mediator which supports control interaction mechanisms or protocols of both components A and B, or
Extend one component so that it supports control interaction mechanism of the other component , or
Build a wrapper around one component and convert its interaction mechanism to one that is supported by the other component
IM3: Custom Component Interaction Mismatch
Certain COTS products provide communication and extension support for specific
languages. For example Microsoft Office [Microsoft Office 2007] provides extensive
support for .NET languages such as Visual Basic, C#, Visual C++, and Visual J++
[Microsoft .NET Framework 2007]. The custom component interaction mismatch
occurs when a COTS component is interacting with a custom component and the
custom component is being built in a language not inherently supported by the COTS
88
product. Such a mismatch can be resolved by either building the custom component
in a language supported by the COTS product or by building a glueware that will
broker the interaction between the custom component and the COTS product. A
detailed description of this mismatch and its preconditions are illustrated in Table 10.
Table 10: Custom Component Interaction Mismatch
Interaction Type: Data or Control
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction in an architecture where one component is a COTS product (A) and another is a custom component (C):
Identify values for implementation language for C and communication language support for A.
If no common control languages are found a mismatch has occurred.
(Note: If there are no languages listed for communication language support attribute for COTS A assume the languages listed in implementation attribute for this analysis)
Result: Interaction may be more effort intensive to setup
Resolution Techniques: Identify a language in which both custom and COTS components can interact with and build glue-code in that language to act as a broker for the interaction, or
Build the custom component in a language supported by the COTS product , or
Build a wrapper around the COTS product and/or the custom component to enable this interaction
IM4: Data Format Mismatch
Components exchanging data (usually more than standard parameters) follow a
certain pre-defined format or generally accepted standard such as HTML [W3 HTML
1999], XML [Harold and Means 2004] or JPEG [Miano 1999]. A data format mismatch
occurs when two communicating components do not support any common data
formats. This can be resolved by identifying a third-party mediator which would
89
convert data from a format supported by one component to a format supported by
the other component or extend the one component so that it can decipher the data
format supported by the other component. A description of this mismatch is shown
in Table 11.
Table 11: Data Format Mismatch
Interaction Type: Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: If one of the two components is a data broker or a data storage component, i.e. it is not required to decipher the data being exchanged; in such a case this mismatch may not occur
Mismatch Identification: For every data interaction in an architecture (if neither components are data brokers):
Identify common values for data format attribute of components A and B
If no common data formats are found a mismatch has occurred.
Result: Data exchanged cannot be deciphered
Resolution Techniques: Identify a mediator which supports data conversion for formats supported by components A and B (such as RTFtoXML converted [Zielinski 2003]), or
Extend one component so that it can decipher the data format supported by the other component
IM5: Data Interaction Mismatch
Data interaction mismatch occurs when two interacting components exchanging data
do not support any common data exchange connectors or protocols. Such
mismatches can be resolved by a bridging connector that supports data exchange
protocols for both interacting components. Alternately, a mediator could be used. If
neither a bridging connector or a mediator is available the developers can build an
extension or a wrapper to one of the components that will support the data
90
interaction mechanism supported by the other component. A detailed description of
this mismatch and its preconditions are illustrated in Table 12.
Table 12: Data Interaction Mismatch
Interaction Type: Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: If components A and B are deployed on different nodes local data interaction mechanisms such procedure calls and shared (local) data do not constitute common data exchange connectors
Mismatch Identification: For every data interaction in an architecture:
Identify common values for data output attribute of component A and data input attribute of component B (if direction of communication is from A to B); and vice versa (if direction of interaction is from B to A).
Identify common values for data transmission protocols of component A and data reception protocols of component B (if the direction of communication is from A to B); and vice versa (if direction of communication is from B to A).
If no common data exchange mechanisms or data protocols are found a mismatch has occurred.
Note: For bidirectional communication follow all the steps
Result: Data exchange is not possible
Resolution Techniques: Identify an online of offline bridging connector or mediator which supports data interaction mechanisms or protocols of both components A and B, or
Extend one component so that it supports interaction mechanism of the other component , or
Build a wrapper around one component and convert its interaction mechanism to one that is supported by the other component
IM6: Data Representation Mismatch
Components exchanging data (usually more than standard parameters) follow a
certain standard data representation method such as ASCII [ASCII 1963] and Unicode
[Unicode 2003]. A data representation mismatch illustrated in Table 13, occurs when
91
two communicating components do not support any common data representation
methods. This can be resolved by identifying a third-party mediator which would
convert data from a representation method supported by one component to a method
supported by the other component or extend the one component so that it can
decipher the data representation method supported by the other component.
Table 13: Data Representation Mismatch
Interaction Type: Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: If one of the two components is a data broker or a data storage component, i.e. it may or may not be required to decipher the data being exchanged; in such cases this mismatch may not occur.
Mismatch Identification: For every data interaction in an architecture:
Identify common values for data representation attribute of components A and B
If no common data representation methods are found a mismatch has occurred.
Result: Data exchanged cannot be deciphered
Resolution Techniques: Identify a mediator which supports data conversion for formats supported by components A and B, or
Extend one component so that it can decipher the data format supported by the other component
IM7: Error Interaction Mismatch
When an error occurs in an interacting component (A) it should make its counterpart
(B) aware of the error. If not component B can be blocked waiting for a response.
Error interaction mismatch occurs when there are no common error exchange
methods between the two components. Such a mismatch can be resolved through a
wrapper or extension around component B that can translate error information from
component A. A description of this mismatch is shown in Table 14.
92
Table 14: Error Interaction Mismatch
Interaction Type: Data or Control
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: None
Mismatch Identification: For every interaction in an architecture:
Identify common values for error output attribute of component A and error input attribute of component B (if direction of communication is from A to B); and vice versa (if direction of interaction is from B to A).
If no common error communication mechanisms are found a mismatch has occurred.
Result: Error messages cannot be deciphered resulting in undesirable consequences when an error occurs
Resolution Techniques: Extend one component so that it can decipher the error interaction mechanisms supported by the other component
6.2 Internal Assumption Mismatch Analysis Rules
Internal assumption mismatch analysis rules define interoperability conflicts related
to incompatible internal assumptions made by the two interacting COTS
components. Of the 50 mismatches listed in this section, 46 mismatches and the rules
to help identify them (IAM1 to IAM46) have been derived from the works of Ahmed
Abd-Allah [Abd-Allah 1996] and Christinia Gacek [Gacek 1998]. Abd-Allah and Gacek
originally defined several of these mismatches to address custom component and sub-
system integration. Where required such mismatches have been updated to address
COTS product integration. This work has added 4 mismatches pertinent to error
handling (IAM47 – IAM50) and rules to identify these mismatches. This work has also
updated several mismatches so that they are applicable in the COTS domain instead
of the architectural style domain for which they were originally developed. The
93
following sub-section lists mismatches and corresponding rules utilized to identify
them in a COTS-based architecture. These mismatch analysis rules have been defined
across 5 distinct connector types. The connector types include:
• Calls define a mechanism to exchange both data and control amongst two
components. Data is usually exchanged as simple parameters. Examples of
calls include procedure calls, remote procedure calls etc.
• Spawn defines a mechanism to begin a new process or a new thread in a
system.
• Data Connector defines a connector responsible for transferring data amongst
two components. Examples of data connectors include pipes and streams.
• Shared Data refers to a mechanism where two components access a shared
repository to exchange data. Example of shared data mechanisms include
database management systems [Silberschatz et al. 2005] and file systems
[Callaghan 1999].
• Trigger refers to an action (data or control transfer) associated with an event –
reception of data or control.
Internal assumption mismatches, because they are based upon internal assumptions
made by COTS component developers, may or may not occur depending upon the
architecture and system dynamics. This framework enables identification of cases
where such mismatches can potentially occur. It recommends that the developers test
for such mismatches when prototyping the application and running the integration
and acceptance tests. Additionally, since these mismatches are occur due to the
94
dynamics of system operation, the mismatch resolution is applied on a per-case basis
and the framework cannot recommend a resolution to these mismatches.
IAM1: Synchronization Mismatch
“Two concurrent threads share data, with potential synchronization problems”
In an interaction where two multi-threaded components or a multi-threaded and a
single threaded component are running concurrently and are sharing data a
synchronization problem can occur. A description of this mismatch is available in
Table 15.
Table 15: Synchronization Mismatch
Interaction Type: Data
Connectors: Shared Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every shared data interaction in an architecture:
If either component’s concurrency value is multi-threaded, a mismatch has occurred.
Result: Data synchronization problems can occur
IAM2: Layering Constraint Violation Mismatch
“A Layering Constraint is violated”
When either components in an interaction support layering, a connector could
potentially ignore constraints set on either control or data connector therefore
violating them. This mismatch may not cause a system failure but can create
95
problems during maintenance and refresh cycles. A description of this mismatch is
shown in Table 16.
Table 16: Layering Constraint Violation Mismatch
Interaction Type: Data or Control or Both
Connectors: Call, Spawn, Data Connector, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using call, spawn, data connector or triggers in an architecture:
If either component supports layering, a mismatch can occur.
Result: Layering constraint maybe violated creating undesired effects during maintenance and refresh cycles.
IAM3: Unrecognizable Trigger Mismatch
“Different sets of recognized events are used by two components that permit triggers.”
In an interaction where both interacting components permit triggers, they may not
identify triggers in certain situations when they have different triggering events
creating problems in systems operation. This mismatch is described in Table 17.
Table 17: Unrecognizable Trigger Mismatch
Interaction Type: Data or Control or Both
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using call, spawn, data connector, shared data or triggers in an architecture:
If both components support triggers, a mismatch can occur.
Result: Triggers may not be identified creating undesired effects in systems operation
96
IAM4: Lack of Triggered Spawn Mismatch
“A (triggered) spawn is made into or out of a component which originally forbade
them.”
Two components are interacting via triggered spawns and one does not support
dynamic creation of threads. In such cases synchronization problems and resource
contention can occur. A description of this mismatch is available in Table 18.
Table 18: Lack of Triggered Spawn
Interaction Type: Control
Connectors: Spawn, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both spawns and triggers
Mismatch Identification: For every interaction using a triggered spawn in an architecture:
If components do not support dynamic creation of threads, a mismatch can occur.
Result: May cause synchronization problems and resource contention
IAM5: Unrecognized Triggering Event Mismatch
“An unrecognized trigger event is used.”
Table 19: Unrecognized Triggering Event Mismatch
Interaction Type: Data or Control
Connectors: Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using triggers in an architecture:
If both components support triggers, a mismatch can occur
Result: May cause the system to behave in an unexpected manner
97
A trigger connector, in certain situations generates event do not occur causing
unexpected behavior. A description of this mismatch is shown in Table 19.
IAM6: Trigger Forbidden Mismatch
“A trigger refers to components which originally forbade triggering.”
When a triggering mechanism is used as the connector for components that do not
support triggers, these triggers may be ignored. Note that this mismatch will be
identified and filtered by interface mismatch IM2. A description of this mismatch is
available in Table 20.
Table 20: Trigger Forbidden Mismatch
Interaction Type: Data or Control
Connectors: Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using triggers in an architecture:
If either component does not support triggers, a mismatch can occur.
Result: May cause the system to behave in an unexpected manner
IAM7: Data Connection Mismatch
“A data connector utilized for interaction between components that forbade them.”
In a sub-system where a data connector is being used for an interaction between two
components but the interacting components do not support data connectors the
interaction will fail. Note that this mismatch will also be identified as an interface
mismatch (IM5). The data connection mismatch is illustrated in Table 21.
98
Table 21: Data Connection Mismatch
Interaction Type: Data
Connectors: Data Connector
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using a data connector in an architecture:
If either component does not support data connector, a mismatch can occur.
Result: May causes an interaction failure
IAM8: Shared Data Mismatch
“A shared data relationship refers to a subsystem which originally forbade them.”
When shared data is being used to setup interaction between two components, but
either of them does not support the shared data mechanism, the interaction will fail.
Note that this mismatch will also be identified as an interface mismatch (IM5). A
description of this mismatch is available in Table 22.
Table 22: Shared Data Mismatch
Interaction Type: Data
Connectors: Shared Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using a shared data in an architecture:
If either component does not support shared data, a mismatch can occur.
Result: May causes an interaction failure
IAM9: Triggered Spawn Mismatch
“A (triggered) spawn is made into or out of a subsystem which is not concurrent.”
99
A triggered spawn is used as a connector during an interaction between two
components, at least one of which does not support concurrent threads. This may
cause synchronization problem and resource contention. A description of this
mismatch is shown in Table 23.
Table 23: Triggered Spawn Mismatch
Interaction Type: Control
Connectors: Spawn, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both spawn and triggers
Mismatch Identification: For every interaction using triggered spawns in an architecture:
If either component’s concurrency value is not multi-threaded and interacting components support both triggers and spawns, a mismatch can occur
Result: May cause synchronization problems and resource contention
IAM10: Single Node Mismatch
“A remote connector is extended into or out of a non-distributed component (i.e. a
component originally confined to a single node).”
Table 24: Single Node Mismatch
Interaction Type: Data or Control or Both
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger,
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using call, spawn, connector, shared data and trigger in an architecture:
If either component’s distribution value is not single-node, a mismatch can occur.
Result: May cause synchronization problems and resource contention
100
When a remote connector is used in an interaction where one of the components is
designed as a single node system, the single node system may not be able to handle
delays or errors that occur during distributed communication. A description of this
mismatch is available in Table 24.
IAM11: Resource Overload Mismatch
“A node resource is overused.”
When multiple components are deployed on a single node over usage of resources
such as memory and disk space can create contention. A description of this mismatch
is shown in Table 25.
Table 25: Resource Overload Mismatch
Interaction Type: Not Applicable
Connectors: Not Applicable
Direction of Interaction: Not Applicable
Initiator: Not Applicable
Mismatch Identification: For every node in the system in an architecture:
If the nodes have 2 or more components deployed on it a mismatch can occur
Result: Resources such as memory and disk space can be overused
IAM12: Triggering Actions Mismatch
“There is a non-deterministic set of actions that could be caused by a trigger.”
When two interacting components support triggering and there is at least one trigger
associated with an event from each component, the sequence in which actions take
101
place may be unclear resulting in undesired effects. This mismatch is illustrated in
Table 26.
Table 26: Triggering Actions Mismatch
Interaction Type: Data or Control or Both
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction using call, spawn, connector, shared data and trigger in an architecture:
If both components support triggering, a mismatch can occur.
Result: Sequence of execution may be unclear resulting in unexpected system behavior
IAM13: Inactive Control Component Deadlock Mismatch
“Data connectors connecting control components that are not always active may lead
into deadlock.”
Table 27: Inactive Control Component Deadlock Mismatch
Interaction Type: Data (only)
Connectors: Data Connector
Direction of Interaction: Unidirectional (From A to B only) or Bidirectional
Initiator: Both components A or B, or component A only
Special Consideration: Mismatch will not occur if the interaction includes both data and control
Mismatch Identification: For every interaction between components A and B using data connector in an architecture:
If component A is synchronous and component B does not have a central or distributed value for control unit the mismatch may occur
Result: A will transmit data to B and block, but component B may be inactive resulting in no response to A. Component A will be deadlocked
102
Two components are connected by a blocking bridging data connector. The initiating
component is synchronous and the other component lacks support for a control unit.
While the synchronous component transmits data the receiving component may be
inactive because it lacks support for a control unit. A component that transmits data
may block waiting for a response and enter a deadlock. A description of this
mismatch is shown in Table 27.
IAM14: Inactive Control Components Mismatch
“Data connectors connecting control components that are not always active may lead
into deadlock.”
Two components are connected by a data connector and the receiving component
may be inactive when the data is sent, resulting in a data loss. A description of this
mismatch is available in Table 28.
Table 28: Inactive Control Components Mismatch
Interaction Type: Data (only)
Connectors: Data Connector
Direction of Interaction: Unidirectional (From A to B) or Bidirectional
Initiator: Both components A or B, or component A only
Special Consideration: Mismatch will not occur if the interaction includes both data and control
Mismatch Identification: For every interaction between components A and B using data connector in an architecture:
If component B does not have a central or distributed value for control unit the mismatch may occur
Result: A will transmit data to B, but component B may be inactive resulting in data loss
103
IAM 15: Single-Thread Assumption Mismatch
“Erroneous assumption of single-thread.”
In two interacting control components a single-threaded component makes a call to
the multi-threaded component that may spawn a new thread and return control to
the single-threaded component. The single-threaded component assumes that it is
working alone. This can cause synchronization problems when accessing share data
and resource contention. A description of this mismatch is shown in Table 29.
Table 29: Single-Thread Assumption Mismatch
Interaction Type: Control, or Data and Control
Connectors: Call, Spawn, Trigger
Direction of Interaction: Unidirectional (from A to B) or Bidirectional
Initiator: Both components A or B, or component A only
Special Considerations: Synchronization problems are likely to occur of the two components are utilizing a shared data method in addition to call, spawn or trigger
Mismatch Identification: For every interaction between components A and B using call, spawn or trigger in an architecture:
If component A is single threaded and component B is multithreaded and supports spawn, a mismatch can occur
Result: A call made from A to B may cause B to spawn a new thread; while A may assume that it is working alone. This can cause synchronization problems or resource contention.
IAM16: Cyclic Component Mismatch
“(Triggered) Call to cyclic (non-terminating) control component.”
When two components are interacting via a triggered call mechanism and one
component is cyclic, hence non-terminating, control may never be returned to the
caller causing a deadlock. A description of this mismatch is available in Table 30.
104
Table 30: Cyclic Component Mismatch
Interaction Type: Control
Connectors: Call, Trigger
Direction of Interaction: Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both calls and triggers
Mismatch Identification: For every interaction between components A and B using a triggered call in an architecture:
If the callee components’ response time is cyclic, a mismatch can occur
Result: Control may never be returned to the caller resulting in a deadlock
IAM17: Underlying Platform Mismatch
“Erroneous assumption of same underlying platform.”
Two components deployed on the same machine actually require different underlying
platform. In such a scenario one or both components may not function. Note that this
mismatch will also be identified during dependency mismatch analysis (DM5). A
description of this mismatch is shown in Table 31.
Table 31: Underlying Platform Mismatch
Interaction Type: Not applicable
Connectors: Not applicable
Direction of Interaction: Not applicable
Initiator: Not applicable
Mismatch Identification: For every component A and B on the same node:
If they do not share the same underlying platform a mismatch has occurred
Result: One or both components may not function
105
IAM18: Encapsulation Call Mismatch
“(Triggered) Call to a private method.”
Two components are interacting via triggered calls and one component makes a call
to a private method of the other component. Since the method is not accessible the
interaction will fail. A description of this mismatch is available in Table 32.
Table 32: Encapsulation Call Mismatch
Interaction Type: Control
Connectors: Call, Trigger
Direction of Interaction: Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both calls and triggers
Mismatch Identification: For every interaction between components A and B using a triggered call in an architecture:
If the callee component supports encapsulation, a mismatch can occur when attempting to access a private method
Result: The interaction will fail since the method is not accessible
IAM19: Encapsulation Spawn Mismatch
“(Triggered) Spawn to a private method.”
When two components are interacting via triggered spawns, a trigger in one
component may erroneously make a call to a method of the other component. If the
other component is encapsulated and the method called is private the method will
not be accessible resulting in interaction failure. This mismatch is further elaborated
in Table 33.
106
Table 33: Encapsulation Spawn Mismatch
Interaction Type: Control
Connectors: Spawn, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both spawn and triggers
Mismatch Identification: For every interaction between components A and B using triggered spawn in an architecture:
If the callee component supports encapsulation, a mismatch can occur when attempting to access a private method
Result: The interaction will fail since the method is not accessible
IAM20: Private Data Mismatch
“Sharing Private Data.”
Two components are interacting via bridging shared data, but the data is private in
the original data component resulting in an interaction failure. A description of this
mismatch is available in Table 34.
Table 34: Private Data Mismatch
Interaction Type: Data
Connectors: Shared Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a shared data connector/data broker C:
If connector C supports encapsulation the interaction can fail
Result: The interaction will fail since the method is not accessible
IAM21: Multiple Central Control Unit Mismatch
“More than one central control unit exists.”
107
When two or more components with central control units are deployed on a single
node each may assume that they have absolute control of the system resulting in a
failure due to execution sequencing. A description of this mismatch is in Table 35.
Table 35: Multiple Central Control Unit Mismatch
Interaction Type: Data or Control or Both
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B in an architecture:
If A and B are on the same node and both have central control units
Result: Each component assumes that they have absolute control of the system resulting in an execution failure
IAM22: Reentrant Data Sharing Mismatch
“Sharing data with a reentrant component.”
Table 36: Reentrant Data Sharing Mismatch
Interaction Type: Data
Connectors: Shared Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a shared data in an architecture:
If either components support reentrance a mismatch can occur
Result: Data sharing can occur with the incorrect invocation of the component resulting in unexpected behavior
When two components are interacting via bridging shared data, and one of the
components is reentrant; data sharing may occur with incorrect invocation of the
108
component resulting in unexpected behavior. A description of this mismatch is
available in Table 36.
IAM23: Reentrant Data Transfer Mismatch
“A reentrant component is either sending or receiving a data transfer.”
Two components are interacting via a bridging data connector and at least one of the
components is reentrant. There can be an incorrect assumption of the specific
invocation of the component that is either sending or receiving data resulting in a
communication failure. A description of this mismatch is shown in Table 37.
Table 37: Reentrant Data Transfer Mismatch
Interaction Type: Data
Connectors: Data Connector, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a data connector or trigger in an architecture:
If either components support reentrance a mismatch can occur
Result: Data sharing can occur with the incorrect invocation of the component resulting in unexpected behavior
IAM24: Non-Reentrant Call Mismatch
“(Triggered) Call to a non-reentrant component.”
When two components are interacting via a bridging call, the callee component is not
reentrant and may already be running; resulting in a communication failure. A
description of this mismatch is available in Table 38.
109
Table 38: Non-Entrant Call Mismatch
Interaction Type: Data and Control
Connectors: Call, Trigger
Direction of Interaction: Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both calls and triggers
Mismatch Identification: For every interaction between components A and B using a triggered call in an architecture:
If either components support reentrance a mismatch can occur
Result: The callee component may already be running resulting in unexpected behavior
IAM25: Non-Reentrant Spawn Mismatch
“(Triggered) Spawn to a non-reentrant component.”
When two components are interacting via a bridging spawn, the spawnee component
is not reentrant and may already be running; resulting in a communication failure. A
description of this mismatch is shown in Table 39.
Table 39: Non-Reentrant Spawn Mismatch
Interaction Type: Data and Control
Connectors: Spawn, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both spawns and triggers
Mismatch Identification: For every interaction between components A and B using a triggered spawn in an architecture:
If either components support reentrance a mismatch can occur
Result: The callee component may already be running resulting in unexpected behavior
110
IAM26: Prioritized Composition Mismatch
“Composition involves one or more prioritized parts.”
One of the two interacting components may support prioritization. This can cause
confusion in execution sequencing resulting in unexpected behavior. A description of
this mismatch is available in Table 40.
Table 40: Prioritized Component Mismatch
Interaction Type: Data and Control
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a call, spawn, data connector, shared data or trigger in the architecture:
If either components (or their parent components) support prioritization a mismatch can occur
Result: There sequence of execution maybe unexpected
IAM27: Prioritized Node Sharing Mismatch
“A prioritized component sharing a node with some other component.”
Table 41: Prioritized Node Sharing Mismatch
Interaction Type: Not applicable
Connectors: Not applicable
Direction of Interaction: Not applicable
Initiator: Not applicable
Mismatch Identification: For every components A and B deployed on the same node:
If one or either components (or their parent components) support prioritization a mismatch can occur
Result: The distribution of priorities will be unclear resulting in unexpected behavior
111
When two components are sharing a node and one of them supports prioritization, it
can be unclear as to how the priorities will be distributed across various parts of the
composition which can affect the way interrupts are to be applied. A description of
this mismatch is shown in Table 41.
IAM28: Backtracking Call/Spawn Mismatch
“(Triggered) Call or spawn from a component that may later backtrack.”
Two components are interacting via a bridging call or spawn and the caller or
spawner may backtrack resulting in unexpected behavior. A description of this
mismatch is available in Table 42.
Table 42: Backtracking Call/Spawn Mismatch
Interaction Type: Control
Connectors: Call, Trigger, Spawn
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support calls and triggers or spawns and triggers. Unidirectional interaction permitted for triggered spawn only.
Mismatch Identification: For every interaction between components A and B using a triggered call or a triggered spawn in an architecture:
If one or either components supports backtracking, a mismatch can occur
Result: The caller or spawner may backtrack resulting in unexpected behavior
IAM29: Backtracking Data Transfer Mismatch
“Data being transferred from some component that may later backtrack.”
112
Two interacting components are exchanging data and the component which sends
the data supports backtracking. If the data sender backtracks it can cause undesired
side effects on the system. A description of this mismatch is shown in Table 43.
Table 43: Backtracking Data Transfer Mismatch
Interaction Type: Data or Control
Connectors: Data Connector, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a data connector or trigger in an architecture:
If one or either components supports backtracking, a mismatch can occur
Result: The data sender may backtrack resulting in undesired effects
IAM30: Backtracking Shared Data Mismatch
“Shared data being modified by a component that may later backtrack.”
Table 44: Backtracking Shared Data Mismatch
Interaction Type: Data
Connectors: Shared Data
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a shared data connector in an architecture:
If one or either components supports backtracking, a mismatch can occur
Result: The data sender may backtrack resulting in undesired effects
Two components are interacting via shared data and one component supports
backtracking. The component may modify the shared data and backtracking causing
113
undesired effects in the overall system. A description of this mismatch is available in
Table 44.
IAM31: Predictable Call Response Time Mismatch
“(Triggered) Call from a component requiring some predictable response times to some
component(s) not originally considered.”
Two components are interacting via bridging (triggered) call connector and at least
one component requires predictable response times. In such a scenario if the one
component does not cater to the predictable response times of the other component,
it can result in undesired effects. A description of this mismatch is shown in Table 45.
Table 45: Predictable Call Response Time Mismatch
Interaction Type: Control
Connectors: Call, Trigger
Direction of Interaction: Bidirectional
Initiator: Either components A or B
Special Considerations: Components A and B must support both calls and triggers
Mismatch Identification: For every interaction between components A and B using a triggered call in an architecture:
If the response time value of one component is predictable, a mismatch can occur
Result: One component does not cater to predictable response time, while the other component requires a predictable response time resulting in undesired effects
IAM32: Predictable Spawn Response Time Mismatch
“(Triggered) Spawn from a component requiring some predictable response times to
some component(s) not originally considered.”
114
Two components are interacting via bridging (triggered) spawn connector and at least
one component requires predictable response times. In such a scenario if the one
component does not cater to the predictable response times required by the other
component can result in undesired effects. A description of this mismatch is available
in Table 46.
Table 46: Predictable Spawn Response Time Mismatch
Interaction Type: Control
Connectors: Spawn, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Considerations: Components A and B must support both spawns and triggers
Mismatch Identification: For every interaction between components A and B using a triggered spawn in an architecture:
If the response time value of one component is predictable, a mismatch can occur
Result: One component does not cater to predictable response time, while the other component requires a predictable response time resulting in undesired effects
IAM33: System Reconfiguration Mismatch
Table 47: System Reconfiguration Mismatch
Interaction Type: Data or Control
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a call, spawn, data connector, shared data, spawn or trigger:
If only one component supports data online reconfiguration, a mismatch can occur
Result: Only the partial sub-system will recover upon the failure resulting in undesired effects
115
“Only part of the resulting system automatically reconfigures upon failure.”
Two components are interacting where only one component supports online
reconfiguration upon failure. This can result in partial system reconfiguring upon
failure causing undesired effects. A description of this mismatch is shown in Table 47.
IAM34: Synchronization Mechanism Mismatch
“Some components that were expected to synchronize have different synchronization
mechanisms.”
Two interacting components are executing concurrently on a system and have
different synchronization mechanisms. This can cause undesired effects. A
description of this mismatch is available in Table 48.
Table 48: Synchronization Mechanism Mismatch
Interaction Type: Data or Control
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using a call, spawn, data connector, shared data spawn or trigger connector in an architecture:
If component A’s value for concurrency and synchronization; and component B’s value for concurrency and synchronization are not the same a mismatch can occur.
Result: Synchronization between components will fail resulting in undesired effects
IAM35: Preemptable Call Mismatch
“(Triggered) Call to a component that should be preemptable and isn’t.”
116
Two components interacting via bridging (triggered) call and the caller’s parent
component is preemptable and callee’s parent is not. This can result in situations
where the caller is preempted and callee is not. A description of this mismatch is
shown in Table 49.
Table 49: Preemptable Call Mismatch
Interaction Type: Control
Connectors: Call, Trigger
Direction of Interaction: Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both calls and triggers
Mismatch Identification: For every interaction between components A and B using a triggered call in an architecture:
If only one component’s parent supports preemption a mismatch can occur
Result: In certain situations a caller will be preempted while callee is not
IAM36: Preemptable Spawn Mismatch
“(Triggered) Spawn to a component that should be preemptable and isn’t.”
Table 50: Preemptable Spawn Mismatch
Interaction Type: Control
Connectors: Spawn, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both spawns and triggers
Mismatch Identification: For every interaction between components A and B using a triggered spawn in an architecture:
If only one component’s parent supports preemption a mismatch can occur
Result: In certain situations a caller will be preempted while callee is not
117
Two components interacting via bridging (triggered) spawn and the caller’s parent
component is preemptable and callee’s parent is not. This can result in situations
where the caller is preempted and callee is not. A description of this mismatch is
available in Table 50.
IAM37: Garbage Collector Mismatch
“(Triggered) Call to a component that performs on the fly garbage collection.”
Two components are interacting via a bridging (triggered) call and the callee
performs on the fly garbage collection while the caller has requirements for
predictable or bounded response times. This can result in undesirable side effects. A
description of this mismatch is shown in Table 51.
Table 51: Garbage Collector Mismatch
Interaction Type: Control
Connectors: Call, Trigger
Direction of Interaction: Bidirectional
Initiator: Either components A or B
Special Consideration: Components A and B must support both calls and triggers
Mismatch Identification: For every interaction between components A and B using a triggered call in an architecture:
If component B’s reconfiguration is ‘on the fly garbage collection’ and component A expects a bounded response time a mismatch can occur
Result: Component B’s response may be delayed resulting in undesired effects
118
IAM38: Encapsulation Instantiation Mismatch
“Incorrect assumption of which instantiation of an object is either sending or receiving
a data transfer.”
Two components interacting via a bridging data connector and at least one
component supports encapsulation. This can result in an incorrect assumption of
which instantiation of an object is sending or receiving data transfer resulting in
unexpected system behavior. A description of this mismatch is available in Table 52.
Table 52: Encapsulation Instantiation Mismatch
Interaction Type: Data and Control
Connectors: Data Connector, Trigger
Direction of Interaction: Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using data connector or trigger connector in an architecture:
If either components supports encapsulation a mismatch can occur
Result: Incorrect assumption of which instantiation of on object is sending or receiving data transfer resulting in unexpected system behavior
IAM39: Data Sharing Instantiation Mismatch
“Sharing data with the incorrect instantiation of an object.”
Two components are interacting via bridging shared data and at least one of the parts
involved supports encapsulation. This can result in data sharing with incorrect
instantiation of a component object. A description of this mismatch is available in
Table 53.
119
Table 53: Data Sharing Instantiation Mismatch
Interaction Type: Data
Connectors: Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using shared data connector in an architecture:
If either components supports encapsulation a mismatch can occur
Result: Incorrect assumption of which instantiation of on object is sending or receiving data transfer resulting in unexpected system behavior
IAM40: Different Response Time Granularity Mismatch
“Time represented/compared using different granularities.”
Two interacting components have response times different than unbounded or cyclic
unbounded and are distributed over machines that compare times with different
granularities. This can cause undesired effects for time-related communication. A
description of this mismatch is available in Table 54.
Table 54: Different Response Time Granularity Mismatch
Interaction Type: Data or Control
Connectors: Not applicable
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and in an architecture:
If the components are deployed on different nodes and both have response time values other than unbounded or cyclic unbounded, can cause a mismatch
Result: This can cause undesired effects for time-related communication
120
IAM41: Absolute Time Mismatch
“Absolute time values are off.”
Two interacting components have response times different than unbounded or cyclic
unbounded, and are distributed over machines that have failed clocks. This can cause
undesired effects for time-related communication. A description of this mismatch is
shown in Table 55.
Table 55: Absolute Time Mismatch
Interaction Type: Data or Control
Connectors: Not applicable
Direction of Interaction: Not applicable
Initiator: Not applicable
Mismatch Identification: For every interaction between components A and B in an architecture:
If the components are deployed on different nodes, a mismatch can occur if the nodes have failed clocks
Result: This can cause undesired effects for time-related communication
IAM42: Underlying Data Representation Mismatch
“Sharing or transferring data with differing underlying representations.”
Two interacting components communicating via data connector or shared data have
different underlying data representations, resulting in a communication failure. Note
that this mismatch will also be identified during interface mismatch analysis (IM4
and IM6). A description of this mismatch is shown in Table 56.
121
Table 56: Underlying Data Representation Mismatch
Interaction Type: Data
Connectors: Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional or Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using data connector, shared data or trigger in an architecture:
a mismatch can occur because of different underlying data formats, units and coordinate systems
Result: This can result in communication failure
IAM43: Resource Contention Mismatch
“Resource Contention”
Two or more components are deployed on the same node and at least one component
requires predictable response times. This can result in response times being affected
indirectly because resource contention was not initially accounted for. A description
of this mismatch is shown in Table 57.
Table 57: Resource Contention Mismatch
Interaction Type: Not applicable
Connectors: Not applicable
Direction of Interaction: Not applicable
Initiator: Not applicable
Mismatch Identification: For every component deployed in an architecture:
If two components are deployed on the same node and either components require a predictable response time a mismatch can occur
Result: Some resource contention which was not originally accounted for can occur affecting the response time.
122
IAM44: DBMS Heterogeneity Mismatch
“Potential database and/or DBMS heterogeneity problems may occur.”
Two or more data repositories are present resulting in problems on semantic
heterogeneity, differing data item granularity, distribution, replication and different
structural organization. A description of this mismatch is available in Table 58.
Table 58: DBMS Heterogeneity Mismatch
Interaction Type: Data
Connectors: Not applicable
Direction of Interaction: Not applicable
Initiator: Not applicable
Mismatch Identification: If an architecture has 2 data repositories a mismatch can occur
Result: This can result in communication failure
IAM45: Inaccessible Shared Data Mismatch
“Inaccessible Shared Data”
Table 59: Inaccessible Shared Data Mismatch
Interaction Type: Data
Connectors: Shared data
Direction of Interaction: Unidirectional and Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using shared data component C in an architecture:
If either components A or B cannot access C a mismatch can occur
Result: This can result in communication failure
123
Two components are interacting via a shared data connector. Communication is
effected through a third data component and one component does not have access to
the data repository causing communication failure. A description of this mismatch is
shown in Table 59.
IAM46: Distributed Control Units Mismatch
“Distributed control units are present.”
Two interacting components have distributed control units. Here components may
assume that the problem is being solved elsewhere by some other control unit. A
description of this mismatch is shown in Table 60.
Table 60: Distributed Control Units Mismatch
Interaction Type: Data
Connectors: Shared data
Direction of Interaction: Unidirectional and Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using shared data component C in an architecture:
If either components A or B do not have access to C a mismatch can occur
Result: This can result in communication failure
IAM47: Roll Forward Error Mismatch
“One component rolls forward upon error while the other component does not assume
roll forward.”
124
There are two interacting components where one rolls forward upon error while the
other component does not assume a roll forward resulting in undesired effects. A
description of this mismatch is available in Table 61.
Table 61: Roll Forward Mismatch
Interaction Type: Data and Control
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional and Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using call, spawn, data connector, shared data or trigger in an architecture:
If component A’s error handling supports roll forward and component B’s error handling does not support roll forward or assume it
Result: This can result in unexpected system behavior
IAM48: Roll Back Error Mismatch
“One component rolls back upon error while the other component does not assume roll
back.”
Table 62: Roll Back Error Mismatch
Interaction Type: Data and Control
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional and Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using call, spawn, data connector, shared data or trigger in an architecture:
If component A’s error handling supports roll back and component B’s error handling does not support roll back or assume it
Result: This can result in unexpected system behavior
125
There are two interacting components where one rolls back upon error while the
other component does not assume a roll back resulting in undesired effects. A
description of this mismatch is available in Table 62.
IAM 49: Error Handling Mismatch
“One of the components does not support any error handling mechanism”
There are two communicating components where at least one component does not
support any error handling mismatch resulting in synchronization issues, and other
undesired effects. A description of this mismatch is available in Table 63.
Table 63: Error Handling Mismatch
Interaction Type: Data and Control
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional and Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using call, spawn, data connector, shared data or trigger in an architecture:
If either component does not support an error handling mechanism a mismatch can occur
Result: The component that does not support error handling mechanisms will not decipher a failure resulting in a synchronization issues and unexpected system behavior
IAM50: Error Handling Synchronization Mismatch
“Two communicating components do not share common error handling mechanisms.”
There are two interacting components and they do not share common error handling
mismatches resulting in data synchronization issues and undesired system behavior.
126
Note that this conflict will also be identified as an interface mismatch (IM7). A
description of this mismatch is available in Table 64.
Table 64: Error Handling Synchronization Mismatch
Interaction Type: Data and Control
Connectors: Call, Spawn, Data Connector, Shared Data, Trigger
Direction of Interaction: Unidirectional and Bidirectional
Initiator: Either components A or B
Mismatch Identification: For every interaction between components A and B using call, spawn, data connector, shared data or trigger in an architecture:
If they do not share a common error handling mechanism mechanisms a mismatch can occur
Result: Upon failure neither components may be able to exchange error information resulting in synchronization issues and undesired system behavior.
6.3 Dependency Mismatch Analysis Rules
Dependency mismatch analysis rules enable identification of dependency
interoperability conflicts in a COTS-based architecture. The following sub-section
lists these dependency mismatches and corresponding rules utilized to identify them.
DM1: Communication Dependency Mismatch
Several COTS products require communicating with other components to fulfill
certain missing required functionalities. A common example of such an occurrence is
where customer relationship management [Sharp 2002] requires a database
management system [Silberschatz et al. 2005] to perform data storage and retrieval
function amongst others. This mismatch occurs when such a communication
dependency is missing in the architecture or there is no interaction between the
127
COTS product (A) and dependent component (B). Note that there can be multiple
options for dependent components (B) for any COTS product (A). A description of
this mismatch is available in Table 65.
Table 65: Communication Dependency Mismatch
Mismatch Identification: For every component in an architecture:
Identify communication dependency values for the component and evaluate the component’s interactions to verify if these dependencies are being met
If a dependency is not met a mismatch has occurred.
Result: The component will not function as required
Resolution: Add the missing product(s) and/or interaction in the architecture
DM2: Communication Incompatibility Mismatch
Table 66: Communication Incompatibility Mismatch
Mismatch Identification: For every component in an architecture:
Identify communication incompatibility values for the component and evaluate the component’s interactions to verify the component is communicating with any components listed in the communication incompatibility value.
If an interaction is found where the component is communicating with another component on the communication incompatibility attribute list a mismatch has occurred.
Result: The component interaction will not function as required
Resolution: Replace the incompatible component with an alternate compatible product with a similar functionality
COTS products often times have known incompatibilities with other components. For
example certain content management systems [Addey et. al 2003] are known to be
incompatible with certain database management systems [Silberschatz et al. 2005].
Communication incompatibility mismatch occurs when such an interaction exists.
Such a mismatch can be resolved by identifying an alternate component that can
128
replace the incompatible component. The incompatibility mismatch while easier to
identify, is more difficult to resolve because of economic, strategic and technical
considerations. A description of this mismatch is available in Table 66.
DM3: Execution Language Dependency Mismatch
COTS components require underlying frameworks, virtual machines or other
software components for executing its compiled or un-compiled code. For example a
Java program must be deployed on a Java runtime environment or an environment
which supports Java-byte code execution [Sun Java 1994]. An execution language
dependency mismatch occurs when such a COTS component (A) is deployed on a
product that cannot support execution A’s code. A description of this mismatch is
available Table 67.
Table 67: Execution Language Dependency Mismatch
Mismatch Identification: For every component in an architecture:
Identify deployment language attribute values for the component and evaluate if the component’s parent’s (i.e. where the component was deployed) execution language support attribute includes those languages.
If the parent component’s execution language support attribute does not support the component’s deployment language attributes a mismatch has occurred
Result: Product A will not function
Resolution: Deploy product A on a component which will support executing A’s compiled or un-compiled code
DM4: Same Node Incompatibility Mismatch
There are several cases where a component does not appropriately function when
deployed on the same node with another specific incompatible product, regardless of
129
whether they interacting with each other. This is often observed with different
versions of COTS products. One possible reason for such incompatibility is that both
components are competing for the same resources. A same node incompatibility
mismatch occurs when products A and B are incompatible when deployed on the
same node. Resolving such a mismatch requires redesigning the architecture of the
node where such a mismatch can occur. A description of this mismatch is available in
Table 68.
Table 68: Same Node Incompatibility Mismatch
Mismatch Identification: For every component in an architecture:
Check every component deployed with the component A’s same node incompatibility attribute
If there is a component that has been deployed on the same node as A and is in A’s same node incompatibility list a mismatch has occurred
Result: Product A and/or B will not function
Resolution: Redesign the architecture so that COTS product A and B are not on the same node
DM5: Underlying Dependency Mismatch
COTS products require support of other components to fulfill certain missing
functionalities. For example .NET based web applications [Microsoft .NET Framework
2007] require an Internet Information Services server [Tulloch 2003]. The underlying
dependency mismatch occurs when such COTS product dependencies are missing in
the architecture. It is not necessary that the COTS have explicit interaction with its
required components (such as described in communication dependency mismatch).
The COTS product may be deployed on its required component or the presence of the
component on the node may be sufficient enough for the COTS to function as
130
required. To resolve such a mismatch the architecture needs to be redesigned so that
product dependencies of COTS A are deployed on the same node with A. Description
of this mismatch is available in Table 69.
Table 69: Underlying Dependency Mismatch
Mismatch Identification: For every component in an architecture:
Identify underlying dependency values for the component A and evaluate the components on the same node as component A to verify if these dependencies are being met
If a dependency is not met a mismatch has occurred.
Result: Product A will not function
Resolution: Deploy product A’s dependency on the same node as A
The three groups of interoperability assessment rules form the intelligence of this
framework. The next section presents how these rules can be utilized to perform
interoperability analysis. Furthermore, to automate the interoperability analysis
process these rules are converted into a program. Architecture of such a program is
illustrated in section 8.
131
Chapter 7
Interoperability Evaluation Process
The COTS interoperability evaluation process is the third and final component of this
framework. This is a guided process that enables analysis of a COTS-based systems
architecture using COTS product definitions characterized using interoperability
representation attributes and interoperability assessment rules. This analysis will
enable the development team to estimate the amount of integration effort, which can
then become part of the COTS selection evaluation criteria and aid in the decision
making process. This section presents the guided process termed COTS
interoperability evaluator. One primary benefit of this process is that using the
attributes and interoperability assessment rules, this process can be significantly
automated – reducing the effort spent in analyzing COTS-based architectures.
The COTS interoperability evaluation process is illustrated in Figure 18. The process
has been designed for effective reuse across an organization. The COTS
interoperability evaluation process consists of two sub-processes – the
interoperability definition generation process and the interoperability analysis
process (indicated by the shaded block in Figure 18). The remainder of this section
will describe each of these two sub-processes in details.
132
Figure 18: COTS Interoperability Evaluation Process
7.1 Interoperability Definition Generation Process
This process involves building a COTS interoperability definitions repository. In an
organization the COTS interoperability experts (i.e. personnel with significant
amount of experience in COTS assessment) will be responsible for building the
maintaining such a repository. Building the definition repository is a multi-step
process:
1. The first step involves creating a standard representation format for storing
attributes and values in a COTS interoperability definition. This may be as
133
simple as attribute value pairs or a complex XML schema [Harold and Means
2004] for storing these values.
2. The second step entails identifying COTS products whose interoperability
characteristics are required. These will be requested by project managers
performing interoperability assessment for their respective projects.
3. The COTS interoperability experts will now research every product on the list
to identify their interoperability attribute values. Sources where such
information can be found include, but is not restricted to:
a. COTS product websites: Most general attributes, interface attributes
and some dependency attributes should be easily accessible from the
COTS product websites itself.
b. COTS product support team: For the attributes not identified from
COTS product websites, product vendors could be contacted to obtain
information. Alternately, product manuals could be utilized to identify
some of these attribute values.
c. Developers who have had experience in integrating the product: These
developers would be instrumental in identifying some dependency
values attributes such as same node incompatibilities and
communication incompatibility.
d. COTS product related newsgroups and forums: An alternative to
experience developers such newsgroups could be visited to identify
dependency attributes.
134
4. This information will then be stored in the format defined in step 1. Steps 2 to
4 will be repeated in order to create definitions for every product required for
assessment.
5. The final step involves maintaining these definitions and updating them as
new COTS product versions are released.
These COTS interoperability definitions stored in the repository will be used during
the COTS interoperability analysis process.
7.2 Interoperability Analysis Process
This process is responsible for guiding the development team to perform
interoperability assessment of the COTS-based system architecture. The process
follows the steps below:
P1 - Design COTS-based Architecture:
The process begins with the development team designing a COTS-based architecture.
The design includes placeholders for COTS products and their interactions. Every
interaction between two COTS or a COTS and custom products is characterized by:
Interaction type defines whether the interaction involves data exchange, control
exchange or both.
Direction of interaction indicates the direction of data flow, or control transfer; an
interaction can be unidirectional or bidirectional.
135
Initiator indicates bidirectional interactions that involve a query-response style of
operation where only one component is responsible for starting (or initiating) the
interaction. The initiator value indicates which component is responsible for starting
some feedback provided by subjects with industrial work experience between 4 to 20+
years.
“I think developing a framework for evaluation of COTS product selections is an excellent idea. At my company, there has been increasing interest in integration of COTS products, over the last 15 years or so. Although I have not been involved in any projects whose main focus was integration of COTS products, so far, I expect to eventually be involved in such projects. I can see how a framework such as this and a tool to support it could be very useful.”
“I think this COTS analysis framework is a good way to analyze the interoperability of COTS products for a given system design. I really like the way it determines dependencies of all the different components so that you can see if you are missing some critical components needed to support the rest of your design. It can help you to quickly identify glaring errors in terms of which components are necessary. I also like how the framework takes the given interface mismatches and translates them into a set of internal assumptions. It kind of shows how the effects that may be seen due to a given connector utilization.”
“The integration rules used in the framework are pretty thorough for analyzing mismatches in the deployment diagram. Some rules are more cryptic than others, but overall they do provide a foundation for an analyst to start redesigning the architecture so that mismatches can be eliminated.”
“The framework itself combined with Integration Studio tool is quite powerful at methodically considering all the factors that may come into play when combining COTS components together to produce a system. This tool holds a lot of promise, and the idea of collecting the relevant information of a COTS component and then providing a user friendly interface in which to allow a developer to combine it with other components and then see a compatibility analysis report is a very useful one.”
“Integration Studio and the underlying framework is a powerful tool to analyze COTS interoperability by an analyst with intermediate to advanced experience.”
“The Integration Studio tool provides a very effective interoperability assessment and analysis platform for various COTS-based architectures. Since majority of the systems now being manufactured are composed of COTS, widespread adoption and use of the tool presents a great opportunity to the practitioners to reduce risks and create better effort estimates.”
“The Integration Studio tool is useful in that it provides a clean interface with which to represent a COTS-based architecture. I believe that such a tool would
182
be useful in real world situations in which many disparate components and connectors are assembled in order to determine the viability of COTS-based system architectures.”
“Overall, I think this tool has promise and can be useful for someone who is really familiar with the COTS domain and has more than just cursory knowledge of the types of components under analysis.”
“The COTS interoperability evaluation framework provided gives us an excellent paradigm for analyzing the dependencies and interfaces among a given COTS architecture.”
In addition these and several other comments by experimental subjects provided
valuable feedback on improving the utility of Integration Studio tool.
9.6 Threats to Validity
Two types of threats to validity exist: controllable and uncontrollable [Campbell and
Stanley 1963]. Great care has been taken to make sure that this framework is a useful
model for COTS-based systems assessment. Experimental design, however, is not
perfect. Several external factors can affect the experiment and influence the overall
result. This section attempts to identify the most significant threats to the validity of
this framework and outlines ways in which they were reduced. This section will
discuss some validation threats that the experimental results may counter.
9.6.1 Controllable Threats
Inconsistent Effort Reporting
Threat: Effort reported by the subjects may be inaccurate.
Threat Control: For most the experiments at least 2 forms of effort reporting
mechanisms were employed:
183
• Using a post-experiment questionnaire, and
• Using the classroom effort reporting system.
During the experimental analysis, in situations where the two efforts did not match,
the issue was discussed with the subject in question (wherever possible) to accurately
identify the effort applied.
Learning Curve
Threat: There is a learning curve for candidates using this framework and those using
competing technologies.
Threat Control: Experiment subjects were provided with a 45 minute to 1 hour tutorial
in all 4 experiments. The tool has been designed so that it is extremely easy to use and
similar to Microsoft Visio or Rational Rose in look and feel. Candidates in the course
were trained in using both these tools. The tool utilized in validation experiments did
not employ any advanced notation, just simple boxes and lines, which further reduces
the need of a complex learning curve. Moreover the questionnaires required that the
efforts spent by subjects on tools and technology education, and actually applying
them to the projects are separately reported. Feedback received from experiment
subjects indicated that the tool lacked some desired features – such as copy paste,
group formatting, etc. However all subjects were able to use the tools without any
significant problems.
184
Non uniformity of motivation
Threat: Candidates in one group may have assumed that theirs is an inferior method
and will be de-motivated to perform well in these experiments.
Threat Control: Both groups were trained separately with regards to concepts of
interoperability mismatches in the classroom. Subjects were advised not to discuss or
collaborate with students from their own groups or with students from other group.
In addition while the grading criteria were uniform across both groups, they were
graded on separate curves for the purpose of this assignment.
Treatment Leakage
Threat: There is a possibility that the candidates from the control group obtained
access the information in treatment group and use it to identify mismatches.
Threat Control: During the experiments various security precautions were utilized.
These included:
• controlled dissemination of the tools utilized in validation experiments and
• unique identification key for every candidate in the experiment to access the
tool and related materials to ensure these treatments were not leaked.
In some cases where treatment leakage was identified those specific data points were
removed from this analysis.
185
9.6.2 Uncontrollable Threats
Non-representativeness of Projects
Threat: Experiments will involve projects developed in an advanced software
engineering course. There is a threat that such projects are not representative of
projects in the real world.
Threat Reduction: While the above may be true for some projects it is applicable for
most, especially those that are COTS intensive. This is because: projects developed in
the course are from diverse domains (research – medicine and engineering, library
information systems, and even industry). In addition projects developed at CSSE
utilize many of the COTS products that are used in industry projects (industry
strength databases, and application servers, commercial graphic tools). This has been
more visible of late because the industry has started accepting open source products
such as JBOSS [Davis 2005] application server as their primary platforms. Moreover
experiment C2 obtained similar results for industrial projects.
Uniformity of Projects
Threat: There is a possibility that the projects selected for these experiments will be
from the same domain, or have similar architectural style characteristics.
Threat Reduction: Of the two controlled experiments one experiment did include
cases utilizing web-based architectural style, however this was compensated from the
second controlled experiment (C2) where all selected projects were from different
domains and had distinct architecture styles.
186
Non representativeness of Subjects
Threat: The experimental candidate pools consisted of full-time masters’ level
students and a set of independent validation and verification (IV&V) students who
are full-time professional employees. There is a possibility that this pool does not
represent the industry candidates.
Threat Reduction: Many of the experimental candidates while full-time students come
to school with a certain amount of industry experience. Candidates work experience
information was collected as part of the course data collection. The experience
information for the two groups has been reported alongside experiment results.
Moreover researchers have shown [Höst et al. 2000] that under selected factors there
are only minor differences between conception of students and professionals; and
that there is no significant difference between correctness of students and
professionals.
Noisy Data
Threat: Effort data utilized in experimental analyses for experiments P1 and P2 from
past projects may be inaccurate.
Threat Reduction: In several cases where possible, the respective project team
members for past projects used were contacted to verify the interoperability
assessment and integration efforts that they spent in their projects.
187
Chapter 10
Conclusion and Future Work
10.1 Summary of Contributions
The present work on interoperability assessment and resolution framework makes the
following contributions to the body of knowledge:
1. A set of COTS interoperability representation attributes, extended from previous
works, to define interoperability characteristics of a COTS product. These are 42
attributes classified into four groups – general attributes (4), interface attributes
(16), internal assumption attributes (16) and dependency attributes (6). This
research added 16 attributes to the interoperability assessment literature.
2. A set of 62 interoperability assessment rules, also extended from previous works,
to identify interoperability mismatches in COTS-based architectures. These rules
are classified into 3 groups – interface mismatch analysis rules (7), internal
assumption mismatch analysis rules (50), and dependency mismatch analysis
rules (5).This research added and enhanced 15 rules interface, dependency an
internal assumption rules and updated several internal assumption rules to enable
identification of interoperability mismatches.
3. A guided process to efficiently implement the framework in practice.
4. An automated tool that implements 1, 2 and 3 in practice.
188
5. Integration of this technology with a real-world quality of service connector
selection in the area of voluminous data intensive connectors.
10.2 Framework Limitations
Following are some limitations of this framework:
• Accuracy of the framework relies significantly on COTS product interoperability
definitions. Errors in defining COTS interoperability characteristics will result in
imprecise mismatch analysis.
• The framework was found to provide less value in certain domains where COTS
components pre-dominantly follow a specific methodology of development and
adhere to strict standards of defining component interfaces. For example in the
gaming domain where most components are object oriented and a significant
amount of interaction takes place via APIs and method calls the framework will
not provide significant value-added analysis.
• This framework does not eliminate the need to prototype the application. It
provides a high-level assessment which can be used to filter candidate COTS
choices.
• A large part of effort reduction in the framework is due to the assumption that the
upfront effort required to build interoperability definitions is amortized across
multiple assessments. If this assumption fails, the application of this framework
may become more expensive than other methods (although the validations
demonstrated that the accuracy of this framework is better than current
methods).
189
10.3 Limitations of Validation
The empirical validation of this framework was primarily limited by the available data
and experimental subjects. The projects for 3 of the 4 experiments (P1, P2 and C1)
were taken from a university class. Only one experiment (C3) was conducted where
the projects were from the industry, however an accurate profile of mismatches that
occurred in these projects was unavailable. Given these constraints this validation has
the following drawbacks:
• There are a limited number of technologies in the research domain and almost
none in the industry domain to set a benchmark for this work.
• The entire evaluation of this framework was performed by means of a tool. This
validation does not account for human errors should this framework be used
manually by interested parties.
• Validation of this research has primarily involved information services and
network centric projects. Utility of this framework in has not been assessed in
other project types such as real-time embedded systems or safety-critical systems.
• The validation as performed evaluates the complete framework including the
three elements: interoperability representation attributes, interoperability
assessment rules and guided process for performing interoperability assessment
and its ability to be automated. This validation does not demonstrate which
elements within the framework are more useful over others.
• Correctness and completeness were demonstrated for only interface and
dependency interoperability assessment rules and not for internal assumption
190
rules. Incidence of internal assumption mismatches is largely dependent upon the
specific and detailed deployment characteristics of the system. Deployment
diagram information utilized by this framework is insufficient to substantiate the
occurrence of internal assumption mismatches. The framework however warns
the user where such mismatches could potentially occur.
The proposed framework thus requires further validation in the area of industrial
projects.
10.4 Future Work
This research has focused on providing the developers with a better and faster
decision analysis framework to maximize their trade-off space when selecting,
refreshing and integrating COTS products. There are several possible avenues of
future work. Some of these are:
1. Building and integrating this framework with quality of service extensions, such
as the voluminous data intensive extension already integrated with the
framework-based tool – Integration Studio.
2. Validate this research on projects across non-information system domains such as
real-time or safety-critical software.
3. The outline and concept behind this work can be utilized in performing
interoperability assessment in areas such as systems engineering. An avenue of
future work would include identifying attributes and rules that can enable
interoperability assessments in the systems engineering domain.
191
4. Currently manual intervention is required to transfer the mismatches identified in
the interoperability assessment report into source lines of glue codes estimate. An
automated model which could convert these mismatch results into source lines of
glue code estimates would eliminate this human intervention, and can provide a
completely automated system (along with COCOTS model) which will input an
architecture and output integration effort estimate.
192
Bibliography
[Abd-Allah 1996] Abd-Allah A. (1996). "Composing Heterogeneous Software Architectures." PhD dissertation, Computer Science Department, University of Southern California.
[Abts 2004] Abts C. (2004). "Extending the COCOMO II Software Cost Model to Estimate Effort and Schedule for Software Systems Using Commercial-Off-The-Shelf (COTS) Software Components: The COCOTS Model." PhD Dissertation. Industrial Systems Engineering Department, University of Southern California.
[Addey et. al 2003] Addey D., Ellis J., Suh P. and Theimecke D. (2003). "Content Management Systems (Tools of the Trade)." A-Press, ISBN 978-1590592465.
[Adobe Acrobat 1993] Adobe Systems (1993). “Adobe Acrobat Family.” Available at: http://www.adobe.com/acrobat/, accessed 2007.
[Albert and Brownsword 2002] Albert C. and Brownsword L. (2002). “Evolutionary Process for Integrating COTS-Based Systems (EPIC).” CMU/SEI Technical Report CMU/SEI-2002-TR-005.
[Allen and Garlan 1994] Allen R. and Garlan, D. (1994). "Formalizing Architectural Connection.” 16th International Conference on Software Engineering.
[Allen and Garlan 1997] Allen R. and Garlan D. (1997). "A Formal Basis for Architectural Connection." ACM Transactions on Software Engineering and Methodology.
[Apache 1999] The Apache Software Foundation (1999). “Apache.” Available at: http://www.apache.org/, accessed 2007
[Apache Tomcat 1999] The Apache Software Foundation (1999). “Apache Tomcat.” Available at: http://tomcat.apache.org/, accessed 2007.
[Apache Xerces 1999] The Apache Software Foundation (1999). “Xerces C++ Parser.” Available at: http://xml.apache.org/xerces-c/, accessed 2007.
[Apple Mac OS 1984] Apple Computer (1984). “Macintosh OS.” Available at: http://www.apple.com/macosx/, accessed 2007.
[ASCII 1963] American Standards Association (1963) "American Standard Code for Information Interchange." ASA Standard X3.4-1963.
193
[Ballurio et al. 2002] Ballurio K., Scalzo B. and Rose L. (2002). “Risk Reduction in COTS Software Selection with BASIS,” Proceedings of International Conference on COTS-Based Software Systems.
[Barret et al. 1996] Barret D., Clarke L., Tar P. and Wise A. (1996). "An Event-Based Software Integration Framework." Technical Report 95-048, University of Massachusetts.
[Basili and Boehm 2001] Basili V. and Boehm B. (2001). “COTS-Based Systems Top 10 List." IEEE Computer.
[Basili and Rombach 1991] Basili V. and Rombach H. (1991). “Support for Comprehensive Reuse.” Software Engineering Journal.
[Bhattacharya and Perry 2005] Bhattacharya S. and Perry D. (2005). "Contextual Reusability Metrics for Event-Based Architectures." Proceedings of International Symposium on Empiral Software Engineering.
[Bhuta 2006] Bhuta J. (2006). “A Framework for Intelligent Assessment and Resolution of Commercial Off-The-Shelf (COTS) Product Incompatibilities.” University of Southern California, Center for Systems and Software Engineering technical report USC-CSE-2006-608.
[Bhuta and Boehm 2007] Bhuta J. and Boehm B. (2007). “Attribute-Based COTS Product Interoperability Assessment.” International Conference on COTS-Based Software Systems.
[Bhuta et al. 2007] Bhuta J., Mattmann C., Medvidovic N. and Boehm B. (2007). “Framework for the Assessment and Selection of Software Components and Connectors in COTS-based Architectures.” Sixth Working IEEE/IFIP Conference on Software Architecture.
[Boehm 1996] Boehm B. (1996). "Anchoring the Software Process." IEEE Software, Volume 13, Issue 4.
[Boehm and Scherlis 1992] Boehm B. and Scherlis B. (1992) “Megaprogramming.” Proceedings of DARPA Software Technology Conference.
[Boehm et al. 1998] Boehm B., Egyed A., Port D., Shah A., Kwan J. and Madachy R. (1998). “A Stakeholder Win-Win Approach to Software Engineering Education.” Annals of Software Engineering Volume 6, Issue 1-4.
[Boehm et al. 1999] Boehm B., Abi-Antoun M., Port D., Kwan J. and Lynch A. (1999). "Requirements Engineering, Expectations Management, and the Two Cultures." Proceedings of IEEE International Symposium Requirements Engineering.
194
[Boehm et al 2000] Boehm B., Abts C., Brown A., Chulani S., Clark B., Horowitz E., Madachy R., Reifer D. and Steece B. (2000). "Software Cost Estimation with Cocomo II." Prentice Hall PTR, ISBN: 0130266922.
[Boehm et al. 2003] Boehm B., Port D., Yang Y. and Bhuta J. (2003). "Not All CBS Are Created Equally." Proceedings of Second International Conference on COTS-Based Software Systems.
[Boehm et al. 2003b] Boehm B., Port D., Yang Y., Bhuta J. and Abts C. (2003). "Composable Process Elements for Developing COTS-Based Applications." Proceedings of 2003 International Symposium on Empirical Software Engineering.
[Borland et al. 1997] Borland D., Coon R., Byers K., Levitt D., (1997). “Calibration of a COTS Integration Model Using Local Project Data.” Proceedings of the 22nd Software Engineering Workshop, NASA/Goddard Space Flight Center Software Engineering Laboratory.
[Brooks 1987] Brooks F. Jr. (1987). "No Silver Bullet: Essence and Accidents of Software Engineering." IEEE Computer, Volume 20, Issue 4.
[Brownsword et al. 2000] Brownsword L., Obnerndorf P. and Sledge C. (2000). “Developing New Processes for COTS-Based Systems.” IEEE Software, Volume 17, Issue 4.
[Callaghan 1999] Callaghan B. (1999). "NFS Illustrated." Addison-Wesley Professional Computing Series, ISBN 978-0201325706.
[Campbell and Stanley 1963] Campbell D. and Stanley J. (1963). “Experimental and Quasi-Experimental Designs for Research.” Houghton Mifflin Company, ISBN 978-0395307878.
[Carney 2001] Carney D. (2001). "Assembling Large Scale Systems from COTS Components: Oppurtinities, Cautions, and Complexities." SEI Monograph on the Use of Commercial Software in Government Systems.
[CODASYL 1976] CODASYL Systems Committee (1976). "Selection and Acquisition of Data Base Management Systems." ACM Press.
[Comella-Dorda et al. 2003] Comella-Dorda S., Dean J., Morris E. and Oberndorf P. (2002). "A Process for COTS Software Product Evaluation." Proceedings of First International Conference on COTS-Based Software Systems.
[Collidescope 2005] Software Engineering Architecture Team. (2005) "Collidescope." Available at http://www.seat.utulsa.edu/collidescope.php, accessed 2007.
[Davis 2005] Davis S. (2005). "JBoss at Work: A Practical Guide." O'Reilly Media, Inc., ISBN 978-0596007348.
[Davis et al. 2001] Davis L., Gamble R., Payton J., Jónsdóttir G. and Underwood D. (2001)"A Notation for Problematic Architecute Interactions." 3rd joint meeting of the European Software Engineering Conference and ACM SIGSOFT´s Symposium on the Foundations of Software Engineering.
[Davis et al. 2002] Davis L., Gamble R. and Payton J. (2002) "The Impact of Component Architectures on Interoperability." Journal of Systems and Software, Volume 61, Issue 1.
[DeLine 1999] DeLine R. (1999). "A Catalog of Techniques for Resolving Packaging Mismatch." Proceedings of Symposium on Software Reuse.
[Denning 1997] Denning A. (1997) "Activex Controls Inside Out." Microsoft Press, ISBN 978-1572313507.
[DeRemer and Kron 1975] DeRemer F. and Kron H. (1975). "Programming-in-the Large versus Programming-in-the-Small." Proceedings of the International conference on Reliable software.
[Dowkont et al. 1967] Dowkont A., Morris W. and Buetell T. (1967). "A Methodology for Comparision of Generalized Data Base Management System." PEGS Informatics, Inc.
[eBase 2004] "USC-CSE Experience Base Repository." Available at: http://ebase.usc.edu/, accessed 2007.
[eBay API 1995] eBay Inc. (1995) "eBay Developer Website." Available at: http://developer.ebay.com/common/api, accessed 2007.
[Elgazzar et al. 2005] Elgazzar S., Kark A., Putrycz E. and Vigder M. (2005). "COTS Acquisition: Getting a Good Contract." International Conference on COTS-Based Software Systems.
[Fielding 2000] Fielding R. (2000). “Architectural Styles and the Design of Network-based Software Architectures.” PhD Dissertation, University of California, Irvine.
[Fielding et al. 1999] Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P. and Berners-Lee T. (1999). "Hypertext Transfer Protocol -- HTTP/1.1." Request for Comments 2616.
196
[Gacek 1998] Gacek C. (1998). "Detecting Architectural Mismatches During System Composition." PhD dissertation, Computer Science Department, University of Southern California.
[Garlan et al. 1995] Garlan D., Allen R. and Ockerbloom J. (1995). “Architectural Mismatch or Why it’s hard to build systems out of existing parts.” Proceedings of International Conference on Software Engineering.
[Geiger 1995] Geiger K. (1995) "Inside ODBC." Microsoft Press, ISBN 978-1556158155.
[Glib 1969] Glib T. (1969) "Weighted Ranking by Levels." IAG Journal, Issue 2.
[Hacker 2000] Hacker S. (2000) "MP3: The Definitive Guide." O'Reilly Media, ISBN 978-1565926615.
[Harold and Means 2004] Harold E. and Means S. (2004) "XML in a Nutshell." O'Reilly Media, Inc., ISBN 978-0596007645.
[Höst et al. 2000] Höst M., Regnell B. and Wohlin C. (2000). “Using Students as Subjects - A Comparative Study of Students and Professionals in Lead-Time Impact Assessment.” Empirical Software Engineering, Volume 5, No 3.
[IEEE 90] Institute of Electrical and Electronics Engineers. (1990). "IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries." ISBN: 1559370793, The Institute of Electrical and Electronics Engineers Inc.
[ISO/IEC 14598-1 1999] International Organization for Standardization (1999). "Information Techonology – Software Product Evaluation." ISO/IEC 14598-1:1999.
[Kelkar and Gamble 1999] Kelkar, A. and Gamble, R. (1999). "Understanding The Architectural Characteristics Behind Middleware Choices." Proceedings of 1st Conference on Information Reuse and Integration.
[Keshav and Gamble 1998] Keshav R. and Gamble R. (1998). "Towards a Taxonomy of Architecture Integration Strategies." 3rd International Software Architecture Workshop.
[Kazman et al. 1997] Kazman R., Clements P., Bass L. and Abowd G. (1997). "Classifying Architectural Elements as Foundation for Mechanism Matching." Proceedings of 21st Annual International Computer Software and Applications Conference.
[Li 1998] Li W. (1998). "Another Metric Suite for Object-Oriented Programming." The Journal of Systems and Software, Volume 44, Issue 2.
[Linux 1994] Linux Online (1994). “Linux Online.” Available at: http://www.linux.org/, accessed 2007.
197
[Matlab 1994] MathWorks (1994). “Matlab - The Language of Technical Computing.” Available at: http://www.mathworks.com/products/matlab/, accessed 2007.
[Mattmann 2007] Mattmann C. (2007) "Software Connectors for Highly Distributed and Voluminous Data Intensive Systems," PhD Dissertation, Computer Science Department, University of Southern California.
[Medvidovic 2006] Medvidovic N. (2006). "Moving Architectural Description from Under the Technology Lamppost." 32nd EUROMICRO Conference on Software Engineering and Advanced Applications.
[Medvidovic and Taylor 1997] Medvidovic N. and Taylor R. (1997). "A Classification and Comparison Framework for Software Architecture Description Languages." IEEE Transactions on Software Engineering, Volume 26, Issue 1.
[Mehta et al. 2000] Mehta N., Medvidovic N. and Phadke S. (2000) "Towards a Taxonomy of Software Connectors." Proceedings of 22nd International Conference on Software Engineering.
[Meyers and Oberndorf 2001] Meyers B. and Oberndorf P. (2001) "Managing Software Acquisition: Open Systems and COTS Products," ISBN: 0201704544, Addision Wesley.
[Microsoft .NET Framework 2007] Microsoft Corporation (2007). “Microsoft .NET Framework.” Available at: http://msdn.microsoft.com/netframework/, accessed 2007.
[Microsoft Internet Explorer 2007] Microsoft Corporation (2007). “Microsoft Internet Explorer.” Available at: http://www.microsoft.com/ie, accessed 2007.
[Microsoft Office 2007] Microsoft Corporation (2007). “Microsoft Office.” Available at: http://office.microsoft.com/, accessed 2007
[Microsoft Windows 1985] Microsoft Corporation (1985). “Microsoft Windows.” Available at: http://www.microsoft.com/windows/, accessed 2007.
[Microsoft Office 2007] Microsoft Office (2007). “Microsoft Office.” Available at: http://office.microsoft.com/, accessed 2007.
[Mielnik et al. 2003] Mielnik J., Lang B., Lauriere S., Schlosser J. and Bouthors V., “eCOTS Platform: An Inter-industrial Initiative for COTS-Related Information Sharing.” Proceedings of Second International Conference on COTS-Based Software Systems.
[Miano 1999] Miano J. (1999) "Compressed Image File Formats: JPEG, PNG, GIF, XBM, BMP." Addison-Wesley Professional, ISBN 978-0201604436.
198
[Morisio et al. 2000] Morisio M., Seaman C., Parra A., Basili V., Kradt S. and Condon S. (2000). "Investigating and Improving a COTS-Based Software Development Process." Proceedings of 22nd International Conference on Software Engineering.
[MySQL 1995] MySQL AB (1995). “MySQL Database System.” Available at: http://www.mysql.com/, accessed 2007.
[Ockerbloom 1998] Ockerbloom J. (1998). "Mediating among Diverse Data Formats." PhD Dissertation, Computer Science Department, Carnegie Mellon University, 1998.
[OMG CORBA 1997] Object Management Group (1997). “Common Object Request Broker Architecture (CORBA).” Available at: http://www.corba.org/, accessed 2007.
[Owl 2004] "OWL Web Ontology Language Overview." Available at: http://www.w3.org/TR/owl-features/, accessed 2007.
[Perry and Wolf 1992] Perry D. and Wolf A. (1992). "Foundations for the Study of Software Architectures," ACM SIGSOFT Software Engineering Notes, Volume 17, Issue 4.
[Postel and Reynolds 1985] Postel J. and Reynolds J. (1985) "File Transfer Protocol." Request for Comments (RFC) 959.
[PHP 2001] The PHP Group (2001). "PHP Website." Available at: http://www.php.net/, accessed 2007.
[Sharp 2002] Sharp D. (2002). "Customer Relationship Management Systems." Auerbach, ISBN 978-0849311437.
[Shaw 1993] Shaw M. (1993). “Procedure Calls are Assembly Language of Software Interconnections: Connectors Deserve a First Class Status.” Proceedings of Workshop on Studies of Software Design.
[Shaw 1995] Shaw M. (1995). "Architectural Issues in Software Reuse: It's Not Just the Functionality, It's the Packaging," Proceedings of the Symposium on Software Reuse at the 17th International Conference on Software Engineering.
[Shaw et al. 1995] Shaw M., DeLine R., Klein D., Ross T., Young D. and Zelesnik G. (1995). "Abstractions of Software Architecture and Tools to Support Them." IEEE Transactions on Software Engineering, Volume 21, Issue 4.
[Shaw and Clements 1997] Shaw M. and Clements P. (1997). "A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems." Proceedings of 21st International Computer and Applications Conference.
199
[Shaw and Garlan 1996] Shaw M. and Garlan D. (1996). "Software Architecture: Perspectives on an Emerging Discipline." ISBN: 978-0131829572, Prentice Hall.
[Silberschatz et al. 2005] Silberschatz A., Korth H. and Sudarshan S. (2005). "Database Systems Concepts." McGraw-Hill, ISBN 978-0072958867.
[Sitaraman 1997] Sitaraman R. (1997). "Integration Of Software Systems At An Abstract Architectural Level." M.S. Thesis, University of Tulsa.
[Smith et al. 1997] Smith R., Parrish A. and Hale J. (1997). "Component Based Software Development: Parameters Influencing Cost Estimation.” Proceedings of the 22nd Software Engineering Workshop, NASA/Goddard Space Flight Center Software Engineering Laboratory.
[Sourceforge 2001] Open Source Technology Group (2001). “Sourceforge.” Available at: http://www.sourceforge.net/, accessed 2007.
[Spitznagel and Garlan 2001] Spitznagel B. and Garlan D. (2001). "A Compositional Approach for Constructing Connectors," Proceedings of Working IEEE/IFIP Conference on Software Architecture.
[Standish 2001] “Extreme Chaos.” 2001 update to the CHAOS report available at: http://www.standishgroup.com/, accessed 2007.
[Student 1908] Student. (1908) "The Probable Error of a Mean." Biometrika 6.
[Sullivan and Knight 1996] Sullivan K. and Knight J. (1996). "Experience Assessing an Architectural Approach to Large-Scale Systematic Reuse," Proceedings of 18th International Conference of Software Engineering.
[Sun Java 1994] Sun Microsystems (1994). “Sun Developer Network.” Available at: http://java.sun.com/, accessed 2007.
[Sun Solaris 1989] Sun Microsystems (1989). “Solaris Operating System.” Available at: http://www.sun.com/solaris/ accessed 2007.
[Unicode 2003] The Unicode Consortium, Aliprand J., Allen J., Becker J., Davis M., Everson M., Freytag A., Jenkins J., Ksar M., McGowan R., Muller E., Moore L., Suignard M. and Whistler K. (2003). "The Unicode Standard, Version 4.0." Addison-Wesley Professional, ISBN 978-0321185785.
[USC CSSE 1995] “University of Southern California, Center for Systems and Software Engineering.” Available at: http://csse.usc.edu/, accessed 2007.
[W3 HTTP 1996] World Wide Web Consortium (1993). “Hypertext Transfer Protocol.” Available at: http://www.w3.org/Protocols/, accessed 2007.
200
[W3 HTML 1999] World Wide Web Consortium (1999). “HTML Specification.” Available at: http://www.w3.org/TR/html401/, accessed 2007.
[Xu and Randell 1996] Xu J. and Randell B. (1996). "Roll-Forward Error Recovery in Embedded Real-Time Systems." In proceesings of International Conference on Parallel and Distributed Systems.
[Yakimovich et al. 1999a] Yakimovich D., Bieman J., and Basili V. (1999). "Software Architecture Classification for Estimating the Cost of COTS Integration." Proceedings of 21st International Conference on Software Engineering.
[Yakimovich et al. 1999b] Yakimovich D., Travassos G., and Basili V. (1999). "A Classification of Software Component Incompatibilities for COTS Integration." Proceedings of 24th Software Engineering Workshop.
[Yakimovich 2001] Yakimovich D. (2001). "A Comprehensive Reuse Model for COTS Software Products." PhD Dissertation, University of Maryland, College Park.
[Yang and Boehm 2004] Yang Y. and Boehm B. (2004). “Guidelines for Producing COTS Assessment Background, Process, and Report Documents.” USC CSSE Technical Report, USC-CSE-2004-502.
[Yang et al. 2005] Yang Y., Bhuta J., Boehm B. and Port D. (2005). "Value-Based Processes for COTS-Based Systems." IEEE Software Special Issue on COTS-Based Development, Volume 22, Issue 4.
[Yang 2006] Yang Y. (2006). "Composable Risk-Driven Processes for Developing Software Systems from Commercial-Off-The-Shelf Products." PhD dissertation, Computer Science Department, University of Southern California, 1996.
[Zelesnik 1996] Zelesnik G., “The UniCon Language Reference Manual,” Available at: http://www-cgi.cs.cmu.edu/afs/cs/project/vit/www/unicon/reference-manual/Reference_Manual_1.html, accessed 2007.