cots terminology and categories: can we reach a consensus?
TRANSCRIPT
International Workshop on
COTS Terminology and Categories:
Can We Reach a Consensus?
(IWCTC 2004) http://softeng.polito.it/iwctc/
February 1, 2004
Redondo Beach (CA), USA
Organizers
Betsy Clark Marco Torchiano [email protected] [email protected]
Co-located with International Conference on COTS Based Software Systems
(ICCBSS 2004)
Table of Contents
Introduction. .................................................................................................................................... 1 Betsy Clark, Marco Torchiano
What is COTS?................................................................................................................................ 3 Maurizio Morisio, Victor Basili
Building Sound COTS Products Taxonomies................................................................................. 5 Juan P. Carvallo, Xavier Franch, Carme Quer, Marco Torchiano
eCots................................................................................................................................................ 9 Stéphane Laurière, Jean-Christophe Mielnik
Empirical Study on COTS Components Classification ................................................................ 13 Jingyue Li, Finn Olav Bjørnson, Reidar Conradi
An informal COTS Specification Model – Enabling Component Acquisition............................. 17 Benneth Christiansson, Marie-Therese Christiansson
International Workshop on COTS Terminology and Categories: Can We Reach a Consensus?
Betsy Clark, Marco Torchiano
Presentation There are a variety of classification schemes related to COTS products. Desktop applications, math libraries, operating systems and complex enterprise resource planning (ERP) product suites are all examples of COTS products but differ dramatically in their scope, resource requirements to implement and associated risks. The Terminology Panel held during ICCBSS 2003 was a surprising "sleeper" in generating lively discussion about the lack of standard terms, definitions, and categories. As a follow up, during this workshop, we will examine alternative categorization schemes and COTS-related definitions. Our objective will be to arrive at a consensus where possible and more clearly identify areas where differences of opinion exist.
The workshop will cover the following topics:
• Definition of COTS and related terms (e.g., NDI)
• Types of systems (e.g., COTS-Solution versus COTS-Intensive)
• Components, packages, products
• Types of components both functional and problem-oriented classifications
• COTS-Based System, COTS-Based Application
• Organizational issues: familiarity with products/architecture, integrator/vendor relationships
• “Easy COTS” and “Hard COTS” (Basili talked about this in his 2003 ICCBSS Keynote)
• Reference process in terms of typical COTS-related activities (assessment/evaluation, tailoring, glue code), roles involved (vendor, customer, users, integrator), and artifact (COTS component, COTS-based system)
Location The workshop will be in the Crowne Plaza Redondo Beach and Marina in Redondo Beach, CA on February 1, 2004 between 1-6.30pm. The closest airport is the Los Angeles International Airport (LAX). Registration fee is USD 75. Please use the ICCBSS 2004 conference web site to register for the workshop.
1
Agenda The workshop is divided into two parts.
During the first part the authors of position papers will have 15 minutes each to present their position to all the participants.
In the second part an open discussion (with the participation of both papers authors and other participants) will take part.
When What Who
1:00 - 1:20 Welcome, Introductions Betsy Clark, Marco Torchiano
1:20 - 1:35 What is COTS? Maurizio Morisio, Victor Basili
1:35 - 1:50 Building Sound COTS Products Taxonomies
Juan P. Carvallo, Xavier Franch, Carme Quer, Marco Torchiano
1:50 - 2:05 eCots Stéphane Laurière, Jean-Christophe Mielnik
2:05 - 2:20 Empirical Study on COTS Components Classification
Jingyue Li, Finn Olav Bjørnson, Reidar Conradi
2:20 - 2:35 An informal COTS Specification Model – Enabling Component Acquisition.
Benneth Christiansson, Marie-Therese Christiansson
2:35 - 2:45 Highlight main discussion points Betsy Clark, Marco Torchiano
2:45 - 3:05 Break
3:05 - 4:05 Discussion
4:30 - 4:50 Break
4:50 - 6:30 Optional session if sufficient interest
All (moderated by Betsy and Marco)
2
1
Position Paper
Maurizio Morisio Politecnico di Torino-
Italy [email protected]
Victor Basili University of Maryland-
The following issues that arise from observations of six project that used COTS at NASA/Goddard Space Flight Center (GSFC). The issue discussed here is meant and should be meant by COTS. What is COTS? COTS is an umbrella term, with several definitions and possible interpretations. All the projects we analyzed reported using products that fall under the definition of a "product where the buyer has no access to the source code; the vendor controls its development; the product has a non-trivial installed base" [Basili 2001]. Further, we did not consider products (such as compilers, CASE tools) used to produce the final deliverable, but not integrated with it. The common denominator of products falling under this definition is the set of problems to solve (the ability to integrate, the possibility of obtaining the desired functionality, dependability of the product and the vendor) and the set of new process activities required (selection, integration, vendor interaction). In other words project managers associate COTS with these problems and issues. Other definitions (including for instance items developed elsewhere in the same company, or items developed by subcontractors) identify other sets of problems, equally interesting but usually falling under other headings (such as reuse, procurement, subcontract management). Open source software (items developed elsewhere, but with access to source code) has several characteristics in common with COTS, but the availability of source code makes it a case apart. Strictly speaking, the definition includes also products such as operating systems, databases, and network protocols. The common characteristics of these COTS is that they are well known products, have been used for years, there is experience, consulting and training about them easily available, and in most cases a second source vendor or product is available. In other words, they are not likely to raise problems or the problems they raise have already been solved. Project managers do not mention these COTS because they are business as usual, and concentrate their attention on COTS that are new for their team and therefore likely to raise problems and risks. To capture these issues we propose to partition COTS in hard and easy. Hard COTS are COTS products likely to raise risks. These risks depend on several properties, both of the organization using the COTS, and of the COTS product itself. Figure 1 shows, in UML-like style, an organization (left square), a COTS product (right square), and a relationship between them that can be hard or easy. Properties of the COTS product that affect the relationship are the amount of functionality offered, the complexity of the interface, maturity and stability of the product, quality of vendor support and availability of support from other parties. Properties of the organization are its experience with COTS based development in general, and with the COTS product at hand in particular.
Organization -experience with COTS product -experience with COTS based development
COTS product -amount of functionality offered -interface complexity -maturity and stability -quality of vendor support -availability of 3rd party support
Hard vs. easy
Figure 1. An organization can have a hard or easy relationship with a COTS product.
3
The different properties have contrasting effects on the relationship. On the COTS side, the amount of functionality offered and the complexity of the interface raise the probabilities of risks. Conversely, maturity and stability of the product, good vendor support and availability of support from third parties contribute to lower the risks. On the side of the organization, experience of the staff on the product, and on COTS based development, possibly in the same application domain, is the main factor that lowers the risks. Figure 2 shows how each property has a positive or negative effect on the relationship, represented on the X axis. It shows also that hard vs. easy is not a binary decision, but a spectrum, and is difficult to assess. One end of the spectrum is that no team member has experience with the COTS product, and no experience with CBS in general, amount of functionality offered is very high, complexity of the interface is high, and so on. The other end of the spectrum is that the COTS product has been applied in the particular environment successfully and there are team members who are part of that application on the current team, there is reliable documentation about the usage of the COTS in the same problem area, and so on. However, situations in between are much harder to assess, and more experience, with more studies has to be developed. Given the same product and organization, the hard/easy property may change over time. For example, the COTS products used in one project were easy for that project, but they were hard for the project team that used them the first time, some years ago. So, probably all COTS are initially hard, then a learning process at the level of a team or organization makes (some or all of them) COTS easy. Some COTS (for example operating systems, databases, ) are easy for the majority of the organizations, because they are around since a long time and organizations have learnt to use them over several projects. Going back to our initial goal (partitioning COTS in hard and easy ones) we can say that easy COTS are COTS easy for the majority of organizations. Easy COTS products mirror both the maturity of the vendor and of the software community. In principle, all other COTS are hard ones. Organizations and project managers are interested in techniques and tools to assist them with hard COTS. [Basili 2001] Basili V.R., Boehm B., COTS-Based Systems Top 10 List, IEEE Computer, May 2001, pp.
91-93.
Hard Easy
Amount of functionality offered Interface complexity Experience with COTS product Experience with CBD Maturity and stability Quality of vendor support Availability of 3rd party support
Figure 2. Effect of properties on the relationship.
4
Building Sound COTS Products Taxonomies Juan P. Carvallo1, Xavier Franch1, Carme Quer1, Marco Torchiano2
1 Universitat Politècnica de Catalunya UPC-Campus Nord (C6)
08034 Barcelona, Catalunya, Spain {carvallo, franch, cquer}@lsi.upc.es
http://www.lsi.upc.es/~gessi
2 Politecnico di Torino C.so Duca degli Abruzzi, 24
10129 Torino, Italy [email protected]
http://softeng.polito.it/torchiano
Introduction The acquisition of process of COTS products requires the identification of the suitable products. The evaluation of COTS products varies from type to type, e.g. a DBMS has to be evaluated differently from a web browser. The techniques used to integrate the COTS products are strongly dependent on the type of products. The same applies to the architectural patterns and style used to build COTS-based systems. So it is important to be able to classify COTS products into homogeneous classes. Taxonomies are a tool to perform such a classification.
Motivation The first question we should ask is: why building taxonomies at all? The purpose of taxonomies is to provide a classification mechanism; they allow distinguishing different categories of COTS products. It is important to provide a clear rationale and structure for the classification. This is required to make it easy both to understand and apply. The hierarchical organization of taxonomies defines clear classification rules, which provide the rationale for the classification. The result is a consistent partitioning of COTS products into classes. A basic and obvious goal of the classification of COTS products is to select the suitable products when we need to build a COTS-based system. The structure of the taxonomy drives the developers during such a selection activity. Following the branches of the taxonomy it is possible to navigate the taxonomy until the suitable class of products is found. In addition, since within a consistent taxonomy each class contains similar products, it is possible to enhance the taxonomy associating a set of features to each class. Typical examples of features that can be linked to classes are:
• a collection of typical issues for that class [4], • a toolbox of techniques and methods suitable for that class, • quality models [5][6].
The above are just examples of features that can be attached to a class of COTS products; many more features can be added.
5
Taxonomies Usually a taxonomy is represented as a tree-like hierarchical structure. We propose to implement a taxonomy, together with its hierarchical structure and classification rules, as a decision tree [2] [3]. The categories and sub-categories are represented by the nodes of the nodes of the tree, being the leaves atomic classes, not further divided. The classification rules are expressed by means of attributes. An attribute is associated to each node; for each possible value of the attribute (or for each subset of a given partition of the possible values) a new child category is introduced. The evaluation of the attributes can be carried on formulating a question to which correspond several answers (i.e. the single values or subsets of values). In addition we attach to each category a generic feature set specific for that category.
Category C1
Category C1.1
Category C1.2
Attribute A1
Feature Set FS1.1
Feature Set FS1.2
Feature Set FS1
v1.1v1.2
Fig. 2.1. The fundamental elements of a taxonomy.
The advantages of providing a decision tree based taxonomy of COTS products categories are:
• a formal and unambiguous definition of classes, • a “guided” way to identify the categories, • the capability to reuse features among categories.
The attributes define how to measure them and the possible values, the partition in sub-categories is formally defined on the basis of such attributes. Since a question can be associated with each attribute evaluation, the process of applying the classification or looking for a classified element in the taxonomy is made simple. The hierarchical structure of the taxonomy allows the definition of generic features in a category, which can be reused and refined in the sub-categories. Actually an inheritance mechanism is applied here: the feature set of a category inherits the feature set of its father that can be extended and refined. The above properties hold only in presence of a valid taxonomy. Actually it is easy to make mistakes in the definition of taxonomies. In addition we must produce compact and reasonable taxonomies. For these reasons we define the criteria for the validity of taxonomies:
• a category can be partitioned into sub-categories based on the values of an attribute, • each attribute must be measurable answering to a question, • the feature sets associated with each sub-category must differ from each other.
6
If the partition of a category into sub-categories is linked to the values of an attribute is easy to formulate a question. This gives the possibility of identifying the relevant category by a series of questions and answers. Each attribute must be associated with a question, that is easy to answer, and must provide a set of possible values. For each of the possible values there is a sub-category. If a partition of a subcategory does not enrich the feature set then it only adds “noise”: it makes the taxonomy more complex and adds a question that has no purpose. We apply the Occam’s razor and remove the categories that are not clearly useful.
Building taxonomies To build a COTS taxonomy it is possible to proceed in several different ways:
• restructure existing application taxonomies (e.g. [1]), • top-down definition from abstract principles, • bottom-up construction from actual COTS products.
Several taxonomies can be found either in the literature, on the web, or from consulting firms. Thus it is reasonable to work on them to produce a taxonomy that conforms to the criteria defined in the previous section. The key point in the definition of taxonomies is the definition of the attributes. A process to carry on this task has not been defined yet. We have to work using common sense and trying to minimize the differences from the original taxonomy. In [1] an example of such a restructuring is presented. Here we summarize briefly the main differences among the original and the resulting taxonomies.
• Identification of new scopes. This is the most usual action we have taken, due to the nature of our activity.
• Division of existing scopes. Occasionally, some original scopes were too coarse-grained mixing different concepts belonging to different attributes.
• Merge of existing scopes. The other way round, some scopes are so similar that their differentiation does not really make sense.
• Removal of existing scopes. The main reasons being: the scope is not a software domain and the scope does not really add value to the taxonomy.
Conclusions We believe that taxonomies based on decision trees constitute a simple and usable tool for classifying COTS products. In addition they allow the definition of feature sets that can be build incrementally as we go down the hierarchy. Examples of features are quality models that were defined in [1], but other can be defined. This is a primary motivation for building classification of COTS products. This motivation is less subject to change when moving from a COTS-based application to another. As a further work we see:
• the definition of wider and more reusable taxonomies, • the definition of more complete feature sets, and
7
• the definition of a process to produce valid taxonomies from existing non-formal application taxonomies.
References
1. Juan P. Carvallo, Xavier Franch, Carme Quer, Marco Torchiano. "Characterization of a Taxonomy for Business Applications and the Relationships among them" In Proceedings of Third International Conference on COTS Based Software Systems (ICCBBS), Redondo Beach (CA), February 1-4, 2004
2. J.R.Quinlan. “Learning efficient classification procedures and their application to chess endgames” in Machine Learning: An Artificial Intelligence Approach, R.S.Michalski, J.G.Carbonell, and T.M. Mitchell (Eds.), Palo Alto, Tioga Publishing Compani, 1983.
3. J.R. Quinlan. “Learning decision tree classifier” in ACM Computing Surveys 28(1), March 1996.
4. M. Morisio, M. Torchiano. "Definition and classification of COTS: a proposal". 1st International Conference on COTS-Based Software Systems (ICCBSS), LNCS 2255, Orlando (USA), 2002
5. X. Franch, J.P. Carvallo. "Using Quality Models in Software Package Selection". IEEE Software, 20(1), January/February 2003, pp. 34-41.
6. J.P. Carvallo, X. Franch, C. Quer, "Defining a Quality Model for Mail Servers". 2nd International Conference on COTS-Based Software Systems (ICCBSS), LNCS 2580, Ottawa (Canada), 2003.
8
!""#$$%&''(
")*$%*+,-!.)/)01%2.3%"2*+0),!+$%4),5$6)7
8"9:;%").*,!#<*!).%7,)7)$2/
8"9:;
)=8>=?8@
!"#$%&'%&()&(%%#*'($'#)&+#,)-!-&')&.!*!/0!1&2334&05&67(8!%9&:.;&<=.&()-&>,88?&@$%&/'%%'#)&'%&$#
*1!($!&()&#A!)&()-&*#88(0#1($'B!&#)8')!&-'1!*$#15&#+&%#+$C(1!&"D6E&A1#-,*$%&()-&A1#-,*!1%9&$#&+#%$!1
$7! &,%! &#+ & %#+$C(1! &*#/A#)!)$% &()-& $# &A1#/#$! &"D6E&-!%*1'A$'#) & $!/A8($!% &*#)$1'0,$')F & $# & $7!
-!+')'$'#) & #+ & %$()-(1-%? & >5 & A1#B'-')F & %!1B'*!% & +#1 & *#88!*$')F & ()- & %7(1')F & %$1,*$,1!- & ()- & (**,1($!
')+#1/($'#)&#)& $7! &A#1$(8 &7$$AGHHCCC?!*#$%?#1F9 &!"#$% &('/% &($ &0!')F&() &DA!)&.'1!*$#15&I1#J!*$& #+
E#+$C(1!&"#/A#)!)$%?
!"#$%&/(K!%&'$%!8+&-'++!1!)$&+1#/&%#+$C(1!&*($(8#F,!%&%,*7&(%&L)#C8!-F!E$#1/9&;1!%7M!($9&N!0
E!1B'*!%&*($(8#F,!% &05&A1#B'-')F&%$1,*$,1!-&-($(&*#)%'%$!)$ &C'$7&(&*#//#)&-!%*1'A$'#)&/#-!89 &05
*#B!1')F&(88&%#+$C(1!&*($!F#1'!%&()-&05&A1#/#$')F&#A!)&*#88(0#1($'#)&()-&')+#1/($'#)&%7(1')F&C'$7')
!"#$%&*#//,)'$5&()-&#$7!1&*($(8#F,')F&')'$'($'B!%&$71#,F7&(&%!$&#+&#A!)&*#)$!)$&8'*!)%!%?
8"9:;%49>AB>9CD;
@)&$7!&%(/!&C(5&(%F()'O($'#)%&%,*7&(%&DPE@E&$7!&Q"I9&$7!&$!*7)'*(8&C#1K&#+&!"#$%&'%&-1'B!)&05
'$%&/!/0!1%9&C7#&%,0%*1'0!&$#&C#1KF1#,A%&')-!1&$#&A(1$'*'A($!&$#&$7!&')'$'($'B!?&!"#$%&C#1KF1#,A%
(1!&-!-'*($!-&!'$7!1 & $#&%A!*'+'* & +,)*$'#)(8 &"D6E& +(/'8'!% &%,*7&(%&Q2::&PAA8'*($'#)&E!1B!1%9 &N!0
"#)$!)$ &M()(F!/!)$ &E5%$!/% & !$* & #1 & $# & F!)!1(8 & $#A'*% & %,*7 & (% & $7! &"D6E &!B(8,($'#) & A1#*!%%?
N#1KF1#,A%&$7($&(1!&0#,)-&$#&"D6E&+(/'8'!%&(1!&')&*7(1F!&#+&-1(+$')F&"D6E&-!%*1'A$'#)&$!/A8($!%?
67!%!&$!/A8($!%&(1!&*#/A#%!-&#+&$7!&/(')&+,)*$'#)(8&()-&$!*7)'*(8&*1'$!1'(&$7($&,%,(885&$(K!&A8(*!&')
$7! &%!8!*$'#) &A1#*!%% &#+ & $##8% & $7($ &(1! &*($!F#1'O!-& ') & $7! &*#11!%A#)-')F &"D6E& +(/'85? &67! &N!0
"#)$!)$&M()(F!/!)$&E5%$!/%&N#1KF1#,A&C#,8-&+#1&')%$()*!&*1!($!&(&$!/A8($!&*#)$(')')F&-!%*1'A$'#)
+'!8-% & %,*7 & (% & 6(R#)#/5 & M()(F!/!)$9 & E!(1*7 & :)F')!9 & .#*,/!)$%S & N#1K+8#C9 & T%!1%S & 1'F7$%
/()(F!/!)$9&!$*?&!"#$%&A8($+#1/&A1#B'-!%&$7!&F,'-()*!9&A1#*!%%9&()-&')+1(%$1,*$,1!&U$7!&A#1$(8&'$%!8+9
A#C!1!-&05 &Q(8'#%& "#)$!)$&M()(F!/!)$&E5%$!/V&)!*!%%(15&+#1 & $7!&C#1KF1#,A%&$#&-#&$7!&C#1K?&P
F8#%%(15&'%&0#,)-&$#&!(*7&C#1KF1#,A?&67!&/(')&!"#$%&F8#%%(15&*,11!)$85&*#)$(')%&-!+')'$'#)%&')%A'1!-
$#&(&8(1F!&!R$!)$&05&WP6D&"D6E&N#1KF1#,A&-!+')'$'#)%?
,8DE?FG:?9H
@) &(--'$'#) & $# &A,08'*85&(B('8(08! &%!1B'*!%9 &!"#$% &A1#B'-!% &%!*,1! & 1!A8'*($'#) &/!*7()'%/% &(B('8(08!
,)-!1&%,0%*1'A$'#)&()-&(88#C')F&*#/A()'!%&$#&!)7()*!&$7!&A,08'*&-!%*1'A$'#)&%*7!/(%&()-&$7!&A,08'*
"D6E & *8(%%'+'*($'#) & C'$7 & -!%*1'A$'#)% & ()- & *8(%%'+'*($'#)% &#)85 & !RA#%!- & ')$!1)(885 & C'$7') & $7!
#1F()'O($'#)?
9
3+I!.!*!).$%*62*%277/1%4!*6!.%+")*$%7/2*I),-
"D6E&-($(&#)&!"#$%&'%&-!%*1'0!-&(8#)F&+#88#C')F&*#)*!A$%G&"D6E&A1#-,*$%9&"D6E&B!1%'#)%9&"D6E
(1$'*8!% & ()- & "D6E & A1#-,*!1%? & .!+')'$'#)% & #+ & $7!%! & *#)*!A$% & (1! & 8'%$!- & 0!8#CX & $7!5 & 7(B! & $# & 0!
-'%$')F,'%7!- & +1#/ & $7! & -!%*1'A$'#) & #+ & $7!'1 & ')%$()$'($'#)%9 & A1!%!)$!- & ') & A(1(F1(A7 & Y!"#$% & "D6E
.!%*1'A$'#)&M#-!8Z?
")*$%7>9JCF:
!"#$%&+#,)-!1%&*7#%!&$#&(-#A$&(&-!+')'$'#)&$7($&*#B!1&(&C'-!&%!$&#+&%#+$C(1!&*#/A#)!)$%?&[!1!&(1!&$7!
*7(1(*$!1'%$'*%&#+&(&"D6E&I1#-,*$&C'$7')&!"#$%&A#1$(8&U')%A'1!-&05&!R'%$')F&-!+')'$'#)%VG
\'*!)%')F
P&"D6E&'%&(B('8(08!&,)-!1&#)!&%!B!1(8&8'*!)%!%&$7($&*()&0!&*8!(185&'-!)$'+'!-
U%!!&"D6E&\'*!)%!V? &67!%!&8'*!)%!%&*()&0!&#A!)&%#,1*!&8'*!)%!%?&P&"D6E
/(5&0!&(B('8(08!&,)-!1&%!B!1(8&8'*!)%!%G&+#1&')%$()*!&M5E]\&B!1%'#)%&*()&0!
,%!-&!'$7!1&')&$7!&$!1/%&#+&$7!&^I\&')&$7!&$!1/%&#+&(&M5E]\&P>&8'*!)%!?&
I(*K(F')F"D6E & *() & 0! & A(*K(F!- &(% & 8')K(08! & 8'01(1'!% & #1 & (% & %$()-_(8#)! & !R!*,$(08!
(AA8'*($'#)%&(%&1!/#$!85&7#%$!-&(AA8'*($'#)%&(%&N!0&E!1B'*!%?
`!1%'#)')FP&"D6E&7(%&($&8!(%$&#)!&B!1%'#)&$7($&/(5&/(5&)#$&0!&%$'88&%,AA#1$!-&05&()5
"D6E&A1#-,*!1?
I1#-,*!1 P&"D6E&7(%&()&'-!)$'+'(08!&A1#-,*!1&U%!!&"D6E&I1#-,*!1V?
I1'*')F"D6E&*()&7(B!&()5&$5A!&#+&A1'*')F?&"D6E&*()&0!&+1!!&#+&*7(1F!9&%,*7&(%&$7!
@.:&:*8'A%!?
"#/A#%'$'#)P&"D6E&*()&0!&*#/A#%!-&#+&#$7!1&"D6E?&;#1&')%$()*!&DA!)&D++'*!&'%&(&"D6E
$7($&'%&*#/A#%!-&#+&DA!)&"(8*9&DA!)&.1(C9&!$*?
")*$%K8>;?9H
P&"D6E&`!1%'#)&7(%&(&)(/!9&(&1!8!(%!&-($!9&()&!R!*,$'#)&!)B'1#)/!)$&()-&(&8'*!)%')F&A#8'*5?
")*$%2>:?FE8
67!&)#$'#)&#+&"D6E&P1$'*8!&/(K!%&%!)%!&#)85&')&$7!&*(%!&#+&A(*K(F!-&(AA8'*($'#)%&8'01(1'!%?&;#1
%,*7&"D6E9&()&(1$'*8!&'%&(&YA75%'*(8Z&1!A1!%!)$($'#)&#+&(&"D6E&`!1%'#)?&P)&(1$'*8!&'%&(&%!$&#+&+'8!%&$7($
*()&0!&'-!)$'+'!-&05&(&%'F)($,1!&%,*7&(%&()&M.a&*7!*K&%,/?
")*$%7>9JCF8>
P&"D6E&A1#-,*!1&*()&0!&
! P&8!F(8&!)$'$5&%,*7&(%&(&*#/A()59&(&*#)%#1$',/9&()&(%%#*'($'#)9&(&,)'B!1%'$59&(&1!%!(1*7&F1#,A9
!$*?
! P)&')+#1/(8&*#//,)'$5&#+&A!#A8!?
P&A1#-,*!1&'%&'-!)$'+'!-&05&(&)(/!9&()&T<\&()-&()&!/('8&(--1!%%?
")*$%/?F8H;8
P&"D6E&8'*!)%!&'%&(&8!F(8&$!R$&$7($&'%&!'$7!1&A,08'*85&(B('8(08!&#)&$7!&@)$!1)!$&$7($&*()&0!�$(')!-&#)
-!/()-&$#&()&!-'$#1?&<!F(1-')F&$7!&"D6E&'$&1!8($!%&$#9&(&"D6E&8'*!)%!&/,%$&-!+')!&$7!&@)$!88!*$,(8
I1#A!1$5&1'F7$%9&$7!&*#)-'$'#)%&#+&,%!9&$7!&*#)-'$'#)%&#+&*#A59&$7!&*#)-'$'#)%&#+&1!-'%$1'0,$'#)9&$7!&%#,1*!
*#-!&/#-'+'*($'#)&*#)-'$'#)%?
10
$9L:@G>8%"9MD9H8H:
P&%#+$C(1!&*#/A#)!)$&/($*7!%&(&C'-!1&%A!*$1,/&$7()&$7!&$!1/&"D6E?&P&%#+$C(1!&*#/A#)!)$&*()&0!
()5&A'!*!&#+&%#+$C(1!&%,*7&(%&(&%!$&#+&Q(B(&*8(%%!%9&(&%!$&#+&.\\%9&!$*?&"D6E&(1!&7'F7_8!B!8&%#+$C(1!
*#/A#)!)$%?
+")*$%")*$%3+$",!7*!).%-)3+/
!"#$%&A8($+#1/&'/A8!/!)$%&(&/#-!8&-!%*1'0')F&')%$()*!%&#+&"D6E&I1#-,*$%9&"D6E&`!1%'#)%9&"D6E
P1$'*8!%&()-&"D6E&I1#-,*!1%? &67'% &/#-!8& '%&%,//(1'O!-&05&$7!&%*7!/(&0!8#C?&:(*7�J!*$& $5A!
A1!%!)$&')&$7'%&/#-!8&$5A'*(885&*#)$(')%&0!$C!!)&$C!)$5&()-&(&7,)-1!-&#+&*7(1(*$!1'%$'*%?
!"#$%&'!%()*+$*#,&-#'!.&#/!)/*!0&1"234&5)$*(.!&(.6%%&*%&,#$&)!+)!%!,$!'7
67'%&/#-!8&'%&$#&0!&(B('8(08!&#)&$7!&A#1$(8&(%&(&%!$&#+&bM\&%*7!/(%?
")*$%"/2$$!I!"2*!).%).%+")*$
67!&*8(%%'+'*($'#)&#+&"D6E&+(/'8'!%&#)&!"#$%&A#1$(8&C(%&')%A'1!-&05&A1'B($!&*8(%%'+'*($'#)%&#+&67(8!%
()-&:.;&()-&05&%!B!1(8 &*8(%%'+'*($'#)% &(B('8(08!&#)& +#88#C')F&%'$!%G &L)#C8!-F!E$#1/9 &;1!%7/!($9
^##F8!&c&.'1!*$#15&c&E#+$C(1!9&[(88E#+$C(1!%9&^(1$)!1&^1#,A&A#1$(8?
;'1%$ & 8!B!8&*($!F#1'!%&#)&!"#$%&(1!G&"#/A,$!1 &P'-!-&E#+$C(1!&:)F')!!1')F9&.($(&M()(F!/!)$9&:_
\!(1)')F9&[,/()&M(*7')!&@)$!1+(*!9&@)-,%$1'(8&PAA8'*($'#)%9&@)$!1)!$9&M'--8!C(1!9&M,8$'/!-'(9&D++'*!&H
>,%')!%%9&DA!1($')F&E5%$!/%9&:/0!--!-&H&<!(8_6'/!9&E*'!)$'+'*&H&:)F')!!1')F9&E5%$!/&P-/')'%$1($'#)?
")*$%3+$",!7*!).%4),50,)<7
67!&"D6E&.!%*1'A$'#)&N#1KF1#,A&C(%&*1!($!-&#)&!"#$%&A#1$(8&')&.!*!/0!1&2334?&@$%&F#(8%&(1!&
! $#&F($7!1&-#*,/!)$%&#+&1!+!1!)*!9&*#)+!1!)*!%9&A#1$(8%&*#B!1')F&$7!&$#A'*%&#+&"D6E&-!+')'$'#)9
*8(%%'+'*($'#)&()-&-!%*1'A$'#)9
11
! $#&A1#B'-!&$7!&"D6E&1!%!(1*7!1%&*#//,)'$5&C'$7&F1#,AC(1!&$##8%&+(*'8'$($')F&$7!&A1#*!%%&#+
1!(*7')F&(&*#)%!)%,%9&
! $#&+#%$!1&*#//,)'*($'#)&#)&$7!%!&%,0J!*$%&$71#,F7&+#1,/%&()-&/('8')F_8'%$%?
"234&8!9*,*$*#,&6,'&".6%%*9*(6$*#,&:#);<)#=+&+6<!&%()!!,%>#$
D)&1!d,!%$9&(&-!/#)%$1($'#)&%7#C')F&7#C&$#&$(K!&A(1$&')&$7!&C#1KF1#,A&*()&0!&-#)!&+#1&$7!&+#88#C_,A#+&$7!&C#1K%7#A?
$<--2,1
67'%&*#)$1'0,$'#)&$#&$7!&C#1K%7#A&/(')85&*#)%'%$%&')G
! "#)$1'0,$')F&$#&$7!&!8(0#1($'#)&#+&(&*#//#)&F8#%%(15&$71#,F7&$7!&(B('8(08!&!"#$%&F8#%%(15
! "#)$1'0,$')F&$#&$7!&!/!1F!)*!&#+&(&*#//#)&-!%*1'A$'#)&/#-!8&+#1&"D6E&I1#-,*$%9&"D6E
`!1%'#)%&()-&"D6E&I1#-,*!1%
! "#)$1'0,$')F&$#&$7!&(-#A$'#)&#+&#)!&%!B!1(8&%$()-(1-&*8(%%'+'*($'#)%&+#1&"D6E
! I1#A#%')F & $# & $7! &C#1K%7#AS% & A(1$'*'A()$% & $# & %7(1! & $7!'1 & '-!(% & ()- & A1#A#%'$'#)% & ') & (
-!-'*($!-&C#1KF1#,A&(1!(&#)&!"#$%&A#1$(8?
12
Empirical Study on COTS Components Classification
Jingyue Li, Finn Olav Bjørnson, Reidar Conradi Department of Computer and Information Science,
Norwegian University of Science and Technology, Trondheim, No-7491, Norway {jingyue, bjornson, conradi}@idi.ntnu.no
Abstract
COTS-based development is gaining more and more attention. Effective COTS component classification will help integrators to successfully control the development process, such as selection and integration. In this paper, we present an empirical study to investigate the characterized classification proposed by previous research. From the result of this study, we conclude that some attributes are not good because they are either not measurable or unnecessary. We also propose one other attribute that will affect the development process dramatically. Our future study will focus on investigating these attributes in a larger sample. 1. Introduction
Commercial-off-the-shelf (COTS) components are now widely used in software development. Unfortunately, the lack of a standardized and well-defined COTS classification scheme, results in many organizations making large investments in COTS components selection and evaluation. Furthermore, unsuccessful selection leads to many difficulties and risks in integration and future system maintenance and evolution.
Previous studies have proposed several attributes to classify COTS products. The values of these attributes are supposed to impact on development process of the delivered system [1][3]. To investigate how the development process is affected by COTS classification attributes, we have designed a structured survey to test some of these attributes. The survey is still not completed. So far, we have personally interviewed team members from five different projects in Norway. From the initial survey results, we have some preliminary insight on the validity and necessity of COTS classification attributes. We found that size and type of functionality are not good classification attributes because they are either hard to measure accurately by the integrator (i.e. COTS user) or they have no actual effect on the development process. Our result also found that the difference between developers’ experience on COTS dramatically affects the future development process, such as selection, integration and maintenance. For other classification attributes, our
initial study still cannot give conclusion on them. More data will be gathered to test them in the future. The rest of this paper is organized as follows: In section 2 we give our definition of COTS components, in section 3, we describe the design and result of this study. Conclusion and future work are discussed in Section 4. 2. COTS components definition In this study, we define a component as “A separable piece of software in the form of program code (source or executable), that will be integrated into a software system (consisting of components plus application), excluding platform software (commodities like OS, DBMS etc.).” The COTS component is defined as “A component that is not developed inside the same organization, excluding platforms and commodities like OS, DBMS etc. It is either provided by some other organization in the same company, or provided by external companies as a commercial product. It is evolved by the provider, and used by the customers without source code modification.”
3. Research design and result
From a literature review, we extracted several hypotheses related to COTS-based development. The purpose of our study is to test these hypotheses by data from real projects in IT companies. Some of the hypotheses are designed to test the relationship between the COTS classification attributes and the development process. This survey design includes two phases of pre-testing. After these pre-tests, the questionnaire will be distributed to more than 100 companies to obtain statistically significant conclusion on our hypotheses. The purpose of the first phase pre-test is twofold. First, we want to test the reliability and validity of each question. Second, we want to know whether some hypotheses based on the classifications come from literature are valid or not. We did five personal interviews in five projects in the first phase pre-test. Based on the result of this pre-test, some classifications were deleted and some classifications were clarified. The revised questionnaire is on the way of
13
the second pre-test. In this paper, we will discuss only the result of the first phase pre-test. 3.1. Background Many researchers have proposed their classification on COTS component. Morisio et al. summarized some of the previous work and gave a proposal on how to classify COTS [1]. These classification attributes are supposed to be linked with software process (e.g. cost models, selection methods, architectures, testing and validation techniques etc.). The classification attributes come from previous literature. There is still no empirical study to evaluate them. Basili et al. proposed to classify the COTS products as hard and easy from their empirical study. Hard COTS are COTS products likely to raise risks. These risks depend on several properties, both of the organization using the COTS and of the COTS product itself [3]. They also proposed that the staffs’ experience on the product and on COTS based development is the main factor that lowers the risks. Several hypotheses were proposed based on this theory. Torchiano et al. also proposed some COTS classification attributes [2]. These attributes came from students in one course in a university. There is still no future evaluation in IT companies. 3.2. Research methods In the questionnaire for this survey, we classified COTS components used in projects based on some attributes. We also asked for details of several sub-processes, such as selection, integration, and maintenance for each COTS component. We then investigated whether there were relationship between the classification attributes and those sub-processes. The attributes proposed by Morisio et al. are grouped into four categories [1]: ¶ Source: where the produce comes from ¶ Customization: how much the product can or
should be customized ¶ Bundle: in what form the component is delivered,
both to the integrator and to the customer of the system
¶ Role: what is the intrinsic role the product can assume in the final system
The attributes in these categories are summarized in the following table: Category Attributes
Origin Source Cost & property Required modification Customization Possible modification
Interface Packaging Delivered
Bundle
Size Functionality type Role Architectural level
In our survey, we selected some attributes in the above categories. ¶ In the source categories, we selected the origin
attribute. ¶ In the customization categories, we selected the
possible modification attribute. ¶ In the bundle category, we selected the size
attribute. ¶ In the role category, we selected the
functionality type attribute and architectural level attribute.
We listed several alternatives for each selected attribute. The definitions of alternatives are as follows: Origin: ¶ By contract: The COTS was acquired by asking
a component vendor to create a component for an agreed-upon fee.
¶ From market: The COTS was bought from the market, where the vendor is selling a product to the world and has no knowledge of the individual purchaser’s requirements or constraints.
Possible modification: ¶ By Plug: Just integrate in the COTS components
to assemble an executable system without any extra work.
¶ By Configuration: Setting or defining shell parameters or macro options available for a COTS component.
¶ By Glueware: Integrate COTS mostly by using in-house built code around COTS components to solve possible mismatch between components, or between components and application/platform.
¶ By Addware: Integrate COTS mostly by using in-house built code around COTS components to add the functionalities which are required but not provided by the components.
¶ By Source Modification: Change the source code of COTS so that it can be integrated.
Functionality type: ¶ General: The functionality is not specific to a
domain, but can be used many different domains e.g. GUI functionality, Web browser functionality, etc.
14
¶ Specific: The functionality is specific to a domain and can be reused only in the domain e.g. financial functionality, telecommunication functionality, etc.
Architectural level: ¶ Core: The COTS components provided the main
functionality of the system. The system was built around these COTS components.
¶ Support: The COTS components provided some functionality to support the central application of the system.
Size: Morisio et al. proposed a classification scale of COTS size, i.e. small means less than 0.5 MB, medium means 0.5MB to 2MB, large means from 2MB to 20MB, and huge means more than 20MB. Because it is better to get the exact number of the value of interval variable and then define a classification scale afterwards, we used the open answers to let respondents to fill in the exact size of the components as following: COTS : _____ KB or ____ (KLOC) In the questionnaire, we also have questions to ask the respondents’ experience on components in order to study whether their previous experience on COTS component have effect on the future development process. The questionnaire was sent to the respondent one or two days before the personal structural interview. To gather comments on each question, we added three extra evaluation questions behind every question. These three questions are:
1. Is this question easy to read as worded? 2. Do you need classification for this question? 3. If you have comments on this question, please
fill in the lines. In the process of the personal interview, the interviewer went through the questionnaire together with the respondent to gather feedback of questions in case there was something needs to be clarified. The interviewer also gathered answers of questions, which were clear enough. 3.3. Result The output of the pre-test can be divided into two parts. First, we evaluated the classification attributes proposed to see whether they are measurable and necessary. Measurable means that the attributes can be quantified and measured. Necessary means that the value of the COTS components in these attributes will affect future COTS-based development process, such as selection, integration, maintenance, and evolution.
From the result of the pre-test of the questionnaire, we found two attributes that were not good classification attributes. ¶ Size: We do not believe size is a good attribute
to classify COTS components because it is not measurable or necessary. First, most COTS components are compiled binary code, the only number that can be calculated is how much space the COTS component takes up in the form of KB on a file. However, compiler differences make it very hard to calculate the lines of source code or use cases from components’ physical size in KB. So, the conclusion is that you can get an estimate size but it cannot tell you anything. Therefore, we define it as non-measurable. Second, most respondent do not care about the size of COTS components. When asked this question, almost everyone needs to re-check the system and calculate the size by KB. Morisio et al. supposed the size will affect the learnability [1]. But respondents said they used only part of the functionalities provided by COTS and believed that size could not affects the development process. So, we believe that this attribute is also not necessary.
¶ Functionality type: We do not believe
functionality type is a good attribute to classify COTS components because it is hard to measure by the component user and it will not affect the development process, and is therefore unnecessary. For example, one respondent said they selected a general component from market, but they had to ask the vendor to change the source code to meet the requirement of their specific domain, which changed it into a specific component. So, he didn’t know how to define the functionality type from his viewpoint. Morisio et al. supposed the functionality will affect the reusability across projects [1]. The assumption is that specific type components may have better reusability across projects. However, one respondent argued that general type components could also have good reusability across projects if the requirements of both projects are general, for example, PDF file generation. They also said that they searched the components only by the required functionalities not by the required domain. We investigated websites of several main component brokers, such as ComponentSource, Component Vendor Consortium, Xtras.net, VBxtras. We found that none of them classified components based on their usage domain. The possible reason is that
15
the functionality type of most components in the market is horizontal, i.e. the functionality is not specific to a domain. As a result, we regarded this attribute is also not necessary either.
Another output of our pre-test was the identification of a new classification attribute that affected the component users’ decision in the component selection process. The attribute is the component users’ or colleagues’ experience with the components. From the survey result we found that component users prefer to select components they have experience with, the experience coming either from themselves or from colleagues. If they had the experience, the component selection procedure would become very short, because they would not use time to search and evaluate the component again. In our survey, four respondents had previous experience with the component they used, so they selected the component mainly on their previous experience. If they did not have experience, they would need more time and effort to search and evaluate the components. One respondent of our survey had no experience with the components he used in the new project. Although he used much effort in searching and evaluating the component, he still thought more effort should be used in the component selection phase because he found many problems after the component had been decided. From the interview, we found it is hard to measure the experience of each person. However, some respondents proposed to define the scale of experience on the experience of the whole project. So, our scale for this new attribute is: ¶ Very much experience: Roughly more than ¾
project members have used this component in previous project
¶ Much experience: Roughly ½ project members have used this component in previous projects
¶ Some experience: Roughly ¼ project members have used this component in previous projects
¶ Little experience: Roughly less than ¼ project members have used this component in previous projects
¶ No experience: No project members have used the same components before.
4. Conclusion and future work
The contribution of this paper includes two parts. First we did literature study on proposed classification attributes. These attributes are proposed as internal COTS components classification attributes, because they are supposed to impact development process. We evaluated whether the attributes could be quantitatively measured. Then we measured whether the value of the classification attributes could affect the development process. We discovered that attributes like functionality type and size are either not measurable or not necessary. The second contribution is that we proposed developers’ experience on COTS components as a new classification attribute that is measurable and necessary. Based on the above result, the questions about size and functionality type attribute of COTS components were deleted in our revised questionnaire. The question about developers’ experience on COTS components was revised and relating scales were added. We did not find systems using COTS components as the core part of the system or COTS components acquired by contract so far. We could not give any conclusion on the origin and architecture attributes. The small sample could also not support any conclusions on the possible modification attribute. Our future study will investigate these attributes based on a bigger sample. 5. References [1] Maurizio Morisio, and Marco Torchiano, “Definition and Classification of COTS: a Proposal”, in proceedings of ICCBSS 2002, LNCS 2255, pp. 165-175. [2] Macro Torchiano, and Letizia Jaccheri, “Assessment of Reusable COTS attributes”, in proceedings of ICCBSS 2003, LNCS2580, pp. 219-228. [3] Victor R. Basili, “Evolving Knowledge about COTS-Opening Keynote”, ICCBSS 2003, available at http://www.iccbss.org/2003/abstracts.html
16
An informal COTS Specification Model –
Enabling Component Acquisition.
Benneth Christiansson and Marie-Therese Christiansson Information Technology Department
Karlstad University Sweden
Introduction In today’s global market, the need for well functioning and robust information systems is greater than ever. Organizations also have to continuously adjust and improve their business practices to maintain a competitive edge at the same rate the information systems have to be adapted in accordance with these changes. This is a big challenge for the software development community, and has been a big issue in the software engineering field for at least two decades. The challenge is to increase the productivity of software system development and to augment the flexibility of software systems to react to business process changes. One approach to achieve this is taking clues from traditional production techniques. Software systems should be constructed from prefabricated, easily identifiable software components (Szyperski, 2002, Christiansson, 2001) that can be widely used. To develop software systems with a component-based approach is one of the newer trends within the software development community. However for component-based software development to be successful in organizations, the software developers must give close attention to the design of components as independent abstractions with well-specified behaviors. Without well-specified behaviors the possibility to distribute and acquire software components will be limited. Langefors (1995, p. 142) describes the development of software systems as finding the solutions to: ”Two fundamental problems with information systems were pinpointed at the outset: (1) The "infological” problem of how to define the information to be made available to the information system user, and how to design data that may represent the information to the user; and (2) The ”datalogical” problem of how to organize the set of data and the hardware so as to implement the information system.”. We take our point of departure in this description. We believe that emphasis during software development needs to be on both these problem areas also regarding component-based software development or even more so regarding component-based development. We believe this is accurate due to two facts firstly software component development should be focused on assembly rather than about construction. This means that we do not have to focus on how the actual development is done; the software component is an existing artifact. Secondly software component development is about acquisition, we need to be able to identify which components we need when assembling systems; this conveys the need for a specification of the components behavior (Szyperski, 2002, Heineman & Councill, 2001). This acquisition we believe needs to be based on an ‘infological’ specification as well as a “datalogical” one, using Langefors (1995) terms. In this paper we describe an informal “infological” model to specify software components used by the largest software component distributor Componentsource (2003). We argue for the need of an informal approach for addressing the ‘infological’ problem of software development that enables acquisition rather than construction. We have previously shown (Christiansson & Christiansson, 2003) that such approaches are missing in the research community. In this paper we focus on an existing solution created in practice. We believe an optimal approach probably can be found somewhere in the middle between “unreflected” practitioners problem solving ad-hoc solutions and “reflected” theorists “unused” efforts. We have chosen to describe our research effort as: “The meeting between business processes and software components – in a well founded specification.” Our approach is focused mainly towards the process of capturing software requirements, and the creation of a specification model that can be used as a tool in the acquisition phase of component-based systems development. Approaches towards the assembly phase already exist and is a major area of research in the component-based software engineering community (Christiansson & Christiansson, 2003). Our approach for specifying software components is based on the integration of results from two research fields; 1) Component Based Software Engineering and 2) Business Process Modelling. We believe it to be possible to integrate 1) business process models; 2) the capturing of software requirements in an informal manner and; 3) software component specifications into one type of document. This document can be used as a tool for software component acquisition. Acquisition and assembly is based on the knowledge of what is needed to acquire and assemble and also on what is possible to acquire. Vigder et al. (1996, p. 13) claims that ”… in order to realize the benefits of COTS software a procurement process must be in place that defines requirements according to what is available in the marketplace, and that is flexible enough to accept COTS solutions when they are proposed.”. What is needed is an approach to specify requirements on software components to identify actual needs. To be able to capture requirements based on the desired business processes expressed by people
17
who run and perform business practise. This is not the reality of today Beck (2000, p. 3) illustrates this as “Business misunderstood – the software is put into production, but it doesn’t solve the business problem that was originally posed. Business changes – the software is put into production, but the business problem it was designed to solve was replaced six months ago by another, more pressing, business problem.” We believe requirements should be captured close to the business practice to cope with the problem of missing and/or inaccurate requirements as well as constant business change, see figure 1. The figure illustrates the connection between business practice and software system as being software components. A software component’s “infological” part exists in the business practice and the “datalogical” part exists in the software system. The figure also shows our approach as a part of the components “infological” side.
Specification
Implementation
Binary
Component
”Infological”
”Datalogical”
Business practise
Software system
Business processmodel
Figure 1. Our approach to a well founded component specification (Christiansson & Christiansson, 2003).
Componentsource Component Specification Model We have chosen to study one of the largest marketplaces for COTS acquisition Componentsource (2003) this is an on-line marketplace for component acquisition. Componentsource was founded in 1995 under the parole “Making Reuse a Reality”. And according to their own information (Componentsourcee, 2003) the “Marketplace of choice for technical decision makers everywhere - home to the world's largest source of software components for all platforms ( 9,000 components and expanding)”. In our experience component acquisition is oftentimes hindered due to lack of tools to aid identification of components. There are no standard strategies for identifying components, or any standard language for expressing requirements on components. ”A standard approach to building and using components must be set and universally practiced if the software engineering community is to reap the benefits…of reusable software components…” (Vaughn, 1990, p. 1). Since Vaughn expressed this need things have happened, but mainly regarding the building part or in Langefors (1993) terms the “datalogical” side. Regarding component usage there are still no clear standards and we have in another study (Christiansson & Christiansson, 2003) shown that this is a low priority area in the component engineering research community. Componentsource however have a big clientele and offers over 9000 components in their repository. This indicates the need for a structured way of presenting these components and it also indicates that they developed successful tools to aid customers and vendors in enabling component acquisition. By studying their offer procedure we have reconstructed their component specification model. To identify the underlying generic structure used at Componentsource we have identified the “find a component” process and documented it. The next step is to analyze the information presented and needed throughout the process and by describing it we have described the Componentsource Component Specification Model.
Find a component process The “find a component” process starts out with a free-text search based on keywords that describe the components functionality on a very high abstraction level (figure 2). These keywords are not regulated in any way. The only directions suggested is that the keywords used for component identification can be product name or description of the service the component provides e.g. the keywords “credit card verification” implies a search for components from any vendor with any name that performs a credit card verification service. After these initial informal search criteria filtering of the repository the result can be refined by applying different additional filters. These filters are based on platform decisions e.g. .NET, DLL, ActiveX/COM etc. The possibility to choose which platform implementation that is desired is available. The amount of components to choose from is
18
now narrowed to be vendor-specific. The next step is to choose one specific component and filter it based on editions and versions of releases. At this last stage of the “find” process the component is presented with the following information to enable decision regarding acquisition:
• a list of features presented in natural language in an informal manner called overview • pricing and licensing information regarding actual costs and legal details regarding usage and
responsibilities • evaluations and downloads if an evaluation version of the component exists it can be downloaded from
here • compatibility information regarding possible operating systems, architecture of product, component
type (eg. COM, javabeans, ActiveX etc.), creation tools (e.g. Visual Basic, C++, Java, etc.), glue-code compatibility, product class (the vendors classification of the component e.g. Business component, SQL component etc.), test and review status and prerequisites for component usage
• publisher details containing information about the vendor • customer reviews if available • support forum if available
Procurer Componentsourcestart
Component needKeywordsdescribingcomponent
Matchingcomponents
EndComponent Identified
Platformrequriement
Matchingcomponents
Versions &editions ofcomponent
Version/Edition
requirement
Overview anddetails
Requiredcomponentdescription
Itera
te if
com
pone
nt d
oes
not m
atch
nee
d
Figure 2. The Find a component process.
The content of the component specification model The component specification content at Componentsource consists of different parts, these parts handle different aspects of a components specification and are also presented at different levels of abstraction and with different levels of informality. The most important part of the specification is however the initial keywords used as search criteria in the Componentsource repository. These keywords are the only part of the specification used for identification of possible component candidates. The rest of the specification is only used to delimit this initial quantity of component candidates until only one component is left. This component is hopefully what the procurer was looking for. If the procurer fails with identifying a component matching the needs, the procurer can try to identify new candidates (se figure 2) and iterate the process by using new keywords. During the search of the repository Componentsource uses a free-text approach scanning through the documents specifying components supplied by the component supplier. The degree of success for procurers in finding components is thereby based on their ability to choose “correct” keywords and the supplier’s ability to use “correct” keywords when supplying information about components to Componentsource. This indicates the need of support when specifying components on a very high level of abstraction in an informal way. The next section of a component
19
specification covers pricing and licensing. This information is provided to enable investment decisions. It is difficult to decide the importance of this part of the specification but of course the component needs to be price worthy to the procurer. Componentsource also provides evaluations and download possibilities before the final acquisition. This download enables the potential procurer to try the features in the actual environment the component is supposed to exist in after acquisition. The specification also contains compatibility information regarding operating systems, used architecture for component construction, information about the tools used to construct the component and product class. Product class is a classification scheme used throughout Componentsource to classify components. It consists of 106 different categories. The next part of the specification contains details regarding the component supplier. This information contains a brief description of the vendors business, other components, contact information etc. Componentsource have also chosen to include a section with customer reviews in the specification. In this section component-users can express their experiences and comments about the component. The last section of the specification contains a support forum. This part can consist of frequently asked questions, sample code, usage examples etc. In table 1 we summarize the specification model used at Componentsource. Table 1 Short summary of component specification Section of specification Containing Overview Overview containing of a short definition of key
functionality Pricing and licensing Price and license information Evals. and downloads Possible downloads of evaluation versions Compatibility Restrictions regarding component usage Publisher details Information about supplier Customer reviews Gathered experience Support forum Information to ease usage
Conclusions and summary Componentsource is one of the largest component distributors. This indicates a successful strategy in aiding procurer in their acquisition process. By reconstructing this process we have described the component specification model that is implied in this support of the acquisition process. The specification model is based on an informal keyword identification process based on the procurer and suppliers ability to express functionality in similar terms. The specification model does not aid the actors in this crucial task and still the process works. The only support in this initial identification process is the product class classification scheme provided by Componentsource. The rest of the component specification contains different details and aspects of the component to aid the procurer in the decision making. It does not aid in the actual identification of component. We believe that the support in the identification process can be enhanced and better supported to make this process more accurate and precise and not so much depending on the actors experience and implicit knowledge.
References Beck K. (2000) Extreme Programming Explained. Addison Wesley Longman, Inc., California, Menlo Park, USA
Christiansson, B. (2001) ”Component-Based Systems development” In: Nilsson A.G. & Pettersson, J.S. (eds.).On Methods for Systems Development in Professional Organisations, Studenlitteratur, Lund.
Christiansson, B. & Christiansson, M-T. (2003) The Missing Approach for Component Specification, In: Assar, S., Semmak, F. & Barkhi, R. (eds.)Proceedings of 1:st International Workshop on Component-Based Business Information Systems Engineering (CBBISE'03), September 2003, Geneva
Componentsource (2003) www.componentsource.com (2003-11-05)
Heineman G. T. & Councill W. T. (2001) Component-Based Software Engineering Putting the Pieces Together. Addison Wesley Longman, Inc., California, Menlo Park, USA
Langefors B. (1995) Essays on Infology – Summing up and Planning for the Future. Studentlitteratur, Lund.
Szyperski C. (2002) Component Software Beyond Object-Oriented Programming. Addison Wesley Longman, Inc., California, Menlo Park, USA
Vaughn T. (1990) Issues in Standards for Reusable Software Components. http://ruff.cs.umbc.edu. 2000-12-16
Vigder M. R, Gentleman W. M. & Dean J. (1996). COTS Software Integration: State of the art. National Research Council of Canada., Toronto, Canada.
20