Database Reference
In-Depth Information
1. They use a CBD approach.
2. They are in favor of using CBD and knowledgeable in CBD methods.
3. They are training their staff on CBD.
4. Their knowledge of CBD is based on a certain CBD method.
5. They have their own CBD approach developed on the basis of their OO methodol-
ogy.
The fi rst cut of the evaluation framework was presented to the industry expert panel
and refi ned based on their comments. The resulting framework has been used to evaluate
the selected six CBD methods.
The academic group was given the assignment to study two CBD methods from the
six selected methods, and based on their knowledge to assign a number between one and
fi ve for each requirement in the evaluation framework. The academic group of 42 students
was divided into six groups of seven members, while the industry expert panel consisted of
16 members. The evaluation was fi rst conducted by the authors of this paper and compared
with the evaluation of the academic group ratings. The majority of the ratings of the authors
and the academic groups were the same but there were some differences in few cases, with
maximum of two points of difference. In such cases the average was taken. Finally the evalu-
ation framework was presented to the industry expert panel and asked for their evaluation.
They were asked to evaluate only the methods they are familiar with. Their evaluations were
similar in most cases with some exceptions—as the difference was not greater than two
points the average was taken. A summary of the evaluation of CBD methods RUP, Select
Perspective, Catalysis, KobrA, UML Components and Business Component Factory based
on the requirements evaluation framework proposed above is presented in Table 2.
Findings
Summarizing our fi ndings, we see that the idea of CBD and SOA is not yet fully in-
tegrated in the investigated methods. Components and services do not yet become the real
focus of the methods. The concepts of component and service are not properly and clearly
defi ned and specifi ed yet. Components are often at the level of packaging of software code,
or old-fashioned business objects. However, during the last years there have been positive
signs in this direction together with the emerging of the new version of the UML 2.0 that
treats components at both a logical and implementation level. Semantics and character-
istics of components and services are mainly defi ned informally using prose text. More
recent CBD methods propose an extended version of the interface concept beyond simple
signatures of operations. They specify pre-conditions and post-conditions on operations, as
well as information type model of the interface, but they still lack, among other things, the
coordination aspects of operations, confi guration mechanisms, and non-functional param-
eters. The importance of defi ning different scope and granularity levels of components, as
well as their recursive composition, has been truly recognized only in Business Component
Factory approach.
Regarding the way of modeling, the investigated methods are based on the current
version of the UML, and based on that defi ne proper extensions to represent necessary
component and service concepts they utilize. Modeling from different viewpoints is an
important mechanism in Business Component Factory. Rigorous component specifi cation
is to some extent provided in Catalysis and UML Components, while model reusability is
