software development [9, 10]. CBD emphasises reuse, while other methods such as OO ignore this issue, or introduce it too late in the lifecycle [11]. Components ...
Evaluation of Component-Based Development Methods Nicky Boertien, Maarten W.A. Steen, Henk Jonkers Telematica Instituut P.O. Box 589, 7500 AN Enschede, the Netherlands E-mail: {boertien, msteen, jonkers}@telin.nl Abstract. Component-based development (CBD) has received a lot of attention in software engineering literature over the last few years. Awareness has been raised that CBD is the way to go in software development, especially in the domain of e-business where the benefits of reusing components, i.e., faster time-to-market and quality, are essential. The question now is how to realise the full potential of CBD? Did we achieve reuse yet? In order to answer these questions, we evaluate and compare five popular methods for component-based development, including Catalysis, the Rational Unified Process and Select Perspective, on their maturity and fitness-for-use in the context of e-business engineering. The evaluation is done based on our own reference framework for ebusiness development and a list of objective criteria. The methods each emphasise certain aspects of CBD, but as yet none of them offers a complete solution.
1
INTRODUCTION
Component-based development (CBD) is often hailed as the solution to application development in the 21st century (e.g., see [1, 2, 3, 4]). Largely based on its focus on reuse, its proponents promise faster time-to-market, cost reduction, better quality, flexibility, and scalability. All qualities that are badly needed in the networked economy of today. At the same time we are witnessing the birth of a new engineering discipline. Enterprises are increasingly dependent on Information and Communication Technology (ICT). ICT has evolved from a supporting role to the core business of many organisations. This transition to e-business (i.e., doing business using ICT) requires a multidisciplinary approach that combines elements of business process reengineering (BPR), supply chain integration, marketing, and software engineering [5]. We call this new discipline e-business engineering. As we will argue below, CBD has a central role to play in e-business engineering. The question that we were concerned with is: what kind of method enables us to take advantage of all benefits of CBD in the context of e-business engineering? The goal of our research is developing a methodology for component-based e-business engineering that is as much as possible based on best practices. This paper reports on the first step we took in this direction, that is, the evaluation of a selection of CBD methods: CADA, Catalysis, Comet, Rational Unified Process and Select Perspective. 1.1
Component-based development
Component-based development is an approach for system analysis and design that has evolved from the Object Oriented (OO) paradigm. It has received a lot of attention in software engineering literature over the last few years, e.g., see [6, 7, 8]. Rather than fine-grained objects, it places large, independently packaged, reusable components, sometimes referred to as subsystems, at the core of software development [9, 10]. CBD emphasises reuse, while other methods such as OO ignore this issue, or introduce it too late in the lifecycle [11]. Components represent coherent parts of a system that can be independently stored and assembled into new software systems. The potential for savings on development time and costs are obvious. In addition, because of its structure, a component-based application will be more flexible and scalable. The use of components guarantees a better quality as components are frequently used and improved over time. Ideally, a software developer could use components of other unknown developers. This would shorten software development times even further, but it imposes two crucial methodological 1
requirements. First, components should be unambiguously specified, which would enable developers to position a component: what is its functionality, where and how to use it. Initiatives for this are emerging [12, 13]. Second, CBD needs a process in which these issues are dealt with. 1.2
E-business development
E-business needs the benefits CBD provides: faster time-to-market, flexibility and scalability. Fast adaptability to changes in the market is crucial in e-business. Next to this, networked enterprises are emerging: business processes around the globe are linked, and so are their corresponding software systems. What is needed is an integral approach to e-business engineering that combines networked enterprise (re)design with the component-based development of transaction services [5]. 1.3
Structure of this paper
The rest of this paper is structured as follows: section 2 describes our approach to evaluate CBD methods: our point of view, and the criteria we used. Section 3 describes the analysis of the investigated methods according to the evaluation criteria. Our findings of the evaluation are described in section 4. Section 5 gives suggestions for future research as a continuation of our findings. 2
APPROACH FOR EVALUATION
Many approaches for evaluation exists, e.g., see [14, 15, 16, 17]. For the evaluation of the CBD methods we used two complementary approaches. On the one hand, we used a fairly standard framework for method evaluation proposed by Wijers et al. (e.g., see [18]). This framework is because of its generic character suitable to adapt to specific issues in CBD. This is further elaborated in section 2.1 below. On the other hand, we had to evaluate the methods on their appropriateness for e-business engineering. To this end, we use our own reference framework for e-business engineering methods, which is introduced in section 2.2 below. 2.1
Criteria for evaluation
Consistent with the framework for understanding methods introduced in [18] we investigated for each method the concepts, the procedures (“way of working”), the techniques (“way of modelling”), the philosophy (“way of thinking”) and the level of tool support (“way of supporting”). Each method description in section 3 incorporates these issues. We specified these aspects to issues specific for CBD methods, such as reuse and applicability of the method. We added two general criteria to obtain a more overall view. The way of thinking is not further detailed but incorporated in the general description of the methods (see section 3). The selected methods are evaluated along these criteria. The results are outlined in an evaluation table, shown in Table 1. Below we introduce the criteria used. General criteria • •
Background. The background of a method, i.e., whether it was developed in industry or in academia, is only used in combination with other criteria. It shows possible correlations between background and other criteria such as tool support. Usage. The degree of usage of the method may give an indication of its level of maturity. Some caution is warranted though. Firstly, we can only give a rough indication, since we do not have factual data on the actual usage of methods. Secondly, some methods existed before CBD was introduced as a new, additional feature, which its user base may or may not be using.
Way of working •
Process support. A method would not be a method if it did not provide some guidance for the development process. The form of this guidance can, however, vary considerably. There are
2
•
methods that define a strict order of activities, whereas others only define the major milestones or aspects that ought to be addressed. Reuse support. One of the main advantages of component-based development is the scope it offers for reuse. In the evaluation of the various methods we looked at the level of support that is provided for reuse: What are the units of reuse? Can only software components be reused (code or executables), or also, e.g., business models? Is there a specific model addressing reuse? Does the method provide a generic description of components for reuse, including the context in which a component can be used (e.g. as a pattern [19])? Does the method provide procedures for storing components in a repository and retrieving them again?
Way of modelling •
Modelling techniques used. The choice of method is often determined by the modelling techniques that the method supports or uses. Therefore, we give an indication of the kinds of modelling technique that are employed by the methods.
Way of supporting • •
2.2
Tool support. In our opinion, a method will not be used unless it has tool support. The level of tool support may vary from generic drawing and modelling tools to integrated tool suites that even guide the developers through the process. Implementation platform. Some methods are specifically tailored to a particular implementation platform or architecture. If so, this will be an important criterion in the selection of a method. Reference framework
low-level
high-level
Next to the evaluation of the CBD methods along the described criteria, each CBD method is evaluated on their appropriateness for e-business engineering. In order to be able to reason about this issue in a method-independent way, we have proposed a framework for e-business development, which is illustrated in Fig. 1. More detail on it is described in [20]. This framework identifies seven different aspect areas, called cornerstones, that should be addressed when developing e-business solutions. Ambition & scope Networked Enterprise
Systems
Transaction Scenarios
System Components
Procedures
Protocols
Business
Technology
Fig. 1. The e-business development framework
The cornerstones are divided in business-oriented ones (on the left) and technology-oriented ones (on the right). • Ambition & Scope addresses the objectives of the development trajectory, which may be formulated both in terms of business goals and in terms of technology constraints. • The Networked Enterprise cornerstone provides a high-level view of the networked enterprise in terms of the actors involved, the roles they fulfil and their relationships, but also in terms of the business functions they perform and the flows between these. • The Transaction Scenarios cornerstone addresses the inter-organisational processes and transactions between businesses in the networked enterprise. • The Procedures cornerstone addresses the interactions and message formats for conducting transactions between organisations. 3
• The Systems cornerstone addresses the architecture and the composition of e-business systems. • The System Components cornerstone addresses the specification, design and management of software components. • The Protocols cornerstone addresses the protocols used for communication between components, as well as the inner workings of these components where necessary. The crossover from business-oriented modelling and design to system-oriented modelling and design is somewhere between procedures and protocols. Here the division between the two ends of the spectrum gets blurred. At the higher levels of abstraction, there is a more pronounced gap (also visualised in Fig. 1) between business modelling and technology-oriented modelling. Clearly, the development framework does not provide sufficient guidance in developing e-business applications. It constitutes a map of relevant aspect areas in e-business development, yet it does not provide the shortest, best, or even any, route to come from a given starting point to operational systems. This is where methods come in. We follow Brinkkemper [21] in defining a method to be an integrated collection of procedures, techniques, and product descriptions to support the software engineering process. The e-business development framework is used for positioning the methods. We studied to what extent the cornerstones of the e-business development framework are covered by the various methods. This gives us an indication about the issues addressed by the method and its fitness-for-use. 3
ANALYSIS OF METHODS
Because component-based development is a relatively new approach to software engineering, the number of methods specifically designed for CBD is still limited. Some CBD methods are extensions of existing methods, in particular methods for object-oriented development. One can make a distinction between methods developed in an academic setting and methods with an industrial background. The latter kind is usually associated with a specific set of software development tools. In order to obtain a representative overview of methods, we include two examples of each kind in our comparison, as well as one intermediary variant. We do not aim to present an exhaustive survey. Because of the popularity of Rational’s modelling and implementation support tools, the Rational Unified Process (RUP) method [9] is an obvious candidate for evaluation. The Select toolset of Princeton Softech is also well known, and is accompanied by a well-documented method for CBD [22]. Therefore, we have chosen these two as the industrial methods in our comparison. From an academic environment, Catalysis [10], originating from Brighton University, is one of the best known and most frequently cited methods. As a second candidate in this class, we studied a new development within the EU project OBOE, developed at SINTEF in Norway, called COMET [23]. Finally, we describe the COMPAS Analysis and Design Approach (CADA) [24], developed at the Ordina Institute for Research and Innovation. CADA has an academic foundation, because it was inspired on Catalysis, but it also contains several additional ideas based on practical applications of the method. Therefore, it can be considered a hybrid of an academic and an industrial method. In the remainder of this section, we summarise our analyses of the selected CBD methods. A more exhaustive overview of our research is given in [25]. The methods are presented in alphabetical order. Each method is introduced with information about its background, way of thinking and way of working. After this introduction, the method is evaluated by relating it to the e-business development framework defined in section 2.2. A dot in a cornerstone indicates that the cornerstone is represented in the method. The second means of evaluation is presented in section 3.6, which shows a table with all methods evaluated to the list of criteria as defined in section 2.1. 3.1
CADA
CADA is a new software development methodology developed by Ordina Institute for Research and Innovation [24]. CADA was not developed from scratch, but incorporates ‘best-practice’ methods and techniques from the following sources: • Catalysis [10]. • CRC (Class, Responsibility, Collaborations) cards [26]. 4
• DSDM: Dynamic Systems Development Method [27]. • UML: Unified Modelling Language [28]. The CADA concepts largely correspond to those of Catalysis. However, CADA incorporates more concepts from the UML implementation diagrams and adds a number of concepts for business modelling. One of the central ideas behind the CADA methodology is that a method should support analysts and designers, not dictate them. Therefore, CADA provides guidance for the various design stages, but without prescribing the precise order in which steps have to be taken. CADA distinguishes the following activities: 1. Develop global business model; 2. Develop detailed business model; 3. Develop context model; 4. Develop global system model; 5. Develop detailed system model; 6. Develop deployment model. It defines deliverables for each of these activities. The order in which the various activities are performed is not prescribed. Instead, there are clearly defined dependencies between the deliverables. The context model, consisting of use case models and activity diagrams, provides the link between business modelling and system modelling. CADA provides guidelines and techniques for identifying components during design, but does not provide specific guidance on how to incorporate existing components into a new design. Reuse gets little attention. As shown in Fig. 2, CADA covers almost all of the cornerstones of the e-business framework. Only the Protocols cornerstone is not covered as no specific guidelines are given for implementation. Use case diagrams and activity diagrams together form the CADA context model. This model serves also as a means to connect the business-oriented models to the system-oriented models.
1
Ambition and scope
Networked Enterprise
3
Transaction Scenarios
2
8 Systems 4
6
7
System Components
5 Procedures
Protocols
1. 2. 3. 4. 5. 6. 7. 8.
global business model scope demarcation business model use case model activity diagram component model frameworks system and deployment model
Fig. 2. Coverage of CADA
3.2
Catalysis
Catalysis is a research initiative developed at the University of Brighton by D’Souza and Wills. The method is intended to support the modelling and construction of open distributed systems. Open distributed systems are considered to evolve in form and function over time, as components and services are added and removed from it. Catalysis is about the incremental construction of a business model using packaging, refinement and decomposition. Catalysis provides examples of this process, but does not provide a fixed set of milestones, nor does it provide a predefined way for software development. In the final model, a level of granularity is reached in which components in the model are recognisable in both the business process and the implementation. A shared vocabulary accompanies the model. This together is called a Type Model, an example of which is given in Fig. 3. The Type Model represents both real-world objects and their interactions. It serves as a communication mechanism between analysts and designers. Reusable frameworks for designs, specifications and architectures can be extracted or used in the process of modelling.
5
Catalysis pays a lot of attention to the mapping between business process and implementation as is shown in Fig. 4. The Type Model plays an important role in this.
Fig. 3. Type Model
Ambition and scope Networked Enterprise 1 Transaction Scenarios
Procedures
4 Systems 2
5
System Components
3
1. business model 2. context model; architecture 3. component model 4. system specification 5. type model; frameworks; patterns
Protocols
Fig. 4. Coverage of Catalysis
3.3
Comet
The “COmponent-based METhodology” (COMET), described in the “Component-Based Methodology Handbook” [23], has been developed in the Open Business Object Environment (OBOE) project, submitted under the ESPRIT framework IV. Several user groups and technology suppliers are involved in the project. The Norwegian research institute SINTEF is responsible for the development of COMET. COMET is characterised by development of application-independent business object models, and the realisation of these models in software components. It is a stepwise description that gives guidelines of how to analyse, design and implement software systems, in particular distributed information systems. For the realisation, OMG’s Business Object Facility (BOF) is recommended. An implementation of this platform, on top of CORBA, is also under development within the OBOE project. A large part of the methodology, however, is independent of the implementation platform. COMET consists of three main modelling phases: business modelling, component-modelling and implementation modelling. These phases are traversed more or less in this order, although the method does not prescribe a strictly linear process: like most methods, it allows incremental and iterative development of software. Each of the models consists of a number of submodels, as shown in Fig. 5. In each of the three phases, a reuse model is used to explicitly address the reuse of components. This model is orthogonal to the other models, and uses the notion of a reuse repository. This repository is used in two ways:
6
• Search the reuse repository for reusable components, frameworks, design patterns etc. that may be used in the current design. • Identify possibly reusable components, frameworks, design patterns etc., and, once they have been developed, add them to the reuse repository.
Requirements Model
Business Process Model
Organisation Model
Enterprise Distribution Model
Business Model Reuse Model Component Model
UI Model
Service Model
BO Model
System Distribution Model
Implementation Model
Component ImplementationModel
DB Model
Integration Model
Test Model
Fig. 5. Overview of COMET models and their relations
Fig. 6 shows how the different models used in COMET relate to our framework presented in section 1.1. It appears that, to a certain extent, COMET covers all the aspects that we identified in our framework, although the distinction between transaction scenarios and procedures is not made. 1 Ambition and scope
Transaction Scenarios
2
Procedures
1. 2. 3. 4. 5. 6. 7. 8.
Systems 5
Networked 3 Enterprise 4
6
System Components
Protocols
5
global business model scope demarcation business model use case model activity diagram component model frameworks system and deployment model
Fig. 6. Coverage of COMET
3.4
RUP
The Rational Unified Process (RUP) [9] is the software engineering method of the Rational Software Corporation. It is an iterative, object-oriented, controlled and tool-supported method applicable to all sorts of software development projects. The RUP enjoys a considerable popularity in the software industry, especially amongst users of Rational’s modelling and implementation support tools. The RUP describes mainly a “way of working,” as the UML [28] is the preferred “way of modelling.” The development process is divided in four phases: inception, elaboration, construction and transition, and an arbitrary number of iterations. In addition, the RUP is structured along a number of workflows, which group different kinds of activity, viz. Business modelling, Requirements, Analysis & design, Implementation, Test and Deployment, but also a number of supporting workflows, such as Project management and Configuration & change management. The RUP does not really introduce new modelling concepts, as it relies on the UML for those, but it does introduce a number of concepts for describing methods, such as worker, artefact, activity and workflow. These respectively capture who should be doing what, how and when. 7
The RUP provides some guidance for developing and modelling (with) components, but this guidance is rather limited and stays pretty much at the level of packaging source code. “Componentbased development is (just seen as) a variation on general application development”. [29]
Ambition and scope Networked Enterprise
1
Transaction Scenarios
Procedures
Systems 5
2 3
System Components
4
1. 2. 3. 4. 5.
business modelling requirements analysis & design implementation deployment
Protocols
Fig. 7. Coverage of the RUP
The Business Modelling workflow defines the Business Use-case Model and the Business Object Model. These models cover much of the business modelling side of the e-business framework (see Fig. 7). The Requirements workflow relates the business modelling side to the system modelling side. The Analysis & Design workflow runs all the way through the technology-related cornerstones, as it produces the system architecture, identifies and specifies components as well as protocols. In the Implementation workflow the components are realised in code, so this workflow can be related to the Components and Protocols cornerstones. The Deployment workflow, in which the working system is documented, can be related to the Systems cornerstone. 3.5
Select Perspective
Select Perspective is a method for developing software applications. It is supported by several tools from Princeton Softech of which Select Enterprise (which provides Business Process Modelling, UML, and data design models), and Select Component Manager (which is a library for component specifications and finished components) are the most important ones. Select Perspective claims to be a practical approach for application development. Therefore, the main ideas of the methodology are about results that are scalable and adaptable to changes. To achieve this goal, Select Perspective is based on CBD. According to Princeton Softech, CBD capitalises on previous methodologies such as Structured Development, RAD, Object-oriented development, and extends these. Select Perspective is a hierarchical method. It has phases, core activities within each phase, and within each activity a standard method. The phases are “align”, “architect” and “assemble” (see Fig. 8). The grey-and-white square represents the scope of the full application; each white rectangle represents a solution increment within this application. The more time has passed, the more parts of the application are defined.
Fig. 8. The three major phases of a development project [22]
The align phase begins by addressing the broad scope of the intended application, then drills down into a single “increment”, or solution. The overall system architecture is elaborated while more increments are delivered. Within each phase, activities are repeated (iterative development) and a fixed set of activities are done in parallel (parallel development). In each parallel activity it is possible to use techniques in which the company has already invested, but Select Perspective prefers their own 8
method, called LUCID. The core idea of all these steps is the tight linkage between the application and the business process. Select Perspective is time-boxed: after each period there is a visible result. Compared to the e-business framework, Select Perspective provides extensive support for all cornerstones, except for protocols and ambition & scope (see Fig. 9).
Ambition and scope Networked Enterprise 1 Transaction Scenarios
Procedures
Systems 4
2
3
System Components
5
Protocols
1. to-be business process model 2. use case model 3. class modelling; interaction modelling; UML class model/ relational DBMS schema entity-relationship diagram 4. component specifications; new component version; component data model; Select component manager 5. data model; application; next application release; program templates
Fig. 9. Coverage of Select Perspective
3.6
Assessment based on the evaluation criteria
Next to the evaluation of the methods to our reference framework (fig. 2, 4, 6, 7, 9), all CBD methods will be evaluated on a list of criteria, defined in section 2.1. To obtain overview we summarised the data in the table presented below. It shows all methods evaluated to the criteria.
9
Table 1. Evaluation of CBD methods Method
CADA Hybrid
Catalysis Academic
COMET Academic
RUP Industry
Select Perspective Industry
Usage of methodology
Ordina
Several Fortune 500 companies [30]; Influences other methodologies
Only in user case within OBOE project
Adopted by some major players
Regularly used
Process support
Milestones; Guidelines
Guidelines
Milestones; Guidelines
Phases; activities; workflows;
Units of reuse
Patterns; component
Patterns available
No
Framework; Patterns; components Yes
Components; patterns; frameworks No
Milestones; Guidelines; templates; and tool mentors Software components No
Yes
Component library
No
No
No
No
Yes
UML CRC cards Business Model (proprietary) No dedicated support, standard UML tools can be used for modelling
Several UML diagramming techniques
Several UML diagramming techniques
UML and others
Business Process Modeling; several UML diagrams ; Relational DBMS schema; ER diagram;
No dedicated support, standard UML tools can be used for modelling
No dedicated support, standard UML tools can be used for modelling
Extensive support from the Rational Suite
Not mentioned
Platform independent, e.g., Java, CORBA.
Business Object Framework (BOF) on top of CORBA.
Platform independent
Select Enterprise; Select Component Manager; UML tools; BPM tools; OO tools; Data modeling tools. Platform independent, e.g., Java, CORBA.
Reuse
Background
Modelling techniques used
Tool support
Implementation platform
4
Patterns; components;
FINDINGS
In this section, we compare the main features of the methods described. The methods are discussed on basis of our research, of which section 3 is a summary. First, the methods are compared based on the list of evaluation criteria, summarised in Table 1. Second, the positioning of the methods in our reference framework and general remarks resulting from our evaluation are discussed. Process support Except for Catalysis, each method describes milestones, which should be completed at the end of a phase in the development process. The trajectory to pass through the stages is not strict; the user can tailor it to his situation. Next to this, the top-down approach is abandoned; four methods show a software development trajectory with an incremental character. Guidelines are provided to help the user during the process. The guidance a user gets during the process, however, differs substantially. Milestones are roughly defined; results of each stage or the activities are not well outlined. The five methods show two extremes: Select Perspective provides a very strict process with clear results and activities, Catalysis limits itself to examples of how to use the method in some specific situations. The others, CADA, COMET and the RUP, are in-between these extremes. Reuse For reuse purposes, it is necessary to record information about components. This should be done in a fixed structure in order to know on which aspects a component can be searched for. An example of such a template is a pattern [19]. The idea to record knowledge exists in all investigated methods, how to realise it remains vaguely. This holds for both the patterns themselves and the usage of patterns 10
during the process. It is not surprising, therefore, that few methods have patterns available. Select Perspective jumps out with Component Manager, a mechanism for storage and retrieval of components. The other methodologies rely on experiences of developers in finding components. Usage of methodology As the evaluation table shows, both academia and industry are convinced of the advantages of CBD. It is not only used in specific cases but in several companies as well. Modelling techniques used It is clear that UML is highly represented for modelling during the system development process. Several diagrams are used; unfortunately it is not always clear which diagram types of UML, which makes it hard to be more precise. UML is primarily used for modelling software systems. When it comes to business modelling, three methods use UML as well, but extend it by adding extra information to the diagrams. The other two methods introduce their own, proprietary technique for modelling the business process. From the methodologies, only Select Perspective supports several techniques next to the technique which is introduced by the method itself. Tool support The majority of the methods does not provide dedicated tool support, but refers to standard UML tools. How to make the proprietary models is left aside. This is surprising because how to realise the models without tool support? This aspect clearly shows the difference of background: only Select Perspective and the Rational Unified Process, which originate from industry, provide extensive tool support. Implementation platform All methods claim to be platform-independent, sometimes Java and CORBA are suggested. As a consequence, how to translate the models into code is not made explicit either. Summarising our findings, we see that the idea of CBD is not yet fully integrated in the investigated methods. Instead of components, other issues such as the applicability of the method, or a better managed and controlled process are emphasised. Actually, when studying these arguments, it seems that the role of components is only one of the many new things in the method. The component concept is poorly defined. Opinions are diverse and at the level of “functional element” or “subsystem”. Except for CADA, characteristics of a component are not defined. As a consequence, a transparent method to distinguish components during the process is and cannot be provided. Because components are at the heart of CBD, this is a serious gap. The collaboration between components is specified neither. Three methods declare that a connection is made by means of interfaces. More detail on this, for example how to bridge the gap in functionality which might be lacking in both components, is not given. The comparison with the e-business development framework shows that both business and implementation aspects are considered important. A tight relation between the business process and the software system also is. However, the guidance for mapping the business needs onto the application is limited. Three methods link these two aspects together using a model, two methods give some guidelines. Apart from the protocol cornerstone, all methods fully cover the e-business development framework. Some differences in emphasis of each method can be extracted. Both the business processes and the implementation have full attention in CADA and Select Perspective. Catalysis emphasises reuse of knowledge in the development process and communication between the analysts and system developers. COMET concentrates on the business process and reuse, while the RUP pays a lot of attention to system modelling. In general, modelling is important in a CBD process: each method uses several models.
11
5
FUTURE RESEARCH
Today, the importance of CBD is well recognised in both the industry and academic world. There is a common understanding of the tight connection between business and implementation. A de-facto standard for system modelling in CBD, especially using OO development platforms, is set: UML. However, we have to conclude that the core elements of CBD, components and reuse, are far from mature. The CBD methods available leave many questions to the user. What is a component exactly? How to distinguish a component? The range of tools for CBD shows gaps. The characteristics of a CBD process are not specified. A thorough CBD method is needed. Part of this method would be: • standard vocabulary; • characteristics of a component; • standard description of components; • univocal process; • explicit way of modelling; • industrial-strength development tools. The standard vocabulary improves communication between all parties involved in a CBD process. It consists of definitions of concepts such as component, framework and architecture. One of the enablers of CBD are characteristics of components. They enable us to develop or distinguish a component and to judge the completeness of a component. This issue is underexposed in the methods. Consequently, a thorough method for developing components is not provided. In order to identify characteristics, a bottom up approach should be followed: develop and evaluate components for a specific platform. With a collection of components, an attempt to specify characteristics can be done by generalising from their properties. As an extension of the characteristics, a standard description, such as a pattern, of a component can be defined. The description ensures that all relevant information about a component is recorded in a standardised way. This enables a developer to use components of unknown developers, their development tools and platforms. Additionally, the standard categories can be used for searching components. Tools can support this by providing functionality for storage and retrieval of components. One of the methods, Select Perspective, has reached this stage; Component Manager is part of its tool set. After having the preconditions for a component repository available, an unambiguous method is needed in order to use it. Today, a typical CBD method distinguishes activities in both the business and implementation process. The guidance during the process often leaves a lot of freedom to the user. Issues which should be addressed are for example developing components and assemble software from components. A crucial aspect in assembling is collaboration between components. Several scenarios are possible, for example collaboration by means of an interface, a framework or method invocations. This issue is barely covered in the methods investigated. Collaboration by means of interfaces is briefly mentioned three times, two methods do not discuss this at all. We consider this an important issue in successful CBD. Research on using components on the same platform and across platforms could give a start for a solution in these. Considering the amount of models proposed by the methods, modelling has full attention in CBD methods. Nevertheless, the relation between models often remains vague. In order to define which modelling languages, mappings between models and tools are needed, the typical CBD process should gain more detail. Is it for example possible to have more than one implementation of the same model? Currently, what lacks is a modelling language and tool for business modelling. All methods have proposed a proprietary technique for this. In conclusion, CBD still offers many research questions. In order to achieve assembling software from components downloaded from the Internet these have to be solved first. The Giga Transaction Services project, a project on e-business engineering, will research these issues. Acknowledgements The research for this paper has been conducted within the Giga Transaction Services project, under the GigaPort Programme [31]. We would like to thank the reviewers for their constructive remarks. 12
REFERENCES 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.
Segev, A. & Bichler, M. (2000). Component-based electronic commerce. In M.Shaw, R. Blanning, T. Strader, & A. Whinston (Eds.), Handbook on electronic commerce Springer-Verlag. Larsen, G. (2000). Component-based enterprise frameworks. Communications of the ACM, 43(10), 24-26. Sprott, D. & Wilkes, L. (1999). Component Based Development Using Componentised Software CBDi Forum. Technology Strategy Team (1998). InterEnterprise Process Engineering with Component-Based Development EC Cubed, Inc. Janssen, W. & Steen, M. W. A. (2000). Rapid service development: An integral approach to e-business engineering. In S.Murugesan & Y. Deshpande (Eds.), Web Engineering Springer-Verlag. Communications of the ACM, 43(10). (2000) IEEE Computer, 32 (07), (1999) IEEE Software, 15(5), (1998) Kruchten, P. (1999). Rational Unified Process: An Introduction. Addison-Wesley. D'Souza, D. F. & Wills, A. C. (1999). Objects, Components and Frameworks with UML: The Catalysis Approach. Addison-Wesley. Meijler, T.D. and Nierstrasz, O., (1997) Cooperative Information Systems: Current Trends and Directions, M.P. Papazoglou and G. Schlageter (Eds.), pp. 49-78, Beyond Objects: Components, Academic Press. REGINA Component Information System (2000). WWW [On-line]. Available: http://www.findcomponents.com/ Active-X.COM - Your ActiveX Component Library (2000). WWW [On-line]. Available: http://www.active-x.com/ Brinkkemper, S., (1990). Formalisation of Information System Modelling Thesis Publishers, The Netherlands. Hong,S., Goor, van den, Brinkkemper, S., (1993). A Formal Approach to the Comparison of Object-Oriented Analysis and th Design Methodologies, Proceedings of the 26 Hawaii International Conference on System Sciences, Vol. IV, pp. 689998. Lemmen, K., (1994). Het aanpakmodel: Methodology Engineering met het MADIS-raamwerk. Informatie Vol. 36, pp. 318-323. Stichting Nederlands Studiecentrum voor Administratieve Automatisering. Blank, J., M.J. Krijger (1983). Evaluation of methods and techniques for the analysis, design and implementation of information systems. Academic Service. Seligmann, P. S., Wijers, G. M., & Sol, H. G. (1989). Analysing the structure of I.S. methodologies: An alternative approach. In Proceedings of the First Dutch Conference on Information Systems Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design patterns: Elements of reusable object-oriented software. Addison-Wesley. Fielt, E., van den Eijkel, G., Janssen, W., Steen, M. W. A., & Oude Luttighuis, P. (2000). Rapid service development methodology (Rep. No. TI/RS/2000/030). Enschede: Telematica Instituut. Brinkkemper, S. (2000). Method Engineering with Web-enabled Methods. In S.Brinkkemper, E. Lindencrona, & A. Sølvberg (Eds.), Information systems engineering: state of the art and research themes (pp. 123-133). Springer-Verlag. Princeton Softech (2000). Select Perspective: Princeton Softech's practical methodology for delivering next-generation applications Princeton Softech. Solberg, A. & Berre, A.-J. (1997). Component based methodology handbook Norway: SINTEF. Hubbers, J. W. & Verhoef, D. (2000). Workshop component-based development. Ordina Institute for Research and Innovation. Component Based Rapid Service Development: state-of-the-art and definitions D1.3.4v2 https://extranet.telin.nl/docuserver/dscgi/ds.py/View/Collection-373 Bellin, D. & Simone, S. S. (1997). The CRC Card Book. Addison-Wesley. DSDM Consortium (2000). Dynamic Systems Development Method. DSDM Consortium [On-line]. Available: http://www.dsdm.org/ Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley. The Rational Unified Process (2000). [Computer software]. Rational Software Corp. Catalysis (2000). http://www.catalysis.org. Gigaport (2000). http://www.gigaport.nl.
13
