A Methodology Framework for Component-Based System Development Support Zoran Stojanovic1, Ajantha Dahanayake1, Henk Sol2 1
Department of Information Systems, Faculty of Information Technology and Systems, Delft University of Technology, Zuidplantsoen 4, 2628 BZ Delft, The Netherlands
[email protected],
[email protected] 2
Department of Information, Communication and Systems, Faculty of Technology, Policy and Management, Delft University of Technology, Jaffalaan 5, NL-2628 BX Delft, The Netherlands
[email protected]
Abstract. Components already represent a common solution for implementation and deployment of advanced enterprise distributed information systems. Now there is a strong need for providing effective CBD methodology support through appropriate component-based methods, tools and techniques that effectively target existing component technology. Current CBD methods and approaches do not provide a full support for various component concepts. They handle components mainly at the implementation and deployment phases still heavily influenced by the UML notation. This paper presents a methodology framework, which provides a full system development support in the component-oriented manner. First, the sample of CBD methods has been evaluated by the framework’s concepts and requirements. Based on the evaluation, the CBD method improvements have been proposed. The improved approach uses the standard RM-ODP as an underlying framework, providing a consistent, systematic, and integrated CBD methodology support throughout the lifecycle.
1. INTRODUCTION Today’s organisations are intensively looking for the way to effectively use advanced technology opportunities in conducting their business, under the constant pressure of ever-changing demands in the environment. There are many impact factors responsible for the current state of the enterprise world. The Internet has been established as the main actor of the new era of “digital economy”. There is a strong need for tighter integration of various types of information inside the enterprise, such as, business, geographical, and multimedia. Furthermore, new technological achievements in wireless communication provide unlimited mobility of users, information and applications. Finally, tight connection and mutual dependences between information technology (IT) and business worlds result in higher complexity and sensibility on changes of the new enterprise information systems. All these new technology, business and organisational challenges result in a growing interest in the research community and industry over component-based development (CBD) [Brown and Wallnau, 1998]. CBD provides organisations with a method for building enterprise-scale solutions that are flexible, manageable and able to accommodate the ever-changing demands in the environment in a cost-effective, timely manner [Butler Group, 1998]. By using CBD approach a system development becomes the selection, reconfiguration, adaptation, assembling and deployment of encapsulated, replaceable and reusable system elements called components, rather than building the system from scratch [Szyperski, 1998]. So far the CBD paradigm has been mainly introduced through the new technological solutions and distributed middleware infrastructures such as Microsoft’s Component Object Model (COM) [COM], Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) [Siegel, 2000] or Java-based tools [Java Beans]. While the technology is necessary element of any solution, it is not sufficient by its own. Methods, techniques and tools for developing component-oriented applications are equally important, targeting that technology at the final phase [Welke, 1994]. 1
Therefore, the main objective of this paper is to identify significant shortcomings of the current CBD methods and to present a first cut of the methodology framework for designing improved CBD methods. For this reason the paper is organised as follows: first an account of the current state of the CBD methods and approaches are given. The most prominent, established and well-documented CBD-methods are described and compared by the extent and nature of CBD support. Based on the analysis, a methodology framework for an advanced CBD support is defined, and the chosen sample of methods is evaluated accordingly using the framework. Finally, in order to fulfil the requirements, suggestions are made on how to improve the methodological support for component-based system development.
2. THE CURRENT STATE OF CBD METHODS CBD is not completely a new approach; rather it has evolved from the previous “divide-and-conquer” ideas and concepts in the computer science [Gartner Group, 1997; Szyperski, 1998]. Higher productivity, flexibility, and quality, through reusability, replaceability, efficient maintainability, scalability and parallel work are among the CBD claimed benefits [Butler Group, 1998; Allen and Frost, 1998]. Furthermore, components can be placed on any network node, depending on application needs and regardless of the type of particular network connection. The CBD paradigm is seen by many as an evolutionary step forward with regard to the OO paradigm, resulting in many similar concepts, principles and ideas. The “component vs. object” issue has become the focus of many discussions and studies, raising the question whether and/or to what extent object-orientation can provide the effective support for component-based system development [Szyperski, 1998; D’Souza and Wills, 1999].
2.1 CBD methods and approaches CBD technology solutions have already been settled in practice. At the same time methods and techniques are required for developing components and component-oriented applications. Even if an enterprise information system is being built using Commercial-Off-The-Shelf (COTS) components, still a proper methodological guidance is required in order to achieve a successful solution. Academia and industry have just started recognising the importance of new CBD methods and techniques, by introducing their approaches, best practices and experiences in following the CBD paradigm [Brown and Wallnau, 1998]. The area of the CBD methods is still immature but evolving, resulting in a common use of OO constructs and concepts in building component systems. But even the UML, a standard object-oriented modelling language, takes more technical perspective on components using available implementation diagrams (component and deployment) [OMG, 1999]. In order to gain the clamed CBD benefits, the comprehensive CBD strategy is needed. It should guide and structure the whole system development in the componentoriented manner. For the purpose of analysis and evaluation of the CBD methodology state-of-the-art, a sample of CBD methods have been selected. Only established, well-published methods, documented through books, web sites, companion papers, with the opportunities for training and consultancy have been selected. These methods have a clear structure covering the whole development lifecycle through the sequence (and/or iteration) of process steps. They have been already used in many practical projects and are supported by software development tools and environments. Selected methods are: the Rational’s Unified Process [Jacobson et al., 1999], the Select Perspective method [Allen and Frost, 1998] and the Catalysis approach [D’Souza and Wills, 1999]. However, several other CBD approaches and best practices have been proposed by research centers and IT-business industry during the last years such as Compuware’s Uniface [Uniface, 2000], the Scipio Consortium approach [Scipio, 1999], the KobrA approach [Atkinson, 2000], Castek CBD methodology [Castek, 2000], and the Andersen Consulting’s (now Accenture) approach [Ning, 1998]. Although these approaches are mainly well supported by appropriate toolset and used in some practical projects, they do not offer a clear and structured development process. They rather combine a best of breed OO and CBD concepts, elements and strategies in an ad-hoc manner, often combining and using concepts from the three 2
selected methods. Necessary steps in a development using these approaches are not firmly defined. Their support for the component concepts greatly varies in nature and extent. Therefore, these approaches are not suitable and representative for the purpose of CBD methods evaluation. At the time of conducting this research, the authors have not found other remarkable efforts in the area of CBD methods, especially not proposed by academics. Along with further evolving and maturing of these CBD methods, as well as appearing of new ones, they will be accordingly included in the evaluation and analysis. In the sequel, the RUP, Select Perspective and Catalysis will be further described and analysed. 2.1.1 Rational Unified Process Rational Unified Process (RUP) is a software engineering process developed by Rational Software. The RUP is the direct successor of the Rational Objectory Process (version 4), which was the result of integration of the Rational Approach and the Objectory process [Jacobson et al., 1992] in 1995. The RUP includes not only a system development then also management of the process. Regarding that it schedules work, provides guidance for a team’s activities, plans deliveries of artifacts, allocates resources, and monitors and measures the project’s progress [Booch, 1995]. The RUP is well documented through the number of books and companion papers. The method is supported by web-based searchable knowledge base (www.rational.com) providing all team members with guidelines, templates and tool mentors for all development activities. Training and consultancy opportunities are available. The process is supported by Rational tool family. The key concept of the RUP is the definition of activities (workflows) throughout the development lifecycle, such as requirements capturing, analysis, design, implementation, and testing. In architecting the solution, a support for the CBD approach is encouraged but heavily influenced and constrained by the UML notation. The RUP’s view on the component concept is still on the level of physical packages of programming code, based on the UML component and deployment diagrams. This is illustrated by the RUP’s definition of a component as “a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture”. RUP uses the UML concept of subsystems for the purpose of component modelling, but without detailed elaboration. The RUP does not specifically target at component-based development. It rather offers a general framework for object-oriented design and construction. Use of the UML as the basic modelling notation provides a great deal of flexibility in designing, but specific support for key component modelling concepts is lacking and limited to UML notations. Along with current improvements and extension of UML leading to the version 2.0, probably RUP will provide a more thorough and consistent CBD support. One of the main advantages of the RUP is providing an opportunity for iterative and incremental system development, seen nowadays as the best development practice.
2.1.2 Select Perspective Select Perspective was originally created in 1994-1995 by combining Rumbaugh’s Object Modelling Technique (OMT) [Rumbaugh, 1991] and Jacobson’s Use Case driven Objectory method [Jacobson et al., 1992] based on the RAD (Rapid Application Development) principles. Originally the Select supported only business modelling, use case modelling, class modelling, object interaction modelling and state modelling. After arising the interest and importance of the CBD paradigm, the method has been extended to provide business-oriented component modelling, component modelling of legacy assets, and deployment modelling. Select includes the integration of object-oriented technology with business modelling and data modelling, using the best of breed tools and techniques. The method is based on a service-based architecture adopted from the Microsoft Solution Framework (MSF) application model, with the following service categories: user services, business services and data services [Microsoft, 1996]. It is well documented by available book and companion reports. Training and consultancy support are available. The method is supported by the Component Factory tool family including Select Enterprise, Component Manager and Select Wrapping Tools.
3
In addition to the UML for object-oriented and component modelling, the Select Perspective method uses a notation adopted from the CSC Catalyst methodology [CSC, 1995] for business modelling, maintaining the link between business processes and associated use cases and classes. Furthermore, it uses EntityRelationship Diagrams (ERD) for data modelling and provides mapping between the UML diagrams and relational data models. The method handles the component concept by using the concept of package, defined in UML as “a general purpose mechanism for organising elements into groups” [OMG, 1999]. Two basic stereotypes of the package are distinguished: service package used in business-oriented component modelling and component package used in component and system implementation. A service package contains classes that have a high level of interdependency, and serve a common purpose by delivering a consistent set of services. A component package represents an executable component, i.e. actual code. When service package is placed to a node of the network modelled by the UML deployment diagram, the package effectively becomes a component package. Special attention in the method is paid to component modelling of the legacy assets, i.e. how to use the component principles to efficiently wrap and further use legacy systems. Similar to RUP, the Select method offers some process, task and team managerial facilities. Originally founded as an RAD approach, the Select Perspective method currently claims a support for iterative, incremental and parallel development. It defines phases for accomplishing a component-based project, namely Align, Architect and Assembly, as well as the core set of techniques known as LUCIDTM (Linkage to business, Use case model, Class model, Interaction Model and Data model, Develop, Test & Deploy) [Perspective, 2000].
2.1.3 Catalysis Catalysis is a component-oriented approach with its origins in object-oriented analysis and design methods. Catalysis began in 1991 as a formalisation of OMT [Rumbaugh, 1991]. It extends secondgeneration methods such as Fusion [Coleman et al., 1993] and Syntropy [Cook and Daniels, 1994], including a support for framework-based development and defining methodical refinements from abstract specification to implementation. The book written by D’Souza and Wills describes Catalysis in details [D’Souza and Wills, 1999]. There are a number of technical papers and presentations about Catalysis as well. Dedicated website (www.catalysis.org) offers on-line support for potential users of the method. Opportunities for training and consultancy are provided. Catalysis is supported by the COOL family of tools (COOL:Gen, COOL:Spex, COOL:Joe, etc.). Catalysis is a methodology for modeling and constructing open systems from objects, components and frameworks. It is mainly a development process, i.e. its main purpose is to provide software construction from high-level requirements. Although the details of Catalysis are complex, the approach itself is based on a few underlying concepts (types, conformance, collaborations and frameworks) used throughout the process. Catalysis approach to component development encourages a strong separation and independence of component specification from implementation using an extended form of UML. Although Catalysis covers the complete system lifecycle, “from business to code”, the support of the component concept is rather at the implementation level. The method defines a component as a “coherent package of software artifacts that can be independently developed and delivered as a unit and that can be composed, unchanged, with other components to build something larger”. Higher-level CBD support is provided through the concept of type, as a stereotype of a class, and collaborations among those types. Type is defined as the representation of a consistent behaviour in the domain, while the class is an implementation of the type. External behaviour of the type is defined by its interface, which is mapped to class operations. Larger-grained development concept in Catalysis is package, as the basic unit of development product, which can be separately created, maintained, delivered, updated, assigned to a team, and generally managed as a unit. Catalysis uses concepts of abstraction, refinements, and frameworks in order to achieve an iterative, nonlinear and parallel process with necessary quality assurance. Catalysis is not a rigorous methodology; it is rather a semi-structured set of design principles, advices and patterns throughout the system lifecycle.
4
Therefore, a systematic “roadmap” of the Catalysis way is still lacking. The whole method tends to be vague, with possible difficulties of applying it in practice.
2.2 Summary of the methods The range and variety of CBD support, provided by the presented methods, are shown in the Table 1.
Used Notation
UML
Component
Mostly physical view
Select Perspective Book, Web-site, Consultancy, Training Development + management Select Component Factory (Select Enterprise, Component Manager, etc.) BPM (Catalyst), UML, ERD Mostly physical view
Component Modelling Component Implementation Incremental and Iterative Complexity
UML subsystem
Service package
Availability
Type of process Tool Support
RUP Book, Web site, Consultancy, Training Development + management Rational product family (Rational Rose, etc.)
UML Component and Component package, Deployment diagram Deployment diagram Yes Yes Middle-level of details, well structured using UML
Catalysis Book, Web site, Consultancy, Training Mostly development COOL product family (COOL: Spex, COOL:Gen, etc.) UML Logical + physical view Stereotype type Package, Technical components Yes
Middle-level of details, Highly-detailed, without a sequence of techniques systematic roadmap
Table 1. Variety of CBD support in presented methods.
3. CBD METHODOLOGY FRAMEWORK Information system development is a complex process, which needs a solid and sound foundation as guidance. It contains a coherent set of activities and techniques that can be used to organise, perform and improve a development process. In the sequel we will present the framework based on the necessary concepts and requirements for effective component-based development process support.
3.1 Framework foundation As the underlying idea in performing analysis of CBD method requirements, we use the analytical framework defined in [Sol, 1988] which pays explicit attention to all important aspects of the process. This framework defines a set of concepts and views that characterise the information systems development process: a way of thinking, modelling, working, controlling and supporting (Figure 1). It is crucial that a development method provides the necessary support for all aspects of this framework: - Way of thinking – visualises the essential philosophy of an information systems development method regarding the information systems functionality and role in the environment. - Way of modelling – a means for structuring problems by distinguishing between types of models required for problem specification and solution finding. - Way of controlling – includes a set of directives and guidelines on managing the information systems development process, on management of time, means, and quality aspects. 5
-
Way of working – is seen as a means for structuring problems by distinguishing between types of tasks to be performed for systems development process. Way of supporting – represents the tools that support information systems development process. Way of thinking
Way of controlling
Way of modelling
Way of working
Way of supporting Figure 1. The framework for understanding information system development. For the full advantage of CBD, the nature and structure of the whole development process, i.e. all its aspects presented above, have to be aligned with the component concept. This means that an entirely new development methods and tools are required, much closely aligned with CBD principles. In order to provide a consistent and comprehensive CBD methodology support, the presented framework will be used in the sequel. Through presented separation of concerns, the framework will help in identifying the necessary requirements and characteristics of an advanced CBD method inside each of the presented viewpoints.
3.1.1 Way of thinking The underlying philosophy of the method should focus on: • Component as the main focus of a development process; - The component concept should be the focus and main artifact of a development process, used consistently throughout the system lifecycle. • Clear, consistent, and technology-independent component definition; - Among the other important characteristics and benefits of the CBD approach claimed so far, the component concept represents an excellent solution for providing a meeting point between technology and business worlds. A component as an encapsulated concept clearly defined and delimited from the environment, with specific roles and behaviour in a domain, with hidden interior and exposed services through interfaces, can be easily understood by both worlds. Such concept gives business analysts and managers greater ability to model business processes and requirements at a higher-level, in a domainspecific, but implementation-independent way. On the other hand, the application developers retain control over how their models are turned into complete applications using advanced component-based technology. • Components as means for integrating business requirements and systems information; - Object-orientation cannot be effectively used for the purpose of Business-IT alignment. Objects can be too small in size and technologically oriented to be considered as basic units of a development process by business side. The logic is usually too trivial to justify the expense of modelling, building, documenting and reusing a single object interface. On the other hand, business processes are often too fuzzy and complex to be uniformly and easily understood by IT side. They must be partitioned into constituent, semantically separated business patterns or building blocks in order to be efficiently handled by application developers. Furthermore, components as behaviour-oriented concepts, handled 6
through services they offer in the context of information they represent, are more natural approach for describing complex business processes than objects as mainly entity-based structures. Thus, a component can represent a lingua franca for business and IT worlds, i.e. a means for integrating instead of separating them.
3.1.2 Way of working In order to achieve consistent understanding and use of a component, we need a clear and universal definition of the component concept, understood from many different perspectives, by different participants in enterprise system development process. According to that the CBD method must match the following: • Full component lifecycle; - To provide activities of component discovering, identification, modelling, specification, implementation and assembling, which actually covers a full component lifecycle. • Traceable component concept; - To make a component concept traceable and consistent throughout the system development lifecycle, i.e. each phase in the component lifecycle would transfer the concepts to the corresponding development process phase. • Integration of views; - To integrate multiple views and perspectives on the component (e.g. specification vs. implementation components, business vs. technical components, entity vs. process components). • Iterative and incremental development; - The concept of a component and component-based development efficiently support new, advanced and currently the most prominent paradigm in system development, namely iterative and incremental development. It has been introduced as a promising effort in providing the best trade-off between the time-to-market and quality issues, making the step further from the Rapid Application Development (RAD) and Waterfall Process. CBD supports quite naturally such an approach, by partitioning the complex problem area into constituent parts, and defining possible phases, increments and opportunities for parallel work inside a development process. A rigorous, repeatable refinement process through all presented component-based lifecycle phases should be provided. It results in that the final software solution meets original business requirements through easily traceable pathway.
3.1.3 Way of modelling In the context of the way of modelling and accordingly the ways of thinking and working, the proper CBD method should include the following characteristics and functionality: • Component modelling concepts and notation; - To provide component modelling concepts, such as specification component, component interface, interface type, specification type, collaborations, etc. so far realised through UML extension mechanisms (stereotypes, tagged values, pre- and post-conditions). A proper textual and/or graphical notation for representation must be provided and uniquely understood by all actors in the development process. • Acquisition of business requirements using components; - Business requirements should be analysed in terms of possible semantical and logical fragmentation and separation of concerns inside a business domain area. It results in component-oriented requirements capturing as a mechanism for early structuring the whole development process in the CBD manner. • Component-oriented business modelling; - Business concepts, i.e. entities, processes, rules and events should be considered through the definition of different concepts, activities, behaviours and constraints in the business domain, as a source for component-oriented, interface-focused structuring of the domain. • From business modelling to system modelling using components; - To provide a component transition from business modelling to system analysis and design, so that it should be used for further structuring of business and system artifacts, their relationships and activities, 7
•
•
•
•
as possible components of the system. It can be achieved through performing component-oriented use case modelling using the notion of use case components [Jacobson et al., 1997]. Some components are the system representations of particular technical or business concepts, while the others are the representations of involved human actors in the term of necessary user interface, database tables, etc. Behaviour in the domain represented by component interfaces; - Behaviour of the concepts inside the domain area should be analysed in terms of component interfaces, so that the system can be modelled as a collection of interacting components, representing the well-defined, self-contained concepts and their collaboration. The result of this process is a detailed interface-driven analysis (or behaviour-driven) of what each component must do, without stating how that behaviour will be implemented. Specification vs. implementation independence; - Component specification should be defined independently of the implementation, making that one component specification can be implemented using many possible implementations. Component specification should specify the component behaviour, while component implementation should implement it. Rigor component specification; - A precise, formal or semi-formal notation should be available for describing component specification, sufficient for rigorous analysis of this specification against user’s needs. Such rigor specification should represent a contract between the component provider and component consumer upon which they should agree, as well as the main information support in browsing COTS catalogs. Precise component specification should be sufficient and straightforward for easy and effective component implementation. Reusability of modelling artifacts; - Single component or a whole pattern of component interactions can be explicitly modelled, stored in the repository and subsequently reused across the further system design. In that way the model not only the code, can become a reusable artifact.
3.1.4 Way of controlling A set of guidelines for the management of the CBD process should be included. • Proper CBD process management approach; - To provide a management facilities within the CBD process by managing time, means and quality aspects in the component-oriented manner. In that way the control points in each of CBD process phases should be defined and used for checking component artifacts during the process on particular quantity and quality parameters.
3.1.5 Way of supporting A set of tools that support information systems development process should be provided. • Effective Tool Support; - Component-based development process must be well supported by an appropriate toolset through the each phase of the system lifecycle. A family of tools should be provided and systematically integrated, where each tool should cover a single aspect or part of the development process. The tool support must be sufficiently flexible to adopt eventual changes of the particular method, and even to provide an integrated support for the whole spectrum of CBD development methods [Dahanayake, 1997].
3.2 Analytical Framework-based Evaluation of CBD Methods A summary of the evaluation of CBD methods RUP, Select Perspective and Catalysis, based on the requirements framework for consistent CBD methodology support is presented in the Table 2. The CBD methods have been evaluated through selected set of criteria using authors’ knowledge and experience gathered through available literature about the methods. Further step will be to provide advanced evaluation criteria by interviewing users of the methods. 8
RUP Component as the main focus of a development process Clear, consistent and technology-independent component definition Components as means for integrating business requirements and systems information Full component lifecycle Traceable component concept Integration of views Iterative and incremental development Component modelling concepts and notation Acquisition of business requirements using components Component-oriented business modelling Business modelling to system modelling using components Behaviour in the domain represented by component interfaces Specification vs. implementation independence Rigor component specification Reusability of modelling artifacts Proper process management approach Effective Tool Support
X
Select Perspective
Catalysis
X X
X
X X
X
X
X X X X
X
X
Table 2. Framework-based evaluation of the CBD methods (X indicates matching; blank indicates not enough evidence of matching). Based on the evaluation the following can be concluded: further efforts need to be invested in bringing the component concept consistently along the component development lifecycle. The consistent, universal definition of the component is needed, making this concept traceable and consistent throughout the development process. Accordingly, proper component modelling concepts and notations are needed for making easy and effective development through iterations and increments. It is evident from the above analysis that a more formal and systematic approach for component-based development is required, covering the whole system lifecycle, and integrating CBD concepts and principles into each phase. In such an approach, integration between phases, through business, information, application and technology issues should be provided, and a component concept should be a correspondence point among them. This should be provided using general well-grounded component theory, representing the bridge between different perspectives and viewpoints. A consistent CBD way of thinking and terminology should be ensured throughout the lifecycle. It should provide an integration of different views, concepts and perspectives as well as a smooth transition among them. The framework for effective CBD methodology support presented in Section 3 can be seen as a first step towards the arriving at truly component-oriented development methodology. Using the framework, we aim to improve CBD methodology support by proposing a new systematic and integrated approach to component-based development.
4. CBD METHOD IMPROVEMENTS In our approach we intend to use the ISO Reference Model of Open Distributed Processing (RM-ODP) [ODP, 1996] as an underlying framework and to integrate the component concept consistently into it. RMODP is a joint standardisation effort of the ISO (International Standardisation Organisation) and ITU-T (International Telecommunication Union). RM-ODP originally consists of four parts, namely Overview, Foundations, Architecture and Architecture Semantics. RM-ODP defines a framework for specifying architectures for distribution, interoperability and portability of applications based on object-oriented 9
technology. The specification of the system by RM-ODP consists of five different specifications, corresponding to five different, but related and consistent viewpoints: Enterprise, Information, Computational, Engineering and Technology, Figure 2.
Figure 2. RM-ODP Viewpoints. The approach provides the seamless integration of the component concept consistently into each of the five ODP specification viewpoints, using the concepts, constructs and definitions from the Part 2, named Foundations, of the standard, Figure 3. These concepts are sufficient for defining clear and precise component semantics in all phases and aspects of the enterprise system development.
Figure 3. An integrated CBD approach Since the component middleware models and infrastructures, like OMG/CORBA, are already widely accepted and used, the ODP Engineering and Technology Viewpoint Specifications can be based on them. In the case of CORBA, these specifications can be defined consistently with CORBA ORBs and IDL, CORBA services and CORBA common facilities [Siegel, 2000]. Further aim is to incorporate CBD concepts and principles into the other ODP viewpoints, first to Enterprise Viewpoint, and then to Information and Computational Viewpoints. In that way, the component concept, handled from different perspectives, is the common correspondence point and unified factor across all ODP viewpoints, Figure 3. Although the ODP viewpoints do not have to correspond to the phases of system development lifecycle, the viewpoint definitions reflect possible relations. For each development phase several (if not all) of the viewpoints can be used, but with corresponding emphasis and level of details. For example, in [Raymond, 1995] Enterprise Viewpoint is related to requirements analysis, Information and Computational Viewpoints to functional specification, Engineering Viewpoint to design, and Technology Viewpoint to implementation. 10
By focusing on a seamless integration of CBD concepts into the RM-ODP viewpoints, a comprehensive component-based specification and development framework for building complex enterprise systems, in a systematic and consistent way, from requirements capturing to implementation, can be provided. Standard concepts and constructs of the RM-ODP foundations can be used for defining clear component semantics inside the ODP framework, throughout all five viewpoints. The standard UML can be used as a modelling notation, since there already exist studies about appropriateness of using UML in specifying RM-ODP concepts and constructs [Hasall et al., 1999]. By following semantically separate but consistent tracks defined by component-oriented ODP viewpoints, the approach enables an integrated view from different perspectives on the building blocks of the system. The viewpoint specifications evolve coordinately through time, resulting in that an overall specification can be used as a firm base for future system development. Using RM-ODP framework as a standard base results in applying CBD principles, from enterprise concepts and requirements to implementation and deployment, in a rigorous and consistent manner. This ensures that the concepts and requirements defined by the methodology framework presented in the Section 3 are fully satisfied. In that way, the full benefit of the CBD paradigm in system development can be achieved. Details about the approach can be found in [Stojanovic et al., 2000].
5. CONCLUSION Components are already a reality at the implementation level [Szyperski, 1998], and now the concept must be founded at the earlier phases of the development lifecycle. Doing so, CBD principles and concepts should be consistently applied through the whole development process, and consistently followed from one phase to the other. Current CBD methods and approaches, such as the Rational Unified Process, the Select Perspective and the Catalysis approach, do not include the full support for the concept of a component. It results in the fact that components are handled mainly at the implementation and deployment phase, instead of being focal point through the complete system lifecycle. The methods are significantly influenced by their OO origins, while trying to introduce the CBD concepts mainly through the use of standard UML concepts and notation. The framework for effective CBD methodology support is introduced in Section 3 as a first step towards the arriving at truly component-oriented systems development methodology engineering. The framework is based on the five aspects of the system development process, namely way of thinking, modelling, working, controlling and supporting, and each of them must be truly component-oriented. Sample of the CBD methods have been evaluated using the concepts and requirements of the methodology framework. Current research covers only three well-documented and established CBD methods. As soon as the other approaches not presented here become sufficiently mature, the methodology framework will be extended to provide their analysis and evaluation as well. The CBD methods have been evaluated using authors’ knowledge and experience gathered through available literature. The next step will be to provide new advanced evaluation criteria by interviewing users of the methods. The evaluation of the methods as well as the methodology framework used for that purpose have initiated us to propose possible improvements in the CBD methodology practice. We suggest using standard Reference Model of Open Distributed Processing (RM-ODP) as an underlying framework for constructing consistent, systematic and comprehensive CBD methodology support. It has been done by seamless integration of the component concepts into each of the five RM-ODP viewpoints (enterprise, information, computational, engineering and technology), making the whole system lifecycle, from business requirements to implementation, truly component-oriented. REFERENCES Allen, P., Frost, S. (1998), “Component-Based Development for Enterprise Systems: Applying the Select Perspective”, Cambridge University Press. Atkinson, C., et al. (2000), “Component-Based Software Engineering: The KobrA Approach”, 3rd International Workshop on Component-based Software Engineering, Limerick, Ireland. Booch, G., (1995), “Object Solutions – Managing the Object-Oriented Project”, Reading, MA: AddisonWesley, 1995. 11
Brown, A.W., Wallnau K.C. (1998), “The Current State of Component-Based Software Engineering”, IEEE Software, September/October 1998. Butler Group (1998), “ Component-Based Development”, Management Guide, Researched by D. Sprott and L. Wilkes, available at http://www.butlergroup.com Castek (2000), “Component-based Development: The Concepts, Technology and Methodology”, Castek company’s white paper, available at http://www.castek.com Coleman, D., et al. (1993), “Object-Oriented Development: The Fusion Method”, Prentice Hall, 1993. COM, DCOM, MTS, ActiveX, COM+, information available at http://www.microsoft.com/com/
Cook S. and Daniels J. (1994), “Designing Object Systems: Object-Oriented Modelling with Syntropy”, Englewood Cliffs, N.J.: Prentice Hall. CSC (1995), Catalyst Methodology (Internal Document) Computer Sciences Corporation. Dahanayake, A.N.W. (1997), “ An Environment to Support Flexible Information systems Modeling”, PhD Thesis, Delft University of Technology, the Netherlands. D’Souza, D.F. and Wills, A.C. (1999), “Objects, Components, and Frameworks with UML: the Catalysis Approach”, Addison-Wesley. Gartner Group (1997): “Componentware: Categorization and Cataloging,” Applications Development and Management Strategies Research Note, by K. Loureiro and M. Blechar, December 5, 1997, http://www.gartnergroup.com. Hassall, J., Eaton, J., Gray, G., Wilcock, M. (1999) “Applying ISO RM-ODP and UML in the Specification of Standard Interfaces to General Ledger Systems”, available at http://www.compassgl.org/ Jacobson, I., et al. (1992), “Object-Oriented Software Engineering – A Use Case-Driven approach”, Reading, MA: Addison-Wesley, 1992. Jacobson I., Booch G., Rumbaugh J. (1999), “The unified software development process”, Reading MA : Addison-Wesley. Jacobson, I., Griss, M., Jonsson, P. (1997), “Software Reuse – Architecture, Process and Organisation for Business Success”, ACM Press, Addison-Wesley Longman. JavaBeans, The source for JavaTM technology at http://java.sun.com Microsoft Corporation (1996), “Microsoft solutions framework: Reference guide, version 2.0”, available at http://www.microsoft.com/ Ning, J.Q. (1998), “CBSE Research at Andersen Consulting”, Proceedings of the First International Workshop on Component-Based Software Engineering, April 1998, Kyoto, Japan. ODP (1996), International Standard Organisation (ISO), Information technology - Open Distributed Processing - Reference model: Overview, Foundations, Architecture and Architecture semantics, ISO/IEC JTC1/SC07, 10746-1/4, ITU-T Recommendations X.901/904. OMG (1999) Object Management Group: Unified Modeling Language 1.3 specification, document ad/9906-09. Available at http://www.omg.org/uml/ Raymond, K. (1995) “Reference Model of Open Distributed Processing (RM-ODP): Introduction. Proc. of the 3rd IFIP TC6/WG6.1 International Conference on Open Distributed Processing, Brisbane (Australia), February 20–24, 3-14. Rumbaugh, J., et al. (1991), “Object-Oriented Modeling and Design”, Prentice Hall, 1991. Perspective (2000), “Select Perspective: Princeton Softech’s practical methodology for delivering nextgeneration applications”, Princeton Softech, http://www. princetonsoftech.com/ Scipio (1999), Scipio Consortium, Scipio Method, http:///www.scipio.org Siegel, J. (2000), “CORBA 3: Fundamentals and Programming” OMG Press, John Wiley & Sons, Inc. Sol, H.G. (1988), “Information System Development: A Problem Solving Approach”, in Proc.of 1988 INTEC Symposium Systems Analysis and Design: A Research Strategy, Atlanta, Georgia. Stojanovic, Z., Dahanayake, A.N.W., Sol, H.G., “Integrated Component-Based Framework for Effective and Flexible Telematics Application Development”, Technical report, ISBN: 90-76412-13-8, Delft University of Technology, November 2000. Szyperski, C. (1998), “Component Software: Beyond Object-Oriented Programming”, ACM Press, Addison-Wesley. Uniface (2000), Compuware Corp., Uniface products, http://www.compuware.com/products/uniface/ Welke, R.J. (1994), “The Shifting Software Development Paradigm”, Data Base, Vol. 25, No.4 (November, 1994), pp. 9-16.
12
