DEVELOPING AN E-COMMERCE SOLUTION ARCHITECTURE BY A COTS-BASED REUSE APPROACH Lamia Labed Jilani
Sihem Ben Sassi
Yenes Nacim
[email protected] [email protected] [email protected]
Henda Ben Ghezala
[email protected]
Laboratoire Riadi-Gdl, Ecole Nationale des Sciences de l’Informatique
ABSTRACT - In this paper, we deal with the design and implementation of an e-commerce web site architecture by using a reuse development approach where the architecture of an e-commerce solution is reused with its different components without developing them from scratch. In fact, this architecture is the same for all the commerce web sites and adopting the traditional development life cycle becomes more costly then reusing existing components of the architecture. We deal specifically with a COTS based development approach where COTS components mean Commercial Off The Shelf. Our contribution consists in proposing a process which will guide the developer in his/her choice of the best COTS components for its application of e-commerce, guidelines about which methods to use for selecting and integrating these components. KEY WORDS : e-commerce, merchant web sites, reuse software engineering, COTS-based development.
1. INTRODUCTION Nowadays, Internet becomes one of the several distribution channels for commerce and trade. Many enterprises are using Internet as one mean of promoting and purchasing their products and/or services and rendering more visible their organizations. Others, have just an ecommerce web site for their commerce and all their transactions are on line (many strat-up enterprises became very famous and made a good sales turnover by this only mean as the very known Amazon website). On the other hand, there are still several organisations which have to implement an e-commerce solution and take advantage of Internet specifically in this area of the market mondialization. In this paper, we deal with the design and implementation of an e-commerce web site by using a reuse development approach. In fact, when analyzing an e-commerce web site specification, reuse seems a very natural approach because the basic solution is the same for any enterprise. In fact, we deal with a catalogue of products, the concept of a caddy, orders, purchasing conditions, transport fees, delivery conditions and secure payment. So, a developer doesn’t have to develop a solution from scratch and try instead to use a reuse approach of existing solutions. The remainder of the paper is structured as follows: section two presents different reuse approaches for commerce web sites developments. Section three elicits a meta model for COTS based development that we use as a reuse development approach. Section four shows the instantiation of the COTS meta model for an electronic commerce solution. And finally, the paper ends with a conclusion and future work in section five.
1
2. REUSE APPROACHES FOR COMMERCE WEB SITE ARCHITECTURE DEVELOPMENT
Many software editors and vendors (commerce server of Microsoft 1 , PEEL2 , AMEN ecommerce solution3 , etc.) sell packages for e-commerce solutions that give the basic skeleton of an e-commerce web site with both the client side and the server side. Buying such packages and then alimenting them with specific products or services of a given enterprise is a solution with the help of the fact that the organization has the good staff for the configuration, alimentation and maintenance of the commerce web site. Here, we are in the context of reuse specifically by using what is called application generators. All we have to do is buying this kind of generators and accept the conditions of using them such as their prices, their licences, etc. Some vendors propose their own services for building and maintaining an e-commerce solution for a given enterprise. In this context, we can consider that we are in the case of buying a COTS component which is a whole system that we buy and accept the condition of maintenance by a third party. Another solution which can interest experienced developers who want to develop their own ecommerce solution (not using an application generator, nor given the job to another company) consists in reusing several COTS components and integrate them into a whole application of e-commerce. So, all the developer job becomes a problem of components integration and not a problem of developing all the components application from scratch as in traditional development. We detail in our paper the process that will be used in such solution. 3. A METAMODEL FOR COTS BASED DEVELOPMENT Commercial Off-The-Shelf (COTS) products are components developed by tierce party, sold leased or licensed to the general public, supported and evolved by the vendor who retains the intellectual property rights, used without source code modification (black box), and available in multiple identical copies [10]. COTS-based development (CBD) consists in reusing this special type of components to build new applications and systems. Thanks to the facts that developing using COTS components is easier than developing from scratch and updating is easier than maintaining. The promised and expected benefits of CBD are multiple. They include [9]: (1) reduction of time-to-market, (2) money saving and (3) stakeholder profits related to costs, quality and used technologies due to competition between vendors. These profits make any organization attracted by a COTS-based solution. These organizations have to follow a different process than the traditional development one. A typical process of COTS use in the development of new applications includes five main steps [1]: (1) examine the marketplace to identify COTS products, (2) qualify and select one or more products, (3) adapt the COTS product to some specific system requirements, (4) integrate the system components, and (5) update the products if needed. Several methods supporting one or more CBD process steps exist. However, in practice, many problems occur during COTS evaluation, selection and integration: what process and method should the developer follow? which combination of methods should he/she use? what is the “best” method in each step according to the current project and developer preferences? and how to choose it? Is the advocated method in one step has an effect on the choice of the next step method? In order to give solutions to these questions, we have first proposed a model for COTS characterizations which describes COTS features and their usage in the different CBD process steps [5, 6]. We have secondly developed a meta model for CBD process [7]. The choice of methods in CBD is decision oriented, so we have adopted the MAP formalism, allowing to specify decision oriented processes according to Dowson classification of process models [2]. The MAP [3, 4] aims at flexibility: it provides a view that does not impose 1 http://www.microsoft.com/commerceserver/ 2 http://www.peel.fr 3 http://www.amen.fr/static/index.php?pid=20
2
activities to do, but enhances what can be done (next) and how it can be done. The key concepts of the MAP include (1) intention which is a goal that can be achieved by performing a process and (2) strategy which is a manner to achieve an a manner to achieve an intension. It is a labeled directed graph with intentions as nodes and strategies as edges between intentions [3]. Figure 1 illustrates the CBD meta model process where the identified intentions are the different main steps of the CBD process namely: “Identify potential COTS”, “Select one COTS”, and “Integrate COTS in the system”. The strategies are the different means to achieve a process step. In fact, the CBD process begins with the identification of potential COTS. For this purpose, six strategies can be used (one or several) including online and hard copy catalogues, search engine, component marketplaces, publicity, and personal experience. To select a COTS, the strategies to fulfil are criteria-based, scenario-based, metrics-oriented, goal oriented, mixed or using a method of another type. A strategy named “other” is added to hold any evaluation/selection method that can not be classified under the identified methods categories. In the same way to selection, the possible strategies to integrate the COTS in the system once it is selected are based on the classification of integration methods: direct composition-based and architectural framework-based. The process ends by verifying the resulting system. Three main techniques can be used. (1) Interface propagation analysis [11] that predicts what impact a COTS product will have on a system stability, (2) error propagation [12] that determines how far bad input data will propagate through the component interface, and (3) side effects check [13] checks that correct performance of the COTS does not have side effect detrimental to the system. The process can also be stopped, via the “abandonment” strategy, if the evaluation reveals that none of the COTS can be selected either because specific requirements are not satisfied, or because they are incompatible with the current application situation being developed and so their integration will be very costly. On the other hand, the strategy “by re evaluating COTS” holds the case where in practice the integration seems to be more complicated than expected and a re evaluation can be achieved to select another COTS product. The strategy “refine search” is used to continue with the search process in order to refine the result. Certain COTS products present a generic solution to a business process and require parameterization but not integration (as a web site generator) , others can respond to the needs by just installing them. This is illustrated by these two strategies “by parameterization” and “by acceptation”. Thus, the map modelizing the COTS assembling process gives the developer a clear idea concerning the steps to fulfil and the different strategies to use but it is not sufficient by itself. In fact, the map hides guidelines that must be fulfilled in order to be used in practice and to provide more details. The guidelines follow a given notation and are of types tactic (plan or choice) according to NATURE formalism [Nature]. In the sequel, we present some examples of these guidelines. When potential COTS are identified, the map proposes two intentions as illustrated in figure 1: remaining in the same intension “Identify potential COTS” or progressing to “Select COTS”. The guideline ISG1 (Intention Selection Guideline) described in Figure 2, is a tactic guideline and more specifically of type choice. It indicates that for progressing from the intention “Identify potential COTS”, two choices are possible. The first case consists in refining the results in order to find other potential components by means of the Intention Realization Guideline, IRG1 because one unique strategy is provided for attaining this goal. Notes that the two criteria c1 and c2 enable the argumentation of the alternative choices where c1 = the number of identified COTS is not sufficient and c2 = the number of identified COTS is sufficient. 3
The guideline SSG1 is tactic of type choice, we don’t give the associated figure but it looks like that of figure 2. Each of its choice alternatives permit the progression to the intention “Select COTS” by adopting a particular type of selection method via the associated Realisation Intention Guideline (RIG). The key of progression in the map when a strategy must be chosen among others is the criterion and the arguments. For executing each of the strategy, except « by using a method of another type, six Intention Realization Guidelines (IRG1 to IRG6) are proposed. Each IRG proposes a method choice among those belonging to the same category of method. As an example, IRG2 indicates that for selecting COTS by using a criteria method category, three methods are proposed : OTSO, STACE and CEP where IRG5 proposes the use the selection method of Alès&Finkelstein approach or POOR when the category of method is goal-oriented.
Start Personal experiences On-line catalgue
Paper catalogue
Search engine Componnents market place
Publicity
Refine the search
Identiy potential COTS
By using goaloriented method
By using a criteria based By using a method mixed method
By using a scenario based method
By using a method of another type
By using a metric based method
Select COTS By using a composition method by framework By COTS re evaluatio n by parametriza tion
by acceptation
By using a direct composition method By using another integration method
Integrate the COTS in the system By analyzing the interface propagation
By testing errors propagation
Bord effect testing Abandon
Stop
Figure 1: CBD process meta-model
ISG1
C1
C2
Figure 2 : Intention Selection Strategy when potential COTS are identified
4
4. INSTANTIATING THE COTS META MODEL FOR AN ELECTRONIC COMMERCE SOLUTION We first present a typical simple architecture of a web merchant site as illustrated in figure 3. Financial intermediate
Inter net
Applicat ion server firew al
Datab firew ase all server
Web
firew all
serv er
Figure 3 : Simple Web merchant site architecture The architecture shows these different components: 1. A web server : the front office assuring the interaction between clients and the back office. 2. A database server for client, products, orders managements, etc. 3. An application sever for the back office needs. 4. A secure payment kit with probably the intervention of a tier as a financial intermediate. 5. A firewall for security concerns. We have decided to use the following components as COTS : 1, 2 et 5. Notes that the others can also be COTS components but we first experiment our meta model with the reuse of these three COTS. 4.1. Approach application The approach application consists in instantiating the proposed meta process which gives a personalized COTS development process. We submit this task to a group of developers and observe the results which we report in the following. So, the first step consists in identifying COTS components matching our needs. The developer use different strategies as shown in figure 1 and specifically search engines, on line catalogues and their colleagues experiments for identifying a set of COTS candidates. We will list them in the sequel. Notes that we have three needs of different COTS having each one its specific specification, the identification process proposes several COTS for each specification. 4.1.2. Selection method choice Once the potential COTS components identified for each specification, the meta process indicates that we must proceed to the selection of the best COTS by using a selection method. This is done in two steps : 1) choice of the method category and then 2) choice of the more appropriate method in that category The category choice is based on previous experiences or given by an expert and can be also done by the developers. The group of developers choose the criteria-based category for the following reasons: 5
•
They are more used with criteria definition, the heights assignments and the evaluation of the candidate products (COTS). • They are not familiar with the goals definitions and scenarios writing. • They avoid the use of metrics. The method category fixed, three methods are encapsulated under this category : OTSO, STACE and CEP. One of these methods must now be chosen. An Intention Realization Strategy IRS indicates that we must apply AHP technique, Analytic Hierarchy Process [8], which is based on multi criteria analysis to help in making decision about which alternative to choose. The alternatives, methods in our case, are featured by a set of quantitative and/or qualitative interdependent criteria. AHP results on a general appreciation of each alternative desirability. In fact, the developers specified the following preferences concerning the selection method criteria: 1. Selection method must deal with component functional needs (we denote this feature by: BF), 2. Selection method must deal with component non functional needs (we denote this feature by: BNF), 3. Evaluation process qualification must be present in the selection method (we denote this feature by: PE), 4. Decision analysis and its qualification must be present in the selection method (we denote this feature by: AD). So, features BF, BNF, PE et AD are the criteria used in the application of the AHP technique. According to the project to develop, e-commerce web site in our case, and the developer profiles, those give the following rates to the four criteria which are : BNF is less « more important » than BF and is «a little bit more important » then the AD criterion. PE is «more important » than AD and is «a little bit more important » than BNF feature. Finally, BF is less « more important » than PE feature and « a little bit more important » than AD feature. This is illustrated in table 1 by matrix MC which uses the AHP scale [8]. We also give in table 1 the associated eigen vector VPC determined by AHP application. Table 1: Comparision Matrix of selection me thods features and its eigen vector BF MC= BNF PE AD
BF BNF PE AD 1/1 1/4 4/1 3/1 4/1 1/1 1/3 3/1 1/4 3/1 1/1 5/1 1/3 1/3 1/5 1/1
0.3132 VPC= 0.3312 0.2963 0.0593
We than build another matrix, say MPM which is obtained by a series of AHP matrices calculations based on the fixing of selection methods priorities according to each criterion BF, BNF, PE and AD. The four obtained eigen vectors form MPM matrix. Then multiplying MPM with the previous calculated VPC (given in table 1) gives Vahp vector. This latter illustrates selection methods ponderations. MPM and Vahp are given in (1) MPM
VPC
Vahp
0 .3132 Otso 0.3325 0. 3325 0. 2500 0. 3090 0 .3067 (1) 0 .3312 Stace 0.5278 0. 5278 0. 2500 0. 1095 × = 0 .4207 0.2963 0.2726 Cep 0.1397 0.1397 0. 5000 0. 5815 0.0593
Thus, the more appropriate method for the group of developers profile is the one having the greater score. STACE selection method is then the more appropriate. When applying STACE, our meta process, gives guidelines about how to apply it in order to help the developer. We treat this in the next section. 6
4.1.3. Selection method application The application of the chosen method STACE, will give the selection of COTS components for the electronic commerce architecture. This method takes 4 steps : 1) Capture of the needs, 2) Socio-technique criteria definition, 3) COTS candidates identification, and 4) Candidates evaluation. Notes the possibility of decisions reviews undertaken in the precedent steps in order to adjust or refine them. When applying these 4 steps, the group of developers go directly to the second one because they already capture the components needs for each needed COTS. We illustrate the work done for each kind of COTS in the sequel and present finally the proposed better COTS to be selected. 4.1.3.1. Database server selection The identified socio-technique criteria definitions are : 1. Technological criterion: the product must be ODBC compatible, 2. The functional criteria: data management must be relational and XML data, 3. Quality criterion: authentification, access control and easy administration. 4. Socio-economic criteria: vendor reputation and product cost. One of the map guideline in STACE application leads to the calculation of the priority matrix between these criteria by using AHP technique. Then the weight of each criteria category (except the technological criteria) must be determined. In the same way as done above and without detailing, we obtain the matrix MPCC in table 2 and VPCC its eigen vector. Table 2: Comparison matrix of category criteria and its eigen vector Functional
Quality
1/1 1/2 1/4
2/1 1/1 1/4
Functional MPCC= Quality Socio economic
Socio economic 4/1 4/1 1/1
0.5470 VPCC= 0.3445 0.1085
Next, the criterion belonging to a same category are also compared (in the same manner by AHP which comes from a Realisation Intention Guideline from the CBD meta-model) and we give in table 3, 4, 5 the associated results with different matrices MPCF, MPCQ and MPCS with their associated eigen vectors: Table 3: Comparison matrix of functional criteria and its eigen vector XML/REL MPCF= Cipher Partageability
XML/REL 1/1 1/3 1/1
Cipher 3/1 1/1 3/1
Partageability 1/1 1/3 1/1
0.4286 VPCF= 0.1428 0.4286
Table 4: Comparison matrix of quality criteria and its eigen vector Security MPCQ= Easy administration
Security 1/1 1/3
Easy administration 3/1 1/1
0.75 VPCQ= 0.25
Table 5: Comparison matrix of socio-economic criteria and its eigen vector 7
reputation cost reputation 1/1 1/3 0.25 MPCS= cost 3/1 1/1 VPCS= 0.75 The next step consists in identifying alternatives of COTS components and then their filtering by using the technological criterion. The identified web servers are : Oracle, MS SQL Server, Sybase ASE, Interbase, MyS QL, PostgresSQL, Ipedo XML database, IxiaSoft TextML, Software AG Tamino, Xpeerion Agilience, Apache Xindice et eXist. By using the technological criterion, several database servers are eliminated because they are not commercial or because they are not ODBC compatible. So, the remaining COTS components are : (1) MS SQL Server, (2) Sybase ASE, (3) MySQL, (4) Oracle, et (5) Software AG Tamino. The last STACE step consists in a detailed evaluation of retained alternatives by using the functional, quality and socio-economic criterion. So, several matrixs are calculated according to each criterion. Table 4 gives an example of such matrix : Table 6: Comparison matrix of candidate database servers according to the criterion relational/XML its eigen vector XML/R EL SQL Server MF1= Sybase MySQL Oracle Tamino
SQL Sybase Server 1/1 5/1 1/5 1/5 1/3 4/1
1/1 1/3 2/1 5/1
MySQL Oracle
Tamino
5/1
3/1
1/4
0.2582
3/1 1/1 3/1 5/1
1/2 1/3 1/1 4/1
1/5 1/5 1/4 1/1
VF1= 0.0815 0.0494 0.1185 0.4924
The final result is obtained by multiplying the matrix formed by the eigen vectors according to each criteria category (functional VF, quality VQ and socio-economic VS) by the eigen vector representing the weights of these criteria categories (2), VPCC previously calculated and given in table 2. The resulted vector shows that Tamino has the highest score, so it will be selected by the group of developers as a COTS component to be reused in the e-commerce architecture.
×
functional Quality Socio economic
VPCC 0.5470 0.3445 0.1085 (2)
SQL Server Sybase ASE MySQL Oracle Tamino
VF VQ VS 0.2393 0.2115 0.1536 0.1330 0.1656 0.0484
0.2204 0.1351 =
0.1231 0.1689 0.5164 0.1648 0.2633 0.1666 0.3398 0.1907 0.1150
0.1816 0.1989 0.2640
For the other COTS, we do the same steps. We will summarize the results in the sequel. 4.1.3.2. Web Serveur selection 8
The identified criteria for the web server according to each category proposed by STACE are : 1. Technological criteria : Unix plateform. 2. Functional criteria : configurable activities journals with visualisation facilities. 3. Quality criterion : (1) performance and (2) easy administration. 4. Socio-economic criterion: (1) vendor reputation and (2) product cost. Identified web servers are : Apache Web Server, Micsosoft IIS, SUN Java System Web Server, Zeus Web Server, Redhat Stronghold. After filtering based on technological criterion, the candidates products are (1) Stronghold Enterprise Secure Web Server, (2) Sun Java System Web Server 6.1 and (3) Zeus Web Server 4.2. Without detailing, table 7 gives the Ponderation Matrix of web servers by criterions category. Table.7: Ponderation Matrix of web servers by criterions category Stronghold Sun web server Zeus web server
functional 0.1897 0.2631
Quality 0.1569 0.2423
Socio economic 0.3536 0.5085
0.5472
0.6008
0.1379
The final weights for web servers are obtained by multiplying the weights vectors of these servers according to each category of criterion (functional, quality and socio-economic) by the eigen vector representing the weights of these criteria categories (3).
×
functional Quality Socio economic
0.5470 0.3445 0.1085 (3)
Stronghold 0.1897 0.1569 0.3536 0.1962 Sun web 0.2631 0.2423 0.5085 = 0.2826 server Zeus web 0.5472 0.6008 0.1379 0.5212 server Zeus Web Server presents the higher weight and so is the better COTS to be selected. 4.1.3.3. Firewall selection The identified criteria for the firewall according to each category proposed by STACE are : 1. Technological criteria : Windows plateform. 2. Functional criteria : (1) IP firewall (low level filtering : TCP/IP protocols), (2) non IP firewall (filtering of other protocols) 3. Quality criterion : (1) administration facility, (2) problems detection capabilities and (3)security (tests as « leak », « yalta », « tooleaky », « firehole »). 4. Socio-economic criterion: product cost. The identified firewalls are : Look’n Stop, Kerio Personal Firewall, Outpost Pro, Zonealarm Pro, Netbarrier, Sygate Personal Firewall, Atguard, Deerfield Personal Firewall, Tiny Personal Firewall. After filtering, the remainded firewalls are : (1) Look’n Stop 2.05, (2) Outpost Pro 2.5, (3) Zonealarm Pro 5, (4) Tiny Firewall 6. Without detailing, table 8 gives the Ponderation Matrix of firewalls by criterions category. Table 8 : Ponderation Matrix of firewalls by criterions category Functional
Quality
Socio-economic 9
Look’n Stop Outpost Pro Zonealarm Tiny Firewall
0.3274 0.2498 0.2114 0.2114
0.4254 0.1957 0.2723 0.1066
0.375 0.375 0.125 0.125
The final weights for firewalls are obtained by multiplying the weights vectors of these firewalls according to each category of criterion (functional, quality and socio-economic) by the eigen vector representing the weights of these criteria categories (4).
×
functional quality Socio-economic
0.5470 0.3445 0.1085 (4)
Look’n Stop Outpost Pro Zonealarm Tiny Firewall
0.3274 0.2498 0.2114 0.2114
0.4254 0.1957 0.2723 0.1066
0.375 0.375 0.125 0.125
=
0.3663 0.2448 0.2230 0.1659
Look’n Stop was the one presenting the highest score. component for the e-commerce solution.
So, it is selected as a COTS
4.1.4. Process termination After the different COTS selection, the meta process indicates that the developers can choose among these alternatives : 1) integrate these components, 2) parametrize them or 3) use them directely . In this case, the parametrization is sufficient to have the desired needs of the ecommerce solution architecture.
5. CONCLUSION AND DISCUSSION For an e-commerce solution architecture, the process that the developers followed was an instantiation of a meta process and consists in : 1) candidate COTS products identification, the choice of the selection method category, the choice of the selection method and the application of this latter in order to retain the most appropriates COTS components. Finally the parametrization strategy is used to respond the application need. The selected candidates, Tamino, Zeus Web Server, Look’n Stop may appear a little bit strange but the group of developers profiles and their decisions (multiple criteria) can explain this fact. With other profiles, the instantiation of the meta process can give other results (this is a meta process, so it gives multiple alternatives and presents personalization of the developer process). This is not strange because there is never one unique solution for a given need. The COTS costs can also be an important criterion and influence the choice of the associated products. Our near future work consists in identifying a set of payment kits such as KLELINE solution, paypall, C-SET, Epay-security, etc. and investigate which solution can be the best for a merchant site. As we know, security criteria needs to be well taken into account specifically in a commercial web site. To summarize, three solutions can be proposed to any enterprise willing at developing an ecommerce web site. They are all based on reusing existing solutions and/or software COTS components that can be integrated to give the e-commerce solution. The choice of one solution between the three depends on economic, technical, organizational and strategic factors of each enterprise. Reuse for such application is the best choice than developing from scratch and we deal in this paper with details about the third solution which needs an entire process and guidelines helping in developing by using a reuse approach.
10
REFERENCES [1] Alves, C., Castro, J., CRE: a Systematic Method for COTS Components Selection, 15th Brazilian Symposium on Software Engineering, Rio de Janeiro, Brazil, October 2001. [2] Alves, C., Finkelstein, A. Challenges in COTS-Making: a Goal-Driven Requirements Engineering Perspective Workshop on Software Engineering Decision Support, in conjunction with SEKE’02, Ischia, Italy, July 2002. [3] Assar, S., et al. Un modèle pour la Spécification des Processus d’Analyse des Systèmes d’Information, In Proceedings of the INFORSID’2000 conference, Lyon, France, May 2000. [4] Ben Achour, C., Extraction des Besoins Par Analyse des Scénarios Textuels, PhD Thesis Université Paris 6 –Pierre et Marie Curie, January. 1999. [5] Ben Sassi, S., Labed, L., Ben Ghezala, H., COTS Characterization Model in a COTSBased Development Environment, 10th Asia Pacific Software Engineering Conference, Chiang Mai, Thailand, December 2003. [6] Ben Sassi, S., Labed, L., Ben Ghezala, H., COTS Description: An Overview and Framework Proposal, International Arab Conference on Information Technology, Alexandria, Egypt, December 2003. [7] Ben Sassi S., Labed Jilani, L. & Ben Ghezala H. "COTS-BASED Development Process Meta modelling", 3rd ACS/IEEE International Conference on Computer and System Applications (AICCSA-05), Egypth, January 2005. [8] Benjamen, A. Une Approche Multi-Démarches pour la Modélisation des Démarches Méthodologiques, PhD Thesis Université Paris 1 - Sorbonne. Oct. 1999. [9] Boehm, B., Abts, C. COTS Integration: Plug and Pray, IEEE Computer, January 1999. [10] Brownsword, L., et al. Developing New Processes for COTS-Based Systems; IEEE Software, August 2000, 48-55. [11] Lawlis, K., et al , A Formal Process for Evaluating COTS Software Products, IEEE vol34, May 2001 [12] Medvidovic, N., et al. Reuse of Off-the-Shelf Components in C2-Style Architectures, In the proceedings of ICSE.97, Boston, MA, 1997. [13] Morisio, M., Sunderhaft, N. Commercial-Off-The-Shelf (COTS): A Survey, Data & Analysis Center for Software, Technical Report, December 2000.
11
