Professional Documents
Culture Documents
ABSTRACT
Software in the modern age are mostly developed by the 1. INTRODUCTION
integration of pre fabricated COTS components as it is the simplest
way to develop systems quickly consuming lesser cost as compared
to the traditional development approaches. The promising features Efforts have been made, right from emergence of software
of component-based-software-engineering (CBSE) have introduced engineering to improve software development process with special
new idea of assembling-software rather than building them. emphasis on design to develop more significant notations to
Assembling software in this way alternatively results in rapid confine and capture the proposed functionality of system, along
development, lesser cost with quality software assembled from pre with encouraging the development of systems by reusing already
tested COTS components. However the task is not as easy as it developed components rather than developing from initial. Each
appears apparently. Assembling software from the existing success in these endeavours helped organizations to maintain and
components presents other challenges among which the improve the quality, maintainability, and flexibility of complex and
“integration time mismatches” is the one. critical systems developed for broad category of domains.
Various strategies have been proposed to overcome these However organizations, having large-scale and complex
mismatches each requiring some external mechanism outside the applications development, still face a lot of problems, especially
component to solve them. while testing and updating the systems. So until systems are not
This paper is an endeavour to provide an integrated approach for designed carefully, they may be costly, in terms of cost and time to
resolving integration time semantic mismatches. It enables COTS enhance the functionality further, and to test the systems updations
components to detect semantic mismatches and resolve them by effectively and efficiently. Furthermore, the ever-growing demand
themselves, thus letting the COTS component itself to participate in for unprecedented complex software has made software engineers
mismatch resolution process. seriously think in terms of code reusability, as the software sizes in
The external mediation, in this way, will be reduced up to excess of 10 million lines are a practical reality. Such system may
maximum, resulting in a smooth integration process with a cut- have even a decade of development period, alternatively facing the
down in integration cost. The proposed approach will further challenges of changing requirements and different other
enhance the fault tolerance capabilities of COTS components as it parameters, obviously demanding a clear shift towards “Assembly
is used more and more. of code” instead of “building from scratch” approach and using
COTS products is one way to implement this strategy, because
software development then becomes the process of “simply”
KEYWORDS integrating COTS components.Engineering practices to support
Components, COTS, CBSE, semantic mismatches, enhanceable code reuse – CBSE - is the need of time.
semantic thesaurus (EST) However despite the benefits of reuse, there are factors that
directly or indirectly influence the success or failure of reuse.
These factors may be of technical, conceptual, organizational,
managerial, economic, psychological, or legal nature [1].
Integration time mismatches are just one to name. Even, when we
Permission to make digital or hard copies of all or part of this work have selected the appropriate components according to
for personal or classroom use is granted without fee provided that requirements, some other fundamental issues may still prevail like
copies are not made or distributed for profit or commercial one that chosen parts do not fit together well. The integration of
advantage and that copies bear this notice and the full citation on such components results in no. of critical faults and inconsistencies
the first page. To copy otherwise, or republish, to post on servers [2] called “Architectural Mismatches” [3]. Resulting from the
or to redistribute to lists, requires prior specific permission and/or a mismatched assumptions a reusable part makes about the structure
fee. of the target system arise due to the mismatched assumptions a
FIT '10, 21-DEC-2010, Islamabad, Pakistan reusable part makes about the structure of the target system [4],
Copyright © 2010 ACM 978-1-4503-0342-2/10/12…$10.00 these mismatches not only lead towards grave consequences, but
also require some intermediate mediation mechanism, the
Wrapper/Glue Code, to overcome the problem. This mediation In [2] Sglietti et al. present an approach to detect and tolerate
mechanism is required as many times as the component is reused, architectural inconsistencies. They categorize architectural
not only for the same component while integrating in different mismatches in different classes and tend to implement a wrapper
applications, but also for its later versions. This entail the first that separately handles these mismatches.
attention of the researchers to come with the solutions of the They mainly identify integration anomalies in four classes:
number of problems adhere to CBSE. Syntactic inconsistencies: inconsistency in the representations of
This paper is a consequence of motivation for this obligation and data imported/exported to/from component.
provides the solution for solving one of the integration time Semantic inconsistencies: inconsistency of semantic nature e.g.
mismatches problem. exchanging the data with different semantics
In rest of the paper, section-2 describes some categories of Application-based inconsistencies: may occur if the local
architectural mismatches and different negotiation approaches functionalities of components fail to accurately represent the global
proposed in literature so far. Section-3 provides brief introduction application context.
of Enhanceable Semantic thesaurus (EST) while section-4 Pragmatic inconsistencies: pragmatic inconsistencies are
elaborates different features of EST. Section-5 provides details concerned with component’s computational environment. E.g.
about implementation of EST where as section-6 presents some access policies to external resources, timing requirements and
case studies to verify the proposed research, section-7 provides other architectural constraints etc.
structure of implementation and finally analysis of results has been These classes are further classified in sub-classes as shown in table
given in section-8. 1.
2. Architectural Mismatches: Classification Table 1: Architectural inconsistencies and sub-
Negotiation Approaches: classification.
Semantic App-based Pragmatic
1. language 1. violation of 1. violation of
The term “Architectural Mismatch” was first coined by Garlan et. 2. numerical state/input absolute time
all in [3]. While developing AESOP, they came across six main 3. physical relation constraints
difficulties during integration of four existing software subsystems 2. data range 2. violation of
(components) into a new coherent system: extensive code size, concurency
poor performance, extensive modification required to get reused constraints
subsystems to work together, the necessity of reinventing existing 3. violation of
functionality to meet the intended use, redundant complexity of architectural
applications built from reused systems, and a complex, error-prone constraints
system development process [4]; Root causes of these mismatches
were divided in four broad categories: Nature of the components, Keshav et. al [6] discuss their preliminary findings from
Nature of the connectors, Global architectural structure, and architectural style integration analysis. They form an integration
Construction process [4]. Four guidelines were proposed by them taxonomy comprising of three main functional integration
[4] to overcome these mismatches elements: Translator, Controller and Extender.
o Architectural assumptions should be made explicit. A Translator translates both the data and functions between
o Large pieces of software should be developed from different component formats; however contents of the information
orthogonal subcomponents. are not changed. It does not need knowledge of source/destination
o Techniques should be provided for reconciling of data
mismatches. A Controller based on some predefined decision making process,
o Sources for architectural design guidance should be a controller coordinates and negotiates the information exchange
developed. between components. It does however need to know the exact
In fact study of Garlan et. all provided a solid base for further component identities for which decisions are being made.
research to deal with architectural mismatches. An Extender adds new features and functionality, and hence
In [5] Yakimovich et el. presented two major causes of COTS augments component capability. Whether or not the Extender
interaction incompatibilities: syntax and semantic-pragmatic. needs to have the knowledge of component identity with which it
Syntax defines the syntactic rules, where as the functional interacts, depends upon specific application.
interaction specifications are defined by semantic-pragmatics. Authors also propose to combine these basic integration elements
Syntactic differences among the components result in syntactic to make possible, the interaction of different components
incompatibilities. Semantic-pragmatic incompatibilities, on the combinations.
other hand, can arise out of the conflict in components interaction. Robert DeLine in [7] provides a catalog of tools and techniques to
The semantic pragmatic incompatibilities are further classified as: negotiate packaging mismatch, organized according to underline
Ø 1-order semantic-pragmatic incompatibility or internal architectural commitment: on-line and off-line bridges, wrappers,
problem: caused by a single component. E.g. it may be that intermediate representations, mediators, unilateral and bilateral
this component does not fulfill the required functionality. negotiation, and component extension. All these techniques are
Ø 2-order semantic-pragmatic incompatibility or a mismatch: explained with the help of an example system consisting of two
incompatibility occurred due to interaction of two components A and B that exhibit incompatibilities while
components. interacting with each other.
Ø N-order semantic-pragmatic incompatibility: incompatibility On-line bridge: in this method a new component (Br - bridge
caused due to interaction of several components. component) is introduced between the interacting components A
and B. Br implements a separate interface for each of the 3.1 Enhanced domain analysis:
components involved in interaction.
During this phase the target domain of component is analyzed to
Off-line bridge: is a special version of on-line bridge except that
understand the problem and component requirements. EST
the component B is some form of persistent data. Now the bridge
implementation requires an extra consideration to be made to
component Br reads data of B and transforms it to be compatible to
traditional domain analysis phase. It emphasizes to identify and
A. This component transforms component B to B’ which then
model all the possible semantics of data that the component will
interacts with component A.
import and export during its interaction with target application.
Wrapper: in this method the bridge Br and the component B are
E.g. in case, the parameters of a certain service call include the
wrapped together to form a new component B’, this component
price of an item, we need to consider all the possible currencies,
than interacts with component A.
the target application may be deemed to use.
Mediator: in this method the connector C can support several
The process of modeling all the possible data semantics will enable
alternatives (interfaces) for a given commitment (often about data
the COTS to be enriched semantically so that it may be capable to
representation). Components A and B can use any of the provided
negotiate semantic mismatches during interoperation, in case any
commitment to interact with each other.
semantic mismatch is detected.
Intermediate Representation: just like Mediator technique, with
This requires a comprehensive analysis and thorough study of all
the restriction that the mismatch between A and B is caused by
possible target contexts. A history of other COTS from the same
data representation. Connector C can support several alternatives
family and some possible target applications will be more helpful
(interfaces) for a given commitment about data representation.
in this regards.
Unilateral negotiation: In this technique a single component (A)
supports multiple commitments, and if the other component’s (B’s)
commitment is supported by it (i.e by A) then A is specialized to 3.2 Enhanced COTS internal design:
match B’s commitment and they are integrated. COTS components are a collection of domain objects that
Bilateral negotiation: in this technique both component support a interoperate to provide the intended functionality. The
set of alternative commitments and agree upon a protocol for functionality is provided by using external interfaces. In fact an
selecting one of the alternatives by negotiating with each other. interface is an invoking point of a COTS component. Figure 1.
Component extension technique: In this technique a component
provides mean for its extension. It defers some of the commitments
about interaction by assigning these commitments to a set of
modules integrated while the component is initialized at runtime Interface
Domain Domain
3. Enhance able Semantic Thesaurus (EST) Object Object
Semantic Thesaurus
Enhance able:
An important feature of EST, as the name indicates, is its ability of
being enhance able. This means that if the semantics (considered
by target application) of any data are not defined in EST (one of Interaction Interface
the situations leading to semantic mismatch), they can be added
using a simple interface (explained in next session). In fact this
feature enables the COTS itself, to participate in mismatch Figure 3: EST Component
resolution process which otherwise requires intensive external
mediation work.
5.2 Conflict Resolution & Thesaurus Control
Mismatch elimination with passage of time: Mechanism:
Probability of semantic mismatches reduces as much as the This feature enables the EST component to resolve the mismatch
component gets used. This is because EST gets populated with and negotiate it, on the basis of the terms defined in Semantic
more and more semantics, which alternatively `augments the Thesaurus.
component’s fault tolerance capability and increases component All the thesaurus related processing is performed by this sub-
strength to participate in mismatch resolution process. component, e.g resolve the mismatch, add new semantics in
It also means that the later versions of COTS component will less Thesaurus, delete semantics from thesaurus etc.
error prone as compared to earlier versions It is the key feature of EST component that enables the main
COTS component to participate in mismatch detection and
resolution process, and hence eliminates the external mediation
mechanism required to resolve the mismatches otherwise.
Semantic Thesaurus
Each component was responsible to complete the command, and In this case study the final Off the Shelf component “NMATH” by
provide the results back to the CLI. “CenterSpace” [12] was integrated with MathType.
The same amount of wrapper code had to be re-written however as
we had already developed the wrapper code so those wrapper
6.2. Case Study 1 classes were used again. All the classes defined in Table-2 were
reused. Also no “CDataConv” class was required as there was no
In first case study a mathematical component “Extreme data type mismatch.
Optimization Numerical Library (EONL) version 3.0” by Extreme
Optimization [10] was integrated with MathType.
Table-2 shows the list of classes developed corresponding to each
6.4. eCalculus:
type of semantic mismatch
eCalculus was the in-house developed Off-The-Shelf mathematical
Table-2: List of wrapper classes component, integrated to verify the proposed solution. The
Data Semantics Explanation architecture of this component was based on the model that was
Number System complied with the proposed design.
Binary Converts data with binary Possible semantics were integrated as subcomponent with in
Class: CBin semantic to any other “eCalculus”, in order to avoid semantic mismatches, and
semantic consequently minimize the external mediation.
Octal Converts data with Octal Further more the scope of semantics with in eCalculus was kept
Class: COct semantic to any other open to enhance the semantic thesaurus with minimum effort.
semantic
Decimal Converts data with Decimal
Class: CDec semantic to any other 7. Structure of eCalculus
semantic
Hexadecima Converts data with 7.1 Semantic Thesaurus:
Class: CHexl Hexadecimal semantic to any
other semantic Semantic thesaurus was implemented using flat files, all the
N-Number System Converts data with N-Number possible semantics were saved in thesaurus using (Key, Value)
Class: CNmN system semantics to other structure.
semantic e.g. in case of angle mode the thesaurus had following entries
Angle Mode (Table-3):
Degree Converts Degree mod to any
Table-3: Thesaurus for Angle mode EST component to add those semantics and update the semantic
Index 0 1 2 3 4 thesaurus.
“AM_CUST_” keys at indexes 5,6… indicate the open scope of
Key AM_ AM_ AM_ AM_ AM_ thesaurus where new semantics can be added by the user. However
DEG RAD GRAD CUS_ CUS_ the semantics must be defined in terms of default angle mode of
component i.e. any value of custom semantic defined by user must
value 1 0.0174 1.111 - -
be equal to 1 degree.
532 As eCalculus uses MOD_DEG as the default angle mod for
trigonometric functions, so all the parameters for trigonometric
AM_DEG key at index “0” represents the default mode of the functions that will be in “degree mode”, they will require no
component i.e. component performs all the trigonometric conversion in their mode. However, all the other angle modes will
calculations in degree mode. be first converted in “degree mode” before applying any
trigonometric function on them. But one thing the worth noting is,
that any parameter received in angle mode other than “degree” will
not be considered as a semantic mismatch, unlike the mathematical
Application CU EST MFC components used in previous case studies, so no external code will
Component be required as the EST component’s mismatch resolution
mechanism will resolve the conflict by converting it to “degree”
mode by itself, after reported by CU.
Similarly the semantic thesaurus for Number Systems was defined
1. Call (Table-4):
Request
2. Semantics
Table-4: Thesaurus for Numeric System
mismatch
detected Index 0 1 2 3 4 5
Key NS_BI NS_ NS_ NS_HE NS_ NS_
3. Call
forwarded N OCT DEC X CUS CUS
to EST _ _
value 2 8 10 16 -
4. Mismatch
Resolved
5. Call Here the key “NS_BIN” represents the binary number system and
forwarded the value of “2” of this key represents the base. Similarly the key
to MFC “NS_OCT” represents the octal number system and the value “8”
of this key represents the base.
6. Task
The keys “NS_CUS_” at indexes 4, 5,… represent the open scope
performed of thesaurus where user can add its own semantics.
In order to verify the result of case studies, the wrapper code Number System
written in each case was compared ( Table-6 ). The number of Binary
“wrapper classes” written was used to conclude about the size of Class: CBin
the code and finally this metric was provided as an evidence to Octal
prove the validity of the proposed solution. Class: COct
Decimal
Class: CDec
8.1 Wrapper code size and Customizability: Hexadecimal
Class: CHex
N-Number System
The number of “wrapper classes” written in each case was used as Class: CNmN
source to conclude the size of the code. Each wrapper class Angle Mode
contained the LOC containing 70 to 100 SLOC.
However the wrapper required in “eCalculus” was of minimum Degree
Class: CDeg
and included the only class “CDataConv” to convert the data
Radians
formats as was required in case of EONL along with an additional Class: CRad
parameter to “eCalculus” function calls, including the semantics of Grad
parameter in “Key, Value” form, e.g. the following function call Class: CGrad
shows the request for the Arch Cosine of the specified value. N-Angle Mod
Class: CAmN
IExtern::tig.cos(“0.345”, “MOD_RAD”);
Here the angle value is provided in “Radian” mod and the key The minimum value of FP obtained for eCalculus clearly shows
“MOD_RAD” specifies the component to calculate the results in the minimum effort, required to integrate the components, based
Radians. on the proposed solution.
Table-5 shows the comparison of wrapper classes (code) that were
written for each of the case study
Table-6: Table of Metrics solution leads us to develop COTS components which could be
customized by configuration and not through adaptation. EST also
Factors and Metrics Components enhances the fault tolerance capabilities of COTS with passage of
Factor Metric EONL Scinet NMAT eCalculu time as the COTS is used more and more. Components become
Math H s highly portable with minimum probability of semantic mismatches,
Customi- RCC 0 0.5 0 1 and the most of all is that all of its features are provided without
zability compromising any performance measure.
Size of FP 2.53 2.35 2.53 0.36 It provides us further inspiration to develop COTS which could
wrapper KSLOC 0.7 0.65 0.7 0.10 have fault tolerance not only for semantic mismatches but for all
code
types of architectural mismatches highlighted so far.
WMC 4,5 5 5 2
2
References:
1.5 [1] Johannes Sametinger. 1997. Software engineering with
1 reusable components. page no. 11
0.5 0.36