A Method for Component-Based and Service-Oriented Software Systems Engineering

Citation preview

---

A Method for Component-Based and Service-Oriented Software Systems Engineering

Zoran Stojanović

A Method for Component-Based and Service-Oriented Software Systems Engineering

PROEFSCHRIFT

ter verkrijging van de graad van doctor, aan de Technische Universiteit Delft, op gezag van de Rector Magnificus Prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties, in het openbaar te verdedigen op dinsdag 22 februari 2005 om 15:30 uur

door

Zoran STOJANOVIĆ diploma engineer en magister computer science van de Universiteit van Niš, Servië en Montenegro geboren te Niš, Servië en Montenegro

Dit proefschrift is goedgekeurd door de promotor: Prof. dr. H.G. Sol

Toegevoegd promotor: Dr. A.N.W. Dahanayake

Samenstelling promotiecommissie: Rector Magnificus, voorzitter Prof. dr. H.G. Sol, Technische Universiteit Delft, promotor Dr. A.N.W. Dahanayake, Technische Universiteit Delft, toegevoegd promotor Prof. dr. ir. A. Verbraeck, University of Maryland, USA Prof. dr. R. Welke, Georgia State University, USA Prof. dr. R.W. Wagenaar, Technische Universiteit Delft Prof. dr. ir. P.J.M. van Oosterom, Technische Universiteit Delft

To my parents To Nada

Published and distributed by: Zoran Stojanović Oostblok 144 2612 PG Delft The Netherlands Phone: +31 (0) 6 2850 2188 Email: [email protected]

Delft University of Technology Faculty of Technology, Policy and Management Jaffalaan 5 2628 BX Delft, The Netherlands Phone: +31 (0)15 278 8380 Fax: +31 (0)15 278 3429

English editor: Miranda Aldham-Breary Printing: Febodruk BV- www.febodruk.nl, Enschede/Utrecht Cover picture: © AV Bros, www.avbros.com

Zoran Stojanović A Method for Component-Based and Service-Oriented Software Systems Engineering Doctoral Dissertation, Delft University of Technology, The Netherlands ISBN: 90-9019100-3

Keywords: Component-Based Development, Model-Driven Architecture, Service-Oriented Software Engineering

Copyright © 2005 by Zoran Stojanović All rights reserved. No parts of this publication may be reproduced, stored in a retrieval system, or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the written permission of the author.

Contents Preface ........................................................................................................................ xi 1 Components and Services ....................................................................................... 1 1.1 Background and Motivation ........................................................................................ 1 1.1.1 Managing Complexity and Changes........................................................................ 1 1.1.2 Methodology Needs................................................................................................. 5 1.2 Research Objective and Questions .............................................................................. 7 1.3 Research Approach..................................................................................................... 12 1.3.1 Research philosophy.............................................................................................. 12 1.3.2 Research strategy................................................................................................... 13 1.3.3 Research instruments............................................................................................. 15 1.4 Thesis Outline .............................................................................................................. 16

2 The State-of-the-Art of Component-Based Software Systems Development ... 19 2.1 The Roots of CBD........................................................................................................ 19 2.2 Component Basics ....................................................................................................... 21 2.2.1 Component Definitions ......................................................................................... 21 2.2.2 Components and Objects....................................................................................... 23 2.2.3 Component Interface ............................................................................................. 25 2.2.4 Components and Architecture ............................................................................... 26 2.3 Technology Standards for CBD ................................................................................. 29 2.3.1 Microsoft Component Model ................................................................................ 29 2.3.2 Enterprise Java Beans Component Model (EJB)................................................... 30 2.3.3 CORBA Component Model (CCM)...................................................................... 31 2.3.4 Summary of Implementation Models .................................................................... 32 2.4 Component-Based Development Methods and Approaches.................................... 33 2.4.1 Rational Unified Process ....................................................................................... 33 2.4.2 Select Perspective.................................................................................................. 34 2.4.3 Catalysis ................................................................................................................ 35 2.4.4 KobrA.................................................................................................................... 36 2.4.5 UML Components ................................................................................................. 37 2.4.6 Business Component Factory ................................................................................ 38 2.4.7 Summary of the Methods ...................................................................................... 39 2.5 Components and Web Services .................................................................................. 40 2.6 Model-Driven Development and Agile Development ............................................... 43 2.6.1 Model-Driven Architecture ................................................................................... 43 2.6.2 Agile Development................................................................................................ 44 2.6.3 Model-driven vs. Agile Development ................................................................... 45 2.7 New Developments in Component Modeling ............................................................ 46

2.7.1 EDOC Profile ........................................................................................................ 46 2.7.2 UML 2.0 ................................................................................................................ 47 2.8 State-of-the-Art Survey Findings............................................................................... 49 2.8.1 Analysis of the CBD Methods............................................................................... 50 2.8.1.1 The Way of Thinking...................................................................................... 51 2.8.1.2 The Way of Modeling..................................................................................... 54 2.8.1.3 The Way of Working ...................................................................................... 56 2.8.1.4 The Way of Controlling ................................................................................. 59 2.9 CBD Method Requirements ....................................................................................... 60 2.9.1 Basic Method Requirements.................................................................................. 60 2.9.2 Requirements for Component-Orientation ............................................................ 61 2.9.3 Evaluation of CBD methods.................................................................................. 62 2.9.4 Evaluation Findings............................................................................................... 64 2.9.5 Conclusion............................................................................................................. 66

3 Component-Based Development in Practice ....................................................... 67 3.1 Airport Business .......................................................................................................... 67 3.1.1 Airport Strategic Exploration ................................................................................ 67 3.1.2 A Support for Airport Strategic Planning.............................................................. 69 3.2 The Airport Business Suite......................................................................................... 70 3.2.1 The System Structure ............................................................................................ 70 3.2.2 Prototype Implementation ..................................................................................... 71 3.3 Design and Implementation of the ABS .................................................................... 72 3.3.1 The Basic Component Architecture of the ABS.................................................... 72 3.3.2 Decomposition of the Main Model Components................................................... 73 3.3.3 Implementation of the ABS Components.............................................................. 75 3.3.4 The Role of the Researcher ................................................................................... 76 3.4 The Role of CBD in the ABS Project ......................................................................... 77 3.4.1 System Flexibility and Adaptability ...................................................................... 77 3.4.2 Project Team Organization.................................................................................... 78 3.4.3 Iterative and Incremental Development................................................................. 79 3.5 Lessons Learned Practicing CBD .............................................................................. 80 3.5.1 The ABS Component-Based Approach................................................................. 80 3.5.2 Evaluation of the ABS component-based development approach......................... 82 3.5.3 Evaluation Findings and Conclusions ................................................................... 83

4 Component Concepts and Definitions ................................................................. 87 4.1 Basic Component Concepts ........................................................................................ 87 4.1.1 Components and Composition............................................................................... 88 4.1.2 Component Essentials ........................................................................................... 89 4.1.3 Different Views on Components ........................................................................... 92 4.2 Component Specification............................................................................................ 94

4.2.1 Context Viewpoint Specification........................................................................... 94 4.2.2 Behavior Viewpoint Specification......................................................................... 95 4.2.3 Information Viewpoint Specification .................................................................... 97 4.2.4 Realization Viewpoint Specification ..................................................................... 97 4.2.5 Component Specification vs. Interface.................................................................. 99 4.3 Components in the Development Lifecycle ............................................................... 99 4.3.1 Coupling and Cohesion ......................................................................................... 99 4.3.2 Component Facets ............................................................................................... 100 4.3.3 Component Granularity and Types...................................................................... 102 4.3.4 Component Reusability and Replaceability......................................................... 104 4.4 Representing Web Services Using Component Concepts ...................................... 105 4.5 Discussion and Conclusion ....................................................................................... 107

5 Component Modeling Techniques and Notations............................................. 111 5.1 Modeling Components Using UML ......................................................................... 112 5.1.1 Modeling Basic Component Concepts ................................................................ 112 5.1.2 Component Context in UML............................................................................... 115 5.1.3 Component Behavior in UML............................................................................. 116 5.1.4 Component Information in UML ........................................................................ 119 5.1.5 Component Implementation in UML .................................................................. 121 5.1.6 Component Stereotypes....................................................................................... 122 5.1.7 Component Package ............................................................................................ 123 5.1.8 Modeling Component Collaboration ................................................................... 124 5.1.9 Alternative Component Modeling ....................................................................... 126 5.2 Textual Representation of Components .................................................................. 127 5.2.1 Component Modeling using IDL......................................................................... 127 5.2.2 A Component Definition Language to extend IDL ............................................. 129 5.2.3 Related Work....................................................................................................... 131 5.2.4 Concluding Remarks ........................................................................................... 133 5.3 Machine-Readable Representation of Components ............................................... 134 5.4 Summary.................................................................................................................... 140

6 Component-Oriented Architecture Design and Implementation.................... 143 6.1 Method Requirements............................................................................................... 143 6.2 Related Work............................................................................................................. 145 6.3 An Overview of the Method ..................................................................................... 149 6.4 Business Domain Model............................................................................................ 154 6.5. Business Component Model .................................................................................... 157 6.5.1 Business Requirements Analysis......................................................................... 157 6.5.2 Identifying Business Components ....................................................................... 159 6.5.2.1 Existing Approaches for Identifying Components ....................................... 159 6.5.2.2 A Procedure for Identyfing Business Components ...................................... 159

6.5.2.3 Comparison and Discussion ........................................................................ 163 6.5.3 Specifying Business Components ....................................................................... 165 6.6 Application Component Model ................................................................................ 166 6.7 Component Refactoring............................................................................................ 170 6.8 Implementation Component Model......................................................................... 173 6.9 Model Packages and Tool Support .......................................................................... 177 6.10 Summary.................................................................................................................. 178

7 Test and Evaluation of the Method.................................................................... 183 7.1 Usability of the Method............................................................................................. 183 7.1.1 An Introduction to the Sample System................................................................ 184 7.1.2 Business Component Model................................................................................ 187 7.1.3 Application Component Model ........................................................................... 195 7.1.4 Implementation Component Model..................................................................... 197 7.2 Users’ Evaluation of the Method ............................................................................. 197 7.2.1 Case Study........................................................................................................... 198 7.2.2 Survey Settings.................................................................................................... 199 7.2.3 Survey Questionnaires......................................................................................... 200 7.2.4 Survey Summary ................................................................................................. 205 7.3 Added Value of the Method...................................................................................... 205 7.3.1 Methods comparison ........................................................................................... 205 7.3.2 Impact of the Method .......................................................................................... 208 7.4 Summary.................................................................................................................... 212

8 Epilogue ................................................................................................................ 213 8.1 Research Findings ..................................................................................................... 213 8.1.1 Research Context................................................................................................. 213 8.1.2 Main Contributions.............................................................................................. 216 8.1.2.1 Research Question One ............................................................................... 216 8.1.2.2 Research Question Two ............................................................................... 219 8.1.2.3 Research Question Three............................................................................. 220 8.1.3 Reflection on the Research Approach ................................................................. 222 8.2 Further Research ...................................................................................................... 223

References ............................................................................................................... 227 Appendix A UML 2.0 Modeling Notation .......................................................... 239 Appendix B Survey Questionnaire...................................................................... 241 Appendix C List of Abbreviations ...................................................................... 247 Summary ................................................................................................................. 249 Samenvatting........................................................................................................... 253 Biography ................................................................................................................ 257

Preface The sea is dangerous and its storms terrible, but these obstacles have never been sufficient reason to remain ashore…unlike the mediocre, intrepid spirits seek victory over those things that seem impossible…it is with an iron will that they embark on the most daring of all endeavors…to meet the shadowy future, without fear and conquer the unknown. Ferdinand Magellan, explorer (circa 1520)

Information technology (IT) and systems have become the backbone of modern enterprises and they provide a wealth of new opportunities for conducting business. The ability of an enterprise to manage the complexity of its information systems and to adapt rapidly to business changes has been widely recognized as a crucial factor for business success. Therefore, an effective approach for building system solutions that support business goals and strategic decisions, and that can be easily adapted to meet business changes represents an essential business knowledge asset. There is a growing consensus in the business/IT community that the way to create these adaptive, and potentially complex, IT systems is through components and services – discrete units of business functionality that collaborate over contract-based interfaces using standard protocols and platforms. During the last few years, component-based development (CBD) and Web services (WS) have been widely used for building flexible enterprise-scale systems and providing effective interand intra-enterprise application integration. While the technology and implementation standards for CBD and WS have already been established in practice, further efforts are necessary to design methods and techniques for engineering these complex computing systems, from business requirements to software implementation. To gain the full benefit of these new development paradigms, improvements in technology must be followed by improvements in the development process. Therefore, a more formal and well-defined system development strategy that includes a set of consistent concepts, a proper modeling notation, guidelines, techniques and tools is required as an essential part of IT development within an enterprise. A method for software systems engineering following component-based and service-oriented concepts, principles and practices is designed and presented in this thesis. A set of consistent and technology-independent component concepts is defined in the method, together with the types, facets and granularity levels of components in the context of the development process lifecycle. The component concepts are modeled throughout the development process, depending on the reason for the modeling and specification, using techniques and notations based on Unified Modeling Language (UML) 2.0, Interface Definition Language (IDL) and eXtensible Markup Language (XML), enriched with extensions where necessary. The method further provides pragmatic guidelines, techniques and milestones that use the defined concepts and notations to facilitate a stepwise development process in a component-based and serviceoriented manner. The method prescribes which activities should be carried out within each

step of the development process and provides guidelines to develop appropriate models. We believe that our method is general, flexible and scalable enough to be used in componentbased architectural design and development for a wide range of IT systems, from small-scale desktop applications to complex, Internet-based, enterprise-scale IT systems. Many people have helped me to conduct the research presented in this thesis and to achieve a number of scientific and professional objectives. First, I would like to thank Henk Sol for supervising and supporting this research. He provided me with unconditional freedom to perform this research in a most approachable way for me and made many valuable comments and suggestions that helped to keep me on track. Second, many thanks to Ajantha Dahanayake for fruitful lengthy discussions, valuable input, and profound support, while conducting the research and during the writing process of a number of joint publications. I had the pleasure to work with many nice, stimulating colleagues at Delft University of Technology. Many thanks to Jeroen Lorist, Amr Ali Eldin, Tamrat Tewoldeberhan, Semir Daskapan, Boris Shishkov and Corné Versteegt for being wonderful friends and for the constructive discussions we had about research and about “outside” life. Many thanks to all the members of the Systems Engineering group for being pleasant colleagues and for supporting me in various ways during the research. Thanks are also due to Miranda AldhamBreary who helped me to improve my English. I would like to thank the people involved in the BETADE research project for sharing ideas and giving valuable input and support, and for the enjoyable time spent together attempting to answer the question: “What are building blocks?” I want to thank the people involved in my case studies for helping me to achieve my research goals, namely the members of the ABS project and the employees of Geodan BV. Perhaps the most difficult thing in doing a PhD is that most of the time the researcher works alone. However, when I was not working I was glad I had the support of many good friends, with whom I have shared the common memories, common strategies to deal with the difficulties of living in a foreign country and common dreams about living a better life far away from our homelands. Thank you my friends for many enjoyable moments spent together and for making me feel at home. Last, but certainly not least, I would like to express my deepest gratitude to my parents, Hranislav and Dragica for all their love, support, care, sacrifice, dedication and efforts during my whole life to get me to where I am now. Unfortunately, my father passed away recently and did not get to see this thesis completed, but I know that he would have been very proud of me. I dedicate this book to the memory of my father. Further, I owe many thanks to my brothers, Ivan and Dragan, who have constantly been with me although thousands miles away. Finally, my deepest thanks go to my beloved wife Nada, for all her love, care, understanding, patience and support during this important and difficult period of our lives. Zoran Stojanović Delft, January 2005

1 Components and Services Modern enterprises are caught in the flux of rapid and often unpredictable changes in business and Information Technology (IT). New business demands caused by the need of an enterprise to be competitive in its market require the immediate support of advanced IT solutions. At the same time, new IT opportunities and achievements are constantly emerging and must be rapidly adopted to support new and more effective ways of conducting business. Therefore, it is crucial to provide a way to achieve effective business-IT alignment in terms of producing high quality and flexible IT solutions within a short time-to-market that satisfy complex business functionality needs and change as business changes (Butler Group, 2003).

1.1 Background and Motivation 1.1.1 Managing Complexity and Changes Enterprise IT systems are, by their very nature, large and complex. Many of them have evolved over years as a way to combine legacy assets, third-party software packages, outsourced applications and newly built functionality, with all these parts possibly running on different computing resources. Due to their complex and often monolithic structure, these systems can be very difficult to test and understand, which can result in low-reliability and a long development lifecycle. Moreover, if one part of the system needs to be upgraded, this often affects the system as a whole causing changes to propagate throughout the system in an unpredictable manner (Szyperski, 1998; Sprott and Wilkes, 1999). There is the risk that businesses may become dependent on IT system infrastructures that are complex to manage and that cannot evolve at the pace required to support changing business goals (Veryard, 2001). Therefore, the ability to manage the complexity of IT systems used to support business and to adapt rapidly to changes in business and IT has been widely recognized as a crucial factor in the modern business and IT world (Brown and Wallnau, 1998; Gartner Group, 1998). During the last years, there has been a growing consensus that, to manage complexity and changes effectively in today’s agile business world, complex IT systems need to be built as a set of discrete building blocks of functionality that can be integrated to form a meaningful, dedicated whole to provide specific support for particular business functions (Heineman and Councill, 2001; Crnkovic and Larsson, 2002). This strategy of separation of concerns, of divide-and-

1

Chapter 1 conquer and plug-and-play used in building IT systems is not new. It has been the goal of the information systems engineering community since the beginning of software development, largely motivated by similar strategies that have been successfully applied in other complex systems engineering disciplines. It is believed that modularization results in a shortened time to market, lower production costs, more evolvable systems and systems of a higher quality (Szyperski, 1998). It was recognized at the 1968 NATO Conference that producing software systems, due to the increasing system complexity, should be treated as an engineering discipline (McIlroy, 1968). Parnas (1972) introduced various concepts and requirements for decomposing system into modules. Since then, a number of development paradigms related to building software systems from parts have been proposed, using the concepts of functions, subroutines, modules, units, packages, subsystems, objects, and components. Parallel to applying the modularization strategy in system development, attempts have been made to define these building blocks of a system at a higher-level of abstraction, i.e. larger grained and semantically closer to the problem owner. As one of the founders of Unified Modeling Language (UML) Booch remarked in his presentation The Limits of Software, “the entire history of software engineering is that of the rise in levels of abstraction” (Booch, 2002). The new levels of abstraction allow us to deal with greater levels of software complexity and help us to bridge the gap between the users and developers of the system, i.e. between the outside view of the system and how it is actually implemented. The object-orientation (OO) paradigm, based on ideas first introduced in the late 1960s by creating the Simula language (Dahl, Myhrhaug and Nygaard, 1968), has become well established as a cornerstone of IT development defining new programming languages (Smalltalk, C++, Java, etc.) and development methods (Booch, 1986; Rumbaugh, Blaha, Premerlani, Eddy, and Lorenson, 1991; Jacobson, Christerson, Jonsson, and Overgaard, 1992; Cook and Daniels, 1994). One of the main characteristics of the OO paradigm is that, for the first time, the business user and the software developer have a means to achieve a common abstraction in terms of an object that associates functionality with data, represents a real-world entity and constitutes the main building block of a software system (Booch, 1986). However, IT practice has shown that it is difficult to manage the complexity of large projects using purely OO techniques (Udell, 1994; Szyperski, 1998; Whitehead, 2002). Applying the OO approach can lead to too many objects/classes with fine granularity and numerous associations among them. Objects are tightly coupled and wired together which results in complex systems with monolithic structures, which are difficult to change, evolve and adapt (Nierstrasz, 1995; D’Souza and Wills, 1999). Recently, Component-Based Development (CBD) has been introduced as a solution for building complex and adaptive enterprise IT systems in the Internet era (Welke, 1994; Brown and Wallnau, 1998; Szyperski, 1998; Crnkovic and Larsson, 2002). Using the CBD paradigm, system development becomes the selection, reconfiguration, adaptation, assembling and deployment of encapsulated, replaceable, interoperable system elements with clear functionality and hidden implementation, rather than building the whole system from scratch 2

Components and Services (Brown, 2000; Clements, 2000). One of the primary aims of CBD is to deal with the increasing complexity and size of business applications (Allen and Frost, 1998; Allen, 2000). Moreover, using CBD helps us to manage changes better as it can be used effectively to localize changes inside single components and prevent the uncontrolled propagation of changes throughout the system (Cheesman and Daniels, 2000; Veryard, 2001). Other potential benefits of following the CBD paradigm in system development, often cited in the literature from the field, are outlined below (Heineman and Councill, 2001; Crnkovic and Larsson, 2002). Using components to develop IT systems reduces development costs as it supports reuse of existing, developed and pre-tested components. In addition, reuse of existing components increases productivity, since system development teams do not have to start building new applications from scratch. A component can be replaced with an improved version or another component as long as the provided functionality is the same. Building with components also reduces maintenance costs. Since components are encapsulated, it is possible to make changes to their implementation without affecting all the systems that rely on them. A component approach also allows system developers to reuse existing knowledge in the form of its legacy software assets, which are often still written in COBOL, thus supporting the continued use of software that represents considerable past investments for a business. Encapsulating such legacy applications and turning them into components allows them to be integrated with new components to accommodate a broader range of business process variability and evolution. Using CBD helps system developers to build higher quality systems since the components that are used have already been pre-tested and certified in prior projects. CBD offers the possibility for parallel work during development projects as different components can be built by different project groups working simultaneously. Finally, CBD provides better system scalability in a way that a system made of components can easily grow in size by adding new components or replacing existing ones with components offering a wider set of responsibilities. In summary, using components allows us to address the core issues and challenges in modern system development in several important ways: using components delivers complex applications that are designed to be adaptable to business and technology changes; their use increases productivity and speed of delivery, without loss of quality; and, components enables the integration of legacy assets with modern approaches, which protects previous investments (Sprott and Wilkes, 1999; Allen, 2000). The Gartner Group predicted in 1998 that, by the year of 2004, ICT organizations that have matured in CBD methods and that have a large inventory of business components will have the potential to be five to ten times more productive and responsive to changes than those that do not. The main concepts and benefits of the CBD approach are shown in the Figure 1.1. The elements of the figure with the arrows pointed at the “CBD oval” represent the main concepts and characteristics that drive CBD. The elements with the arrows pointed away from the oval represent the main benefits of introducing CBD in an enterprise.

3

Chapter 1

Figure 1.1 Concepts and benefits of CBD (adopted from Sprott and Wilkes, 1999) It is not just important to design and develop the individual components that provide the services we need. It is just as important to provide a suitable mechanism to integrate them into a meaningful whole to realize higher-level business functionality. Any strategy for separation of concerns into particular components must also provide mechanisms for seamless, consistent and meaningful integration of these components, to quote Jackson (1990) “having divided to conquer, we must reunite to rule”. During the last few years, we have witnessed the further evolution of the component way of thinking in the form of Web services (Newcomer, 2002; Kaye, 2003; Apperly et al., 2003). These have been introduced as a promising way to integrate information systems effectively inside and across the enterprises. Web services can be generally defined as loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols (W3C, 2004). From a technical perspective Web services are essentially extended and enhanced component interface constructs. The basic elements of the new service-oriented paradigm are the standards for interoperability - XML, SOAP, WSDL and UDDI, which provide platformindependent communication for software resources across the Internet. On top of this basic interoperability protocol stack, new languages and specifications for defining the composition of services to form real-world business processes have emerged, such as Business Process Execution Language for Web Services (BPEL4WS) (BPEL, 2003) and Web Service Choreography Interface (WSCI) (WSCI, 2002). Using this advanced technology, the Internet, once solely a repository of various kinds of information, is now evolving into a provider of a variety of business services and applications. This idea of a software application as a service was recognized in the past (e.g. Brown, 2000), but it can now be fully realized using the Web services technology for systems interoperability 4

Components and Services (Newcomer, 2002). Web services are organized in a Service-Oriented Architecture (SOA) that represents an approach to distributed computing that considers software resources as services available on the network (Kaye, 2003). Similar initiatives have been proposed in the past, such as CORBA (Zahavi, 2000; Siegel, 2000) or Microsoft’s DCOM (Sessions, 1998). What is new about SOA is that it relies upon universally accepted standards like XML and SOAP to provide broad interoperability among different vendors’ solutions. Using SOA, the level of abstraction is further raised, so that the main building blocks are now real world business activities encapsulating the services that offer business value to the user (Kaye, 2003). It is important to make a clear distinction between service-oriented thinking and service-oriented technology. SOA represents the service way of thinking where a business domain is organized into modular services providing business-level functionality that are provided, consumed, brokered and orchestrated into more complex services. The CBD and Web services technology and standards are just the way to implement SOA, i.e. the way to bring the service thinking into practice. 1.1.2 Methodology Needs A common point for both CBD and Web services, as it has been the case with each development paradigm proposed so far, is that they are technology-led, i.e. they were first introduced through new technology standards, infrastructures and tools, and only then were new methods, techniques and processes proposed to target this technology in the final phase (Heineman and Councill, 2001; Crnkovic and Larsson, 2002). Although technology is essential in building complex IT solutions from components and services, it cannot be sufficient on its own to support the full extent of business and IT requirements. One cannot simply implement and deploy components and services using an advanced component middleware infrastructure without any prior plan to follow from business requirements to implementation (Brown, 2000; Whitehead, 2002). As using component middleware technology does not ensure that one will achieve the promised benefits of CBD, conversely, the CBD paradigm can be successfully employed without using this technology (Szyperski, 1998). A similar issue now arises in the case of Web services. As there is more to CBD than packaging software into Java Beans or .NET components, there is more to service-orientation than simply rendering interfaces of e.g. programming objects as Web services (Apperly et al., 2003; Kaye, 2003). Furthermore, the set of technologies and standards available for CBD and Web services is complex and constantly evolving. This can cause problems whenever new versions of interoperability protocols or technology infrastructure appear. Moreover, all of these technologies are low level, based on XML or J2EE and .NET platforms. Developing systems directly using these technologies is tedious, complex and error prone (Szyperski, 1998; Cheesman and Daniels, 2000). At the same time, by using only pure technology, the system development activities are largely separated from the business user’s point of view. This can result in the risk that a developed system does not really reflect business needs, and this may be recognized quite late in the project lifecycle (Allen 2000; Williams, 2000). As the

5

Chapter 1 Butler Group suggests in their report Application Development Strategies, technology and tools are rarely to blame for the high incidence of IT project failures (Butler Group, 2003). Improvements in technology must be followed with improvements in the process of development. The Butler Group believes that a formal, documented, application development strategy, including selection of appropriate processes, methodologies and tools, is an essential part of the overall process of IT governance. The real challenge lies not just in new technology per se, but also in how best to make use of the available technology using systems engineering methods and techniques (Frankel, 2003). A software development method can be defined as a regular and systematic way of conducting the analysis and design portion of a software development process (Wallnau, Hissam and Seacord, 2001), or as a standard that describes the characteristics of the orderly process or procedure used in the engineering of a product or performing a service (IEEE standard, http://www.ieee.org). Therefore, as pointed out by Herzum and Sims (2000), Atkinson et al. (2002), Crnkovic and Larsson (2002) and Apperly et al. (2003), one of the biggest challenges facing component-based and service-oriented development is the lack of a methodology for building complex Web-enabled systems using the notion of components and services. Due to the complexity of their computing models, the need for a development method in the context of CBD and Web services is even more important than for traditional software development (Heineman and Councill, 2001; Kaye, 2003). Applying well-defined development methods and techniques ensures that a development project does not end up with a random collection of unusable, although technologically feasible, components and services (D’Souza and Wills, 1999; Herzum and Sims, 2000; Allen, 2000;). While it is relatively straightforward to break down an application into components such as buttons and dialogue boxes to build a graphical user interface, building a distributed, multi-tier application where core components must interoperate over the Internet requires effort, investment and a design of a totally different order (Heineman and Councill, 2001; Atkinson et al., 2002). Applying a well-defined method within a disciplined development process can help us to gain the full benefits of the CBD and service-orientation paradigms given above (Apperly et al., 2003). For example, a method allows us to reuse models, specifications and designs and not just to reuse software code. As Sommerville (2000) states, the potential gains from reusing abstract products of the development process, such as specifications and designs, may be greater than those to be obtained from reusing code components, since they are more abstract than low-level software code and hence more widely applicable. Furthermore, a CBD method can help us to develop systems to a higher-level of abstraction which will make the development process more productive, flexible and understandable for business people who define the system requirements, use the solutions and who decide future strategies, while the developers handle the tedious details of low-level technologies (Herzum and Sims, 2000; Atkinson et al., 2002). The set of component constructs, made in the way a business analyst sees an application being developed, can be gradually mapped to the low-level software constructs in a way dictated by the method and practiced through the development process (Frankel, 2003). This 6

Components and Services transformation of high-level business models to logical system specification and then to a technology infrastructure of choice, potentially automated by an advanced tool, is the main idea behind the current trend in system development proposed by the Object Management Group (OMG) in the form of Model-Driven Architecture (MDA) (OMG-MDA, 2004).

1.2 Research Objective and Questions While application functionality is routinely packaged into components and services today, the essential component-based and service-oriented development methods that enable application adaptability, widespread reuse and commercialization still have little acceptance (Heineman and Councill, 2001; Whitehead, 2002). The IT community has just recently started to recognize the importance of new CBD methods, processes, and techniques such as Catalysis (D’Souza and Wills, 1999), Select Perspective (Allen and Frost, 1998) and Rational Unified Process (Booch, Rumbaugh and Jacobson, 1999). The way these methods handle component concepts is significantly influenced by their object-oriented origins (Crnkovic and Larsson, 2002; Dahanayake, Sol and Stojanović, 2003). The methods inherit difficulties in recognizing the fundamental nature of components and consider the componentization aspects as ways of code packaging (Eeles and Sims, 1998; Szyperski, 1998). Typical component definitions that consider a component purely as an implementation artifact are given by the UML 1.3 standard (OMG-UML 1.3, 1999), where components are defined through physical component diagrams, and the Gartner Group (1998). ♦ A component is a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces (UML 1.3 standard). ♦ A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group). A consistent view on the component concept beyond the pure technology perspective has been largely missing (D’Souza and Wills, 1999; Atkinson et al., 2002). The numerous definitions of a component that have been proposed so far show clearly that everybody sees components differently. A clear distinction between components and concepts such as objects/classes, packages, subsystems and modules, has yet to be made (Heineman and Councill, 2001). Treating components as software packaging units at the end of the development lifecycle while still following traditional object-oriented analysis and design has created a gap between detailed software design performed using OO concepts and implementation using software components. This has given rise to a need to define a strategy for packaging a hierarchy of OO classes/objects into cohesive implementation units, i.e. components. Various approaches for solving this have been proposed, based on different ways of measuring the cohesiveness between objects that should be deployed into the same implementation component (Ambler, 2001; Larman, 2001; Jain, Chalimeda, Ivaturi and Reddy, 2001). Furthermore, by using 7

Chapter 1 components as implementation artifacts only, software engineers focus their reuse efforts on the implementation level, where technology changes rapidly and standards are only just emerging. As a consequence of this way of thinking, the significance of the component mindset as a paradigm shift in system development, and the potential of the component concept to provide a common ground between business and technology concerns, have not yet been truly recognized (Allen, 2000). Moreover, a way to express the design of software components in an implementation-neutral fashion, a level above the latest language fashion, is missing and strongly required (Kaye, 2003). A newer generation of CBD methods and approaches proposed recently have started to define components as units of business functionality under the name of business components. However, object-orientation has still a strong influence on defining these business components, making them rather similar to old-fashion business objects (Eeles and Sims, 1998). These methods typically define a business component as a representation and implementation of a business concept that is relatively autonomous in the problem space (Herzum and Sims, 2000). Components are often identified based on underlying business entities, such as Order, Customer or Account (Cheesman and Daniels, 2000). Such components are too fine-grained and entity-oriented to be used effectively in the design and development of complex, Web-based and service-oriented applications (Apperly et al., 2003). Due to the recent increase of interest in, and the importance of, the new paradigm of Web services in inter-enterprise collaboration and integration as a further evolution of component thinking, there is a strong need for a method that provides mechanisms and techniques for modeling and designing Web services and service-oriented architecture (Apperly et al., 2003; Stojanović, Dahanayake and Sol, 2004a). Related to this, the method should support the design decisions about what part of the application can be exposed as a marketable, valueadded Web service, or what part of the system architecture can be realized by invoking a Web service from the service provider (Kaye, 2003). Current CBD methods do not provide necessary support for modeling and designing SOA (Apperly et al., 2003). These methods define components based on underlying business entities and, therefore, do not posses a sufficient expressive power to define the concept and behavior of the services that operate across these entities. Exposing the interface of a business entity object as a Web service using the interoperability protocols can easily cause a communication overhead due to finegranularity of the exposed service and its potentially high coupling with the rest of the system. Furthermore, exposing interfaces of business objects as Web services does not necessarily mean that one designs a SOA, where the main elements are larger-grained loosely coupled business added value services that are at a higher level of abstraction and granularity than OO objects (Kaye, 2003). Therefore, a paradigm shift from components as objects to components as service managers should be defined, making the method capable of modeling the system architecture that represents a contract-based collaboration of components and services (Stojanović, Dahanayake and Sol, 2004a). Components defined in a behavior-driven and service-oriented manner are able to provide a straightforward mapping of business processes 8

Components and Services into the service-oriented system architecture, where the collaboration of services provided by components represents the core of the system (Allen, 2000; Apperly et al., 2003). New developments in the field of software engineering, such as Model-Driven Architecture (MDA), UML 2.0 (OMG-UML2, 2004) and the UML for profile for Enterprise Distributed Object Computing (EDOC) (OMG-UML4EDOC, 2004) have recently emerged. MDA shows the power, and importance, of modeling and specifies the possibility of transformations (even automated) between the models at different levels of abstraction. MDA defines the possibility to create high-level business models and then perform successive model transformation and final code generations that gives the software code, or a great part of it. The UML for EDOC and the new major revision of UML, version 2.0, define new ways of component thinking and component modeling. Unlike UML 1.x, they define components as larger design units that will typically be implemented using software modules. However, the concept of service is still not defined as a first-class citizen within these modeling frameworks. It is worth noting that, although UML 2.0 and UML for EDOC bring a lot of definitions and modeling techniques specifying components and related concepts, they do not define stepwise guidelines, methods and techniques for using components within the development process, i.e. they define the way of thinking and the way of modeling, but not the way of working, and in that sense they are method-independent. The full benefit of the component and service way of thinking can be achieved only if the component and service concepts are integrated into each of the phases of a development process in a formal and systematic way (Herzum and Sims, 2000; Atkinson et al., 2002; Butler Group, 2003). Components providing services that support business processes and goals need to be identified and defined early in the development process, then successively modeled and specified in the analysis and design phase, and finally implemented using available component implementation technology (Frankel, 2003). Such truly component- and service-oriented process would maximize the benefits of component and service thinking throughout the process in terms of more adaptable and maintainable system architecture and usefulness of advanced component and Web service technology to implement that architecture. Therefore, the main challenge lies in creating component-based and service-oriented MDA models at different levels of abstraction that help us to map business requirements into software implementation. A method built upon this basis, as its main vocabulary, should provide precise and consistent definitions of various aspects of components in a development process. These aspects are: essential component concepts, concepts related to component specification, different forms and facets of components throughout the lifecycle, from conceptualization to implementation, different granularity and abstraction levels of components within the development process, and properties of components such as cohesion, coupling, reusability and replaceability. In relation to this, a method should provide an effective means for modeling and specifying given artifacts within the process, at the conceptual and specification level using a graphical 9

Chapter 1 modeling technique, at the level that is a step above programming languages using e.g. a textual pseudo-code, and at the machine-readable level that is the basis for communication among computer systems. Finally, a method should define a set of guidelines, techniques and steps to integrate the concepts and modeling techniques into a meaningful whole and place them in the context of a development process that will be used to guide the project from business requirements to software implementation and deployment. Taking the discussion presented above into consideration, the main objective of our research is formulated as follows: To design a method for component-based and service-oriented software systems engineering that supports components and services during the whole system development lifecycle, from business requirements to implementation. While designing the method, we take into account the methodology framework defined by Sol (1990), which pays explicit attention to all the important aspects of a development methodology. Sol’s framework defines a set of essential factors that characterizes an information systems development method and classifies them into a way of thinking, way of modeling, way of working, and a way of controlling, Figure 1.2. The way of thinking of the method provides an abstract description of the underlying concepts together with their interrelationships and properties. The way of modeling of the method structures the models, which can be used in the information system development, i.e. it provides a set of techniques and an abstract language in which to express the models. The way of working of the method organizes the way in which an information system is developed. It defines the possible tasks, including sub-tasks and ordering of tasks, to be performed as part of the development process. It furthermore provides guidelines on how these tasks should be performed. The way of controlling of the method deals specifies management aspects of the development process in terms of the management of resources, actor roles, intermediate and final results, etc.

Figure 1.2 Methodology framework for information systems development The research questions that we addressed to achieve our research objective were inspired by the methodology framework given above. Each research question corresponds to one of the 10

Components and Services main elements of the development method; the first research question deals with the way of thinking of the method, the second deals with the way of modeling of the method, and the third deals with the way of working of the method and partly with the way of controlling of the method. The research questions are defined as follows. 1. How can a technology-independent and coherent set of component concepts be defined to address various aspects of components throughout the development process? 2. What modeling techniques and notations can be used to express the component concepts in a clear and understandable way to all stakeholders involved in the development process? 3. How can the procedures, techniques, steps and rules of a method be defined to guide the development process, from business requirements to software implementation, using the defined component concepts and modeling techniques and notations? The research should result in a method that provides a well-defined and technologyindependent component-based and service-oriented design of IT systems that support and realize business processes and goals. The systems are designed and realized as a collaboration of components that offer services at different levels of granularity and abstraction. The method should enable the precise specification of system architecture, as a set of contract-based components and their collaboration, to be mapped into a platform-specific implementation using the technology of choice (Frankel, 2003). The method takes into account that not all components of a system can be or will be implemented in-house. They can be outsourced, bought as Commercial-Off-The-Shelf (COTS) components, made by encapsulating legacy assets, or invoked as Web services over the Internet. Applying the method should result in well-specified components that reflect business needs and that are, at the same time, based on technology reality, which is an essential factor in providing cost effective management of business and technology changes (Allen, 2000; Apperly et al., 2003). Today, a componentbased representation of a business domain is becoming a great metaphor for business people who are considering how they want to develop their business models in terms of collaborating chunks of business functionality as a way to provide necessary business agility (Veryard, 2001; IBM, 2004). The method we propose should ensure that this separation of concerns, starting at the business level, is mapped appropriately into loosely coupled well-specified and, further, well-implemented components and services, to provide effective business-IT alignment. Potential users of the research results are all the actors in the development process, including business analysts, system architects and software developers. Using the set of defined component concepts, modeling notation and guidelines for transforming business requirements into software artifacts, they can jointly overhaul IT systems used to support a business. In this way, they can simplify the IT architecture, making it more flexible, cost11

Chapter 1 effective and responsive to business changes, and bridge the gap between IT and business, which is the problem that often causes the poor business value returns on investments in advanced IT. Much of the support provided by the component-based method to the functional architect can be equally useful to the business analyst, especially as a way to partition and help master modeling complexities. In this sense, the component-based method could better connect the world of business analysts with the world of system architects, thereby providing effective business/IT alignment. At the same time, software developers retain control over how system models are turned into complete applications using advanced component-based technology infrastructure, which is transparent for business analysts, but well controlled by system architects.

1.3 Research Approach The research approach of a scientific inquiry may be defined as following a certain research strategy in which a set of research instruments are employed to collect and analyze data on the phenomenon studied, guided by a certain research philosophy. In the following sections we discuss the research philosophy, strategy, and instruments that we applied to address our research questions and pursue the research objective described in the previous section. The research approach was chosen based on characteristics of the research objective, research questions and existing body of knowledge. 1.3.1 Research philosophy A research philosophy underlines the way in which the data on the phenomenon studied is collected and analyzed. In general terms, a research philosophy is seen to determine the way a study is guided epistemologically. It determines what kind of knowledge can be obtained and what the limits are of that knowledge. The following research philosophies or “schools of thought” can be distinguished for research on information systems (Galliers, 1992). Positivists generally assume that reality is objectively given and can be described using measurable properties, which are independent of the observer (researcher) and his or her instruments. Positivist studies generally attempt to test theory in an attempt to increase the predictive understanding of phenomena. In line with this, Orlikowski and Baroudi (1991) classify information systems research as positivist if there is evidence of formal propositions, quantifiable measures of variables, hypothesis testing, and the drawing of inferences about a phenomenon from the sample to a stated population. Most of the studies carried out according to this philosophy are aimed at theory testing and make use of deductive reasoning and quantitative research instruments. More recently, an increased awareness of the complexity of the information systems issues has prompted the research community to accept interpretivism as a valid approach to research. Interpretivists, sometimes called anti-positivists, claim that reality can only be understood by

12

Components and Services subjectively interpreting observations of reality. While pointing out that multiple interpretations of reality are possible, they emphasize human interpretation and understanding as constituents of scientific knowledge. Interpretative methods of research in information systems are “aimed at producing and understanding of the context of the information system, and the process whereby the information system influences and is influenced by the context” (Walsham, 1993). Most of the studies carried out according to this philosophy are aimed at building theory and make use of inductive reasoning and qualitative research instruments. Both schools have been used as the basis of studies in information systems research, however, according to Orlikowski and Baroudi (1991), 96.8% of research in the leading American information system journals follows the positivist tradition. The preference for a certain philosophy guides the choice of research instruments. Positivist research instruments often include laboratory experiments, field experiments and forecasting. Interpretivist researchers make more use of action research, descriptive/interpretive research and grounded theory. Several research instruments and techniques can be applied within either a positivist or an interpretivist context. These instruments include field studies, surveys and case studies (Clarke, 2000). Different instruments have their strengths and weaknesses (Galliers, 1992). One should look for a combination of instruments to counterbalance their respective weaknesses and strengths. Several authors (Yin, 1994; Hirscheim, 1992) refer to this observation as the pluralistic view on science. A pluralistic view on science was adopted as the research philosophy in this research, as the strengths and perspectives of both positivist and interpretivist philosophies and related research instruments have been used in various aspects of the research. 1.3.2 Research strategy A research strategy is required to ensure that the necessary steps are carried out to execute an inquiry into the phenomenon studied. Such strategy is used to outline the sequence of data acquisition and analysis. The choice of a research strategy is based on the nature of the research problem, and on the status of theory development in the research field. The research strategy we followed in conducting this research is the inductive-hypothetic research strategy (Sol, 1982). This strategy is based on the expansion of scientific knowledge by adapting it endlessly and inductively in a multidisciplinary manner based on new observations (Galliers, 1992). The main characteristics of the inductive-hypothetic research strategy we used here are the following (Sol, 1982). ♦ It emphasizes the activities of conceptualization and problem specification, underlying specification and testing of premises in an inductive way. ♦ It enables the generation of various solutions, starting, if possible, with an analysis of the existing situation. ♦ It permits feedback and learning and enables evaluation of ideas. ♦ It is very useful when there is a lack of usable theory or methodological support.

13

Chapter 1 These characteristics make the inductive-hypothetic research strategy very applicable for emerging research fields such as a component-based design and development methodology, which has been has been of interest only for last several years. Furthermore, the literature covering CBD and information systems development methodologies is rather overwhelming, but not always relevant for this research. It is difficult, if not impossible to solve the problem of improving component-based and service-oriented methodology theory and practice in a purely deductive way. An inductive research strategy seems to be most appropriate. This is reinforced by the fact that the fields of CBD, MDA and Web services have recently emerged and are still evolving, so that a well-grounded and solid theory is not yet available. Given the lack of available well-established theory in the research field, the only way to formulate a theory is to identify the requirements for a component-based development method using available literature, further refine and justify them in practice and use this combined knowledge to form a theory. This can be facilitated by an inductive approach. The central notion of the inductive-hypothetical strategy is a shift during the research from a description of problems to the prescription of an alternate approach to solve these problems. The inductive-hypothetical strategy consists of five steps in which four types of models are constructed, as illustrated in Figure 1.3.

Figure 1.3 The inductive-hypothetic research strategy A number of initial theories are defined and used to investigate a set of empirical situations in the first step. Attention should be paid to characteristics, heuristics, and the problems encountered. This step ends with the construction of descriptive empirical models providing a detailed insight into, and a better understanding of, the problem area. A descriptive conceptual model is then constructed by abstracting from the empirical models in the second step. This model is used to represent the essential and generic elements of the problem area under investigation and gives indications for possible solutions. A theory is constructed to solve some of the previously observed problems in the third step. Based on the conceptual description, one or more solutions for the problems encountered are designed in the form of a prescriptive conceptual model. This model is still an abstraction of the specific area of

14

Components and Services interests, but explicitly defines how to address the perceived problems. The prescriptive conceptual model is implemented in a number of practical situations in the fourth step. The result of this step is a set of alternatives that provide solutions for the originally identified problems and is presented in prescriptive empirical models. The results of the prescriptive empirical situation are evaluated in the fifth step. Additional improvements or changes to the prescriptive conceptual model may be identified. The inductively expanded theory can be used as initial theory in empirical situations to start a new cycle. 1.3.3 Research instruments Various research instruments can be applied within the three main phases of the inductive research study. We started with a review of existing literature also called a meta-analysis to get the initial starting points for our research. A comprehensive review and analysis of past research/developments can lead to new ideas and insights and can ensure that subsequent research is built on past achievements. Significant advances in our knowledge, and our ability to develop theory, can be made through such an in-depth review of the problem domain (Galliers, 1992). The subjective/argumentative conceptual research was performed parallel to the literature survey. This type of research involves creative information systems research based more on opinion and speculation than observation (Vogel and Wetherbe, 1984). It comprises argumentative/dialectic and philosophical analysis. This creative research process can make a valuable contribution to the building of theories, which can subsequently be tested by more formal means. Its main strengths lie in the creation of new ideas and insights, while its weaknesses result from its less-structured and subjective nature (Galliers, 1992). Drawing on the literature research and argumentative conceptual research, we decided to gain a deeper understanding of the problem domain and better identify shortcomings of the previously proposed solutions using other research instruments, namely case studies. Case study research can be characterized as qualitative and observatory, using predefined research questions (Yin, 1994). In the case study research process, the researcher goes through the phases of design, collection, analysis and report. The choice of a case study is often based on opportunism, rather than on rational grounds (Yin, 1994). An important issue for the design of our research concerns the number of case studies to be used. Single case studies are often seen as inferior to multiple case studies with respect to generality; however, when selected with care, a limited number of case studies, or even a single case study, may be very successful in terms of theory formulation and theory testing (Yin, 1994). We used literature research to compare our findings, to sharpen emergent ideas from case studies, and to gain a better understanding and explanation of the results of the case studies. Theory development was based on an inductive case study, literature research and argumentative research. The inductive case study that was performed had the characteristics of action research. While case study research pays explicit attention to ‘why?’ and ‘how?’ 15

Chapter 1 questions, action research or applied case study research is focused on ‘how to?’ questions (Checkland, 1981; Meel, 1994; Galliers, 1992). Instead of taking the observer point of view, the researcher actively participated in the case study project and got involved in theory application, prototype implementation and testing. After the theory development, and in addition to the test case study, a literature comparison was done to find more support for our findings. Parallel to that, surveys were carried out among experts in the field on a quantitative and qualitative basis. This was used to gather written and verbal data from the potential users to evaluate the level of their satisfaction with the component-based and service-oriented design and development method proposed in this research.

1.4 Thesis Outline The outline of the thesis is given in this section in a descriptive and graphical form shown in Figure 1.4. In this first chapter we describe the background, scope, relevance and motivation of the research performed. The research objective and questions, and research strategy and instruments to achieve the objective and address the questions are presented. The state-of-the-art of component-based and service-oriented systems engineering is presented in chapter two. Existing concepts, development standards, technology infrastructure, and development methods are presented and critically evaluated. Weaknesses and shortcomings of the current achievements in the field are identified and conclusions are derived about how to improve the current theory and practice of systems engineering based on components and services. The chapter results in the set of requirements that is the basis of the creation of our component-based and service-oriented method. An inductive case study about the design and development of an airport business suite, in which the researcher participated actively, is introduced in the third chapter. This case study helps to strengthen the formulation of the research objective and questions, to provide a deeper insight into the problem domain from the practical point of view, and to justify the set of method requirements introduced in the previous chapter. The way of thinking of the method, in the form of the set of cohesive, consistent, and technology-independent component concepts, is defined in chapter four. Different viewpoints in component specification, different component facets throughout the development lifecycle and different granularity levels, from coarse-grained enterprise components to fine-grained program components are addressed in this chapter. The way of modeling of the method in the form of various modeling techniques and notations that can be used to express the component concepts is presented in chapter five. Several modeling paradigms are presented that vary in purpose, scope and the type of expressions, textual or graphical. The modeling constructs that are delineated are able to represent the component concepts given in chapter four in a clear, coherent and easily understandable way.

16

Components and Services

Figure 1.4 The outline of the thesis The way of working of the method is given in chapter six. The set of guidelines, activities, rules and techniques for mapping business requirements into software implementation, using the proposed concepts and notation, is presented. An incremental and iterative process for creating the four component architectural models that together form the complete specification of the system that can be easily implemented using the technology platform of choice is applied in the method. The created method is tested and evaluated in chapter seven. The method is tested for usability by applying it in a case study of building a location-based geographic-information system for supporting users in the field. Based on this application, the method was evaluated by the participants in the case study at the organization where the case study was performed, using a survey technique. The main added values of the method are given, and compared with the current state of the theory and practice in the field. The main conclusions, a reflection on our research, and recommendations for further research are discussed in chapter eight. 17

2 The State-of-the-Art of Component-Based Software Systems Development An overview of the various aspects of Component-Based Development (CBD) is presented in this chapter. The chapter starts with a basic perspective on CBD, followed by definitions of a component and related concepts. An outline of the significant achievements in the fields of component-based implementation models and component-based development methods is presented. New developments and paradigms, such as Web services, service-oriented architecture and model-driven development related to this research are presented. At the end of the chapter, an attempt is made to define the concepts and steps that are needed to improve current CBD theory and practice.

2.1 The Roots of CBD Building complex systems from simpler components is not an invention of the software industry. Around two centuries ago, Eli Whitney proposed manufacturing rifles with interchangeable parts specified clearly according to templates, instead of crafting each rifle individually. Widely regarded as the beginning of mass production, this strategy of interchangeable components led to a dramatic increase in production capacity while delivering the additional benefits of consistent operation and easy maintenance in various manufacturing and, later, industry sectors and it has become a standard approach in e.g. the construction of various electronic devices and in advanced systems engineering. In the field of information systems engineering, CBD is also considered to be an evolutionary rather than a revolutionary approach. It has existed in one form or another for a number of years. The idea of constructing modular software system has long been recognized as advantageous within the software community. This dates back to the early days of structure programming using subroutines and libraries serving as "components" (Parnas, 1972). During the original NATO conference, in 1968, components were seen as a solution for a software crisis or a lack of software that highlighted the widening gap between the achievements of software engineering, when compared to its ambitions. Brooks in his well-known work Mythical Man-Month (1975) describes the difficulties involved in developing complex software systems and presents two possible methods to avoid the complexities of these systems, namely “buy before build” and “reuse before buy”. These strategies are among the cornerstones of today’s CBD paradigm. 19

Chapter 2 During the 1990’s object-oriented (OO) techniques were considered to be a powerful means for solving the software crisis due to achieved high maintainability and reusability (Cook and Daniels, 1994). Some authors state that CBD is a natural extension and an evolution of the OO paradigm, containing, as it does, many similar concepts and characteristics (Orfali et al., 1996; Brown and Wallnau, 1998). Others insist on the failure of object technology for solving software reusability problems and on the necessity for introducing a new component development paradigm (Udell, 1994). The works of Booch (1987) and Meyer (1994) are generally regarded as seminal in the advancement of ideas regarding the fundamental nature of components, particularly with regard to low-level structural properties of the components. Work done by Nierstrasz (1995) in relation to software composition for open distributed systems can be considered to be an important contribution to later CBD concepts and ideas. Further work has extended these early ideas along various dimensions, including the introduction of formal specifications into component frameworks, the development of new paradigms for data movement, and the development of improved design guidelines for what constitutes a good component that is both efficient and independently verifiable. Over the last few years component-related research has also been found under various subjects such as module interconnection languages (MILs) (Prieto-Diaz and Neighbors, 1986), module interface specification and analysis (Perry, 1989), mega-programming (Wiederhold et al., 1992), domain-specific software architectures (Fischer, 1994), software generators (Batory and Geracy, 1996), object-oriented frameworks and patterns (Gamma et al., 1995; Fayad et al., 1999), architecture description languages (ADLs) (Garlan and Perry, 1995) and real-time object-oriented modeling (ROOM) (Selic, Gullekson and Ward, 1994). Components were first introduced at the level of implementation for fast building a graphical user interface using VBX (Visual Basic eXtensions) controls or Java controls. Following that, first Microsoft ActiveX/DCOM/COM, CORBA objects and services, and Java Beans, followed by Microsoft COM+/.NET (Microsoft .NET, 2004), CORBA Components (Siegel, 2000) and Enterprise Java Beans (EJB) (Sun, 2004) were proposed as standard componentbased implementation solutions. Based on them, component-based frameworks and architectures were developed to speed-up application development, such as the IBM SanFrancisco framework based on EJB (Carey, Carlson, and Graser, 2000) and the TINA architecture for building telecommunication systems based on CORBA (TINA-C, 1996). A common theme to all these initiatives is a shift of emphasis from developing small, centralized monolithic systems to developing complex systems consisting of functional units deployed over nodes of the Web. The two key concepts that have emerged are: (i) components as large-grain building blocks of a system and (ii) architectures and frameworks as blueprints of the system describing its main building blocks and the way of composing them into a coherent whole.

20

The State-of-the-Art of Component-Based Software Systems Development

2.2 Component Basics Components are at the heart of CBD. Therefore, a precise definition of a component is needed to understand the basics of CBD and to gain the full benefit possible when following the paradigm. A clear distinction between the concepts of component and object (class) should be made to understand better the advantages of the new component way of thinking. Since a component represents a black-box entity with hidden implementation, it is important to define the concept of component interface as one of the most significant elements of a component. 2.2.1 Component Definitions Various definitions of a component have been proposed, showing clearly that different stakeholders in a development process consider and use components differently. Some definitions are more intuitive and focus on the general aspects of a component, while others define a component more precisely by enumerating its basic properties. The physical perspective on a component as a package of binary or source software code has been predominant for a long time. For example, in a Component Object Model (COM) technical overview from Microsoft, a component is defined as “a piece of compiled software, which is offering a service” (Microsoft, 1996). Object-oriented technology practitioners tend to consider component as implementation level artifacts. In the industry standard objectoriented modeling language, the Unified Modeling Language (UML), versions 1.1 to 1.5, components are physical entities deployed over network nodes (Booch, Jacobson, and Rumbaugh, 1999). UML is a design notation originally developed for the specification of object-oriented systems. Support for components was added to the first UML standards as an afterthought. Therefore, the support provided by UML is likely to be limited and pose some drawbacks (Cheesman and Daniels, 2000). A component in the UML standard (version 1.3) is defined as “a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files” (Booch et al., 1999; OMG-UML 1.3, 1999). The definition is broad and allows for the existence of different kinds of components other than standard software components, such as executables, libraries, tables, files and documents. Similarly, in the Rational Unified Process a component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture (Kruchten, 2003). The term “fulfills a clear function” means that a component is logically and physically cohesive, and thus denotes a meaningful structural and/or behavioral chunk of a larger system. It is not just some arbitrary grouping. The new major revision of the UML (version 2.0), the completion of which is planned for this year (2004), will significantly improve the ability to represent components as, not only implementation level artifacts, but also as design-level concepts that, together with classes, represent the main mechanisms used to build a logical system architecture (OMG-UML 2.0, 2004). 21

Chapter 2 Beside this, other component definitions have been proposed that are similar, or to some extent complementary, to the original UML definition. In one of the seminal works in the CBD area, Szyperski (1998) defines a software component as a unit of composition with contractually specified interfaces and explicit context dependencies. A software component can be deployed independently and is subject to composition by a third party. The Gartner Group (1998) industry analysts define a runtime software component as a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime. Another definition is proposed by Kozaczynski (1999) where a component is a part of a system that is, at the same time a unit of design, construction, configuration, management and substitution. A component conforms to, and provides the realization of, a set of interfaces in the context of well-formed system architecture. D’Souza and Wills (1999) in their Catalysis development approach define a component as a reusable package of software, which is independently developed and can be combined with other components to build larger units. A component in Catalysis may be adapted, but may not be modified. Lewandowski (1998) proposes yet another component definition, by which a component is defined as the smallest self-managing, independent and useful part of a system that works in multiple environments. Some authors try to define a component from a business perspective, treating it as a unit that encapsulates business functionality. Herzum and Sims (2000), for the purpose of their Business Component Factory approach, define a business component as the software implementation of an autonomous business concept or business process that consists of all the software artifacts necessary to represent, implement and deploy a given business concept as an autonomous reusable element of a larger business system. A similar definition can be found in (Andersen Consulting, 1998) where a business component is defined as a means for modeling real-world concepts in the business domain. A component encapsulates everything about these concepts including name, purpose, knowledge, behavior and all other intelligence. A summary of the various component definitions is given in Table 2.1 below. Table 2.1 Summary of various component definitions Source (Microsoft, 1996) (OMG-UML 1.3, 1999). (Kruchten, 2003) (Szyperski, 1998)

(Kozaczynski, 1999)

22

Definition A component is a piece of compiled software, which is offering a service. A component is a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files. A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A software component is a unit of composition with contractually specified interfaces and explicit context dependencies. A software component can be deployed independently and is subject to composition by a third party. A component is a part of a system that is, at the same time a unit of design, construction, configuration, management and substitution.

The State-of-the-Art of Component-Based Software Systems Development Source (Gartner Group, 1998) (D’Souza and Wills, 1999) (Lewandowski, 1998) (Herzum and Sims, 2000) (Andersen Consulting, 1998) (OMG-UML2, 2004)

Definition A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime. A component as a reusable package of software, which is independently developed and can be combined with other components to build larger units. A component is defined as the smallest self-managing, independent and useful part of a system that works in multiple environments. A business component as the software implementation of an autonomous business concept or business process that consists of all the software artifacts necessary to represent, implement and deploy it. A business component is defined as a means for modeling real-world concepts in the business domain. A component is a modular unit of a system that encapsulates its contents behind the interfaces and is replaceable within its environment.

There are certainly many types of components: physical, implementation or run-time, components and logical, design, components (Brown, 2000). What is common for all these variants of components is that a component is capable of being composed into a composition as a part of an assembly. Since there are different kinds of components, there are accordingly different kinds of compositions. A corresponding kind of composition can be defined for every kind of component. In the International Standard Organization (ISO) standard Reference Model for Open Distributed Processing (RM-ODP) a composition is defined as a combination of two or more components yielding a new component behavior at a different level of abstraction. The characteristics of this composed behavior are determined by the components being combined and by the way they are combined (Raymond, 1995; ODP, 1996). The concept of composition is recursive: a system at one level of abstraction may simply be a component at a higher level of abstraction (Kruchten, 2003). Components are often understood in different ways in different communities (Bosch, 1999). The theoretical view is that a component represents a well-defined entity, often small in size and with easily understood functional and nonfunctional features. It is a black box since it has an explicit encapsulation boundary that restricts any external access. Software development practice follows this concept in general, and many domain-specific or even company-specific component models exist (Crnkovic and Larsson, 2002). In many cases in practice, a component is seen as a large piece of software that is reusable and has a complex internal structure. It does not necessarily have well-understood interfaces, and it does not have an explicit encapsulation boundary that prevents access to its internal entities. 2.2.2 Components and Objects CBD is considered to be a next step after object-orientation (Heineman and Councill, 2001). It is therefore natural to question the similarities and differences between objects and 23

Chapter 2 components. According to Udell (1994) components represent a new silver bullet for system development in the Internet age, while objects have failed to provide a higher level of reusability. In UML, components are larger-grained objects deployed on the network nodes (Booch et al., 1999). Szyperski (1998) states that a component comes to life through objects. Therefore, it would normally contain one or more classes, as well as traditional procedures, and even global variables. In a debate on this topic given in Hendersson-Sellers, Szyperski, Taivalsaari, and Wills (1999), granularity is seen as the main issue in distinguishing components and objects. In Catalysis, components are often larger-grained than traditional objects and can be implemented as multiple objects of different classes (D’Souza and Wills, 1999). In Catalysis, components can use persistent storage, while objects typically work only within the main memory. Instead of containing classes or objects, a component could contain traditional procedures, global (static) variables, and can thus be realized by using an objectoriented approach and functional programming. In Catalysis, if an object is packaged together with the explicitly defined interfaces that the object implements and requires, then this object according to the Catalysis approach will be a component. Components in Catalysis have a more extensive set of intercommunication mechanisms than objects and have complex actions at their interfaces. In early work on distributed objects and components (Orfali, Harkey, and Edwards, 1996) a component is defined as an object that is not bound to a particular program, computer language, or implementation. Unlike traditional objects, components can interoperate across languages, tools, operating systems, and networks, but components are also object-like in the sense that they support encapsulation, inheritance, and polymorphism. In object-oriented theory, the concepts of type and its instances are considered separately, for example objects are identifiable instances of classes created at run-time (Booch, et. al., 1999). Therefore, it is natural to compare components with classes at the type level, and component instances with OO programming language objects at the instance level. The internal behavior of a component is usually described by a set of associated classes (Cheesman and Daniels, 2000). When a component is deployed in an execution environment, such as an Enterprise Java Beans (EJB) container, the behavior of the component will be provided by a set of associated objects that correspond to the classes that form a component. In the UML standard (Booch et. al., 1999), components have much in common with classes. However there are some significant differences: ♦ classes represent logical abstractions; components represent physical things; ♦ components represent the physical packaging of otherwise logical elements and are at a different level of abstraction than classes; ♦ classes may have attributes and operations accessible directly, in general, components have operations that are reachable only through component interfaces. The differences listed above clearly show that for OO practitioners, a component is a physical thing that conforms to, and realizes, a set of interfaces. Unlikely classes, the implementation of a component is generally completely hidden and sometimes only available in a binary form 24

The State-of-the-Art of Component-Based Software Systems Development (Heineman and Councill, 2001). Internally, a component may be implemented by a single class, by multiple classes, or even by traditional procedures in a non-object-oriented programming language. In the work of Jain, Chalimeda, Ivaturi, and Reddy (2001) components are exclusively made out of highly cohesive classes that satisfy the defined sets of technical and managerial conditions. It is a common conclusion, emphasized also in the study of Crnkovic and Larsson (2002), that the object-oriented approach and CBD have many similarities, but a clear distinction exists between the two approaches. They do not, however, conflict; on the contrary, object-oriented analysis, design and development constitute a set of technology and methods naturally used in CBSE. 2.2.3 Component Interface A component is an encapsulated unit with a completely hidden interior behind an interface. The interface provides an explicit separation between the outside and the inside of the component, answering the question what: What useful services are provided by the particular component to the context of its existence? But not the question how: How are these services actually realized? A precisely defined component interface allows the component services to be used without knowing how they are actually realized. A component interior is hidden and not important for its environment as long as the component provides services and follows constraints defined by its contractual interface. An interface is an essential element of any component, since it is often the only information that shows the consumer of the component what it really does. In UML, an interface is defined as “a named collection of operations that are used to specify a service of a class or a component” (Booch et al., 1999). These operations can be further expressed using visibility properties, concurrency properties, stereotypes, tagged values and constraints. In the work of Szyperski (1998), an interface of a component can be defined as a specification of its access point. The clients access the services provided by the component using these points. If a component has multiple access points, each of which represents a different service offered by the component, then the component is expected to have multiple interfaces. An interface offers no implementation of any of its operations. Instead, it merely names a collection of operations and provides their descriptions. This separation makes it possible to replace the implementation part without changing the interface, and in this way improve system performance without rebuilding the system (Brown and Wallnau, 1998). Two kinds of interfaces can be distinguished. A component can provide and require interfaces to and from its environment that can include other components. A provided interface represents the services and operations that the component provides to the environment according to its role in it. A required interface specifies the services and operations that the component requires from its environment to perform its role, i.e. to provide its services. In the ISO RM-ODP an interface is defined as an abstraction of the behavior of a component that consists of a subset of the interactions of that component together with a set of constraints 25

Chapter 2 on when they may occur (ODP, 1996). The interface describes the behavior of a component that is obtained by considering only the interactions of that interface and by hiding all other interactions (Raymond, 1995). Most techniques for describing interfaces such as Interface Definition Language (IDL) (Gudgin, 2001; Siegel, 2000) are at a syntactic level, i.e. they are only concerned with the signature part, in which the operations provided by a component are described. The main elements of an interface as defined in (Heineman and Councill, 2001) are: ♦ names of semantically-related operations, ♦ their parameters, ♦ valid parameter types. This restricted form of a component interface is not able to address the overall behavior of the component in a well-understood and precise manner (Crnkovic and Larsson, 2002). A more precise specification of component interface is required to give sufficient information about what the component really does (Brown, 2000; Cheesman and Daniels, 2000). The specification must be completely independent of implementation to allow changing a component’s implementation without affecting what it does from the point of view of a component consumer (D’Souza and Wills, 1999). A precise specification of the component interface is used to assemble and integrate properly the component into an overall solution for a given problem, to substitute the component with a compatible component if necessary, to browse the component catalog to find a component that matches the specification needed, or to reuse the component in a different context (Heineman and Councill, 2001). 2.2.4 Components and Architecture The concepts of component, composition, decomposition, and interface are very closely connected to the concept of system architecture. In the UML standard version 1.3 an architecture is defined as the organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts (components) that interact through interfaces, relationships that connect parts, and constraints for assembling parts (OMG-UML 1.3, 1999). Similarly in the RM-ODP standard an architecture is defined as the concepts and rules that define the structure, semantic behavior, and relationships among the parts of a system; a plan of something to be constructed. It includes the elements that comprise the thing, the relationships among these elements, the constraints that affect these relationships, a focus on the parts of the thing, and a focus on the thing as a whole (ODP, 1996). In another standard ANSI/IEEE 1471-2000, which defines a recommended practice for describing the architecture of software-intensive systems, an architecture is the fundamental organization of a system, embodied in its components, their relationships and the environment, and the principles governing its design and evolution (ANSI, 2000). According to the standard, associated architectural decisions seek to address such concerns as complexity, i.e. applying the principles of “separation of concerns” and “divide and conquer”, and portability 26

The State-of-the-Art of Component-Based Software Systems Development and flexibility, i.e. applying the principle of localizing areas that are likely to change simultaneously. In the Open Group Architecture Framework (TOGAF 8), the concept of architecture has two meanings depending upon its contextual usage (TOGAF, 2003): ♦ a formal description of a system, or a detailed plan of the system at component level to guide its implementation; ♦ the structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. Another similar definition of architecture is offered in the Rational Unified Process (Booch et al., 1999; Krutchen, 2003). According to this definition, an architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization, these elements and their interfaces, their collaborations and their composition. Across the systems and software communities there is quite a bit of diversity in exactly what architecture means, see http://www.sei.cmu.edu/architecture/. In a general sense, it is broadly agreed that architecture is the embodiment of the set of design decisions that define essential characteristics of the system (Clements and Northrop, 1996). Put another way, the architecture is the set of system attributes that largely determine system value, cost, and risk. An architecture is the definition of the essential qualities of the system. However, the work of Shaw and Garlan (1996) and of many others in the software architecture community often take a more structural approach, emphasizing the high-level physical structure as the architecture (TOGAF, 2003). Finally, from the point of view of an enterprise, an IT architecture is placed in a wider context of the enterprise needs. The Centers for Medicare and Medicaid Services define an architecture as "a logically consistent set of principles, policies and standards that guides the engineering of the organization's IT systems and infrastructure in a way that ensures alignment with business needs" (CMS, 2003). When defining and creating system architecture, it is important to provide an architectural model, description and specification, using some semi-formal or formal method and notation, and following an architectural style. In (Putman, 2001), an architectural model of a system is a specification of an architecture that relates the system concepts and behaviors to the users of the system in the domain in which it participates, and to the designers who will implement the model into a system that serves the purpose of the domain. It consists of precisely defined rules and concepts that address all aspects of the system, from functional to nonfunctional to semantic behavior and the rules to construct the system. 27

Chapter 2 In the ANSI/IEEE 1471-2000 standard, an architecture description is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. Architecture specification is a definition of the structural elements and elements that support their interworking by which a system is composed. A precise definition of the behavior of the interworking relationships among the software entities is also part of the architecture specification (Putman, 2001). Architectural style is a set of constraints on the structure of an architecture and on the connectors between components (Shaw and Garlan, 1996). Finally, architecting is defined as the process of creating an architecture specification (Putman, 2001). Modern systems are very complex, and this makes it difficult to specify their architecture all at once. Therefore, modern architecture practice embraces the concepts of architectural views and viewpoints that restrict the focus of interest at any moment to one, or a small number, of the system’s concerns, which are represented as views or viewpoints. A viewpoint in RMODP is a form of an abstraction achieved using a selected set of architectural concepts and structuring rules, to focus on particular concerns within a system. Some authors prescribe a fixed set of views with which to engineer and communicate an architecture. For example, the Rational Unified Process is based on 4+1 view approach to software systems (Kruchten, 2003), RM-ODP is based on five viewpoints (ODP, 1996), while Zachman’s framework defines 36 views on architecture, based on six levels, namely scope, enterprise, logical system, technology, detailed representations and functioning enterprise, and six aspects, namely data, function, network, people, time and motivation (Zachman, 1987). A recent trend, however, is to recognize that architects should produce whatever views are useful for the system at hand. IEEE 1471 exemplifies this philosophy; it holds that an architecture description consists of a set of views, each of which conforms to a viewpoint, which in turn is a realization of the concerns of one or more stakeholders (ANSI, 2000). According to RM-ODP, a complete specification of the system and its architecture is an integrated and consistent specification of all the viewpoints defined by stakeholders in a development process (ODP, 1996). The set of linked specifications, taken together, can ensure that the system can be implemented and operated in such a way that its behavior will meet the business needs of its owners, and, furthermore, that its owners will understand the constraints on their business that operating the system will impose. The RM-ODP specification framework has been used as the basis for defining and standardizing a service architecture in various industry sectors, such as telecommunication applications (TINA-C, 1996) and Geographic Information Systems (GISs) (OGC, 2001). It is worth noting that the Open Geospatial Consortium (OGC), in its documents about a GIS service architecture, was one of the first to define services as the main building blocks of the system architecture and to recognize service collaboration and chaining as an important process to reach complex, higher-level geospatial services. This can be considered to be one of predecessors of the current initiatives related to service-oriented architecture (SOA) and Web services orchestration. 28

The State-of-the-Art of Component-Based Software Systems Development

2.3 Technology Standards for CBD The major component implementation models that are presently available, and that make interoperable software components feasible, are introduced in this section. A component implementation model, often called a component middleware or a component implementation standard, defines a set of standards for component implementation, naming, interoperability, customization, composition, evolution and deployment (Heineman and Councill, 2001; Sessions, 1998b). It also includes the standard structure of a component’s interfaces, the mechanism by which a component interacts with other components, patterns for asking a component about its features, a means for browsing active components and more. Some of the widely used component implementation models are CORBA Components, Microsoft COM+/.NET and Sun’s Enterprise Java Beans (EJB). 2.3.1 Microsoft Component Model The Component Object Model (COM) is a language-independent, binary component standard that was introduced by Microsoft in 1993 (Williams and Kindel, 1994). COM core concepts include: ♦ a binary standard for function calling between components; ♦ the typed grouping of functions into interfaces; ♦ a base interface providing mechanisms for (1) other components to dynamically discover the interfaces implemented by a component and (2) a reference counter, allowing components to track their own lifetime and delete themselves when appropriate; ♦ a globally unique identifier mechanism for components and their interfaces; ♦ a component loader to set up and manage component interactions. COM also provides mechanisms for shared memory management between components and error and status reporting. In COM, an interface is represented as a pointer to an interface node. The interface node contains a pointer to a table of operation variables. These variables point to the actual implementation of the operations. Interfaces are described in a languageindependent way using the Microsoft Interface Definition Language (MIDL). Microsoft introduced its distributed version of COM, called Distributed COM (DCOM) in mid-1995 (Microsoft, 1996; Sessions, 1998a). The introduction of DCOM allowed COM components to be physically separated from the clients that used them, making it possible to create networked applications built from components. In 1996 Microsoft introduced the Microsoft Transaction Service (MTS) (Microsoft, 1998), one of the first attempts to combine transactions with components. MTS-based applications are built on top of DCOM/COM components and further introduce the following capabilities: transaction services, configurable security, resource pooling and easy component administration. In 1998 Microsoft introduced COM+, which coherently packages COM, DCOM and MTS into one product, enhancing existing services and further introducing new ones, such as asynchronous/queued components, loosely coupled event, component load balancing and in-memory database (Sessions, 2000). .NET is 29

Chapter 2 the latest component model from Microsoft. It is not based on COM, instead it relies on language interoperability using an internal language Microsoft Intermediate Language (MSIL) (Microsoft .NET, 2004). A .NET component provides a programmable interface that is accessed by consumer applications, often called client applications. The component interface consists of a number of properties, methods, and events that are exposed by the classes contained within the component. In other words, a component is a compiled set of classes that support the services provided by the component. A .NET component is a pre-compiled class module with a dynamically linked library (DLL) extension. At run time, a .NET component is invoked and loaded into memory to be used by some consumer application. These .NET components are often built and tested as independent .NET projects and are not necessarily part of another project (Microsoft .NET, 2004). 2.3.2 Enterprise Java Beans Component Model (EJB) The Enterprise Java Beans (EJB) Component Model was introduced by Sun Microsystems in 1998 as an extension of its client-side component model Java Beans as a part of the Java 2 Enterprise Edition (J2EE) platform (Sun, 2004). EJB is a server-side component model for the development of applications in the programming language Java. According to the EJB, a component is called an enterprise bean. There are two kinds of enterprise beans, a session enterprise bean and an entity enterprise bean. A session bean is a transient component that exists only during a single client/server session, while an entity bean is a persistent component that controls permanent data that is kept in permanent data stores, such as databases. An enterprise bean resides inside a container. The container consists of a deployment environment for enterprise beans. Further, the container provides a number of services for each bean, such as lifecycle management, state management, security, transaction management and persistence management. In this way, the enterprise bean developer can focus on the application logic that should be provided. An EJB server provides a runtime environment for one or more containers. The server manages low-level system resources and allocates them to containers as needed. The client application interacts with the enterprise bean by using two interfaces that are generated by the container, the Home interface and the Object interface. When the client invokes an operation using these interfaces, the container intercepts each call and inserts management services. The EJB Home interface provides access to the enterprise bean lifecycle services. Clients can use this interface to create, destroy or find an existing bean instance. The EJB Object interface provides access to the application methods of the enterprise bean. This interface represents the client’s view of the bean and it exposes all the application-related interfaces for the client application, except those used by the EJB container to control and manage this object. To access an enterprise bean, one must define a remote interface using the Java Remote Method Invocation (RMI) Application Programming Interface (API). These definitions are used to generate the Object interface. If the client of the enterprise bean is not a Java-based 30

The State-of-the-Art of Component-Based Software Systems Development application, the remote interface should be defined using Java IDL and CORBA integration. The client application interacts with the enterprise bean via the EJB Home and Object interfaces. The EJB container provides lifecycle management, state management, security, transaction and persistence management services for the enterprise bean. 2.3.3 CORBA Component Model (CCM) Motivated by the need to facilitate the building and deployment of component-based applications and the success of EJB, the Object Management Group (OMG) has developed a new server-side component model as part of the new CORBA 3.0 specification, called CORBA Component Model (CCM) (OMG-CORBA, 1999; Siegel, 2000). This component model aims at extending the CORBA core object model with a deployment model and at providing a higher level of abstraction for CORBA and object services. The two major advances introduced by the CCM are a component model and a runtime environment model. A component is an extension and specialization of a CORBA object. Components are specified using an extension of OMG’s Interface Definition Language (IDL), called Component Implementation Definition Language (CIDL). A component is denoted by a component reference. A component also supports a variety of surface features, called ports, through which clients and other elements of an application environment may interact with this component. There are five different kinds of ports according to the component model, as shown in Figure 2.1:

♦ ♦ ♦ ♦ ♦

Figure 2.1 A CORBA component facets, which are the interfaces provided by the components for client interaction; receptacles, which are the connection points that describe the interfaces used by the component; event sources, which are the connection points that emit events of a specified type to interested event consumers; event sinks, which are the connection points into which events of a specified type are announced; attributes, which are named values primarily used for component configuration. 31

Chapter 2 A component may have multiple facets, receptacles, event sources, event sinks and attributes. Similarly to EJB, the CCM defines different categories of components, namely service components, session components, process components and entity components. A service component supports a single invocation per instance, is stateless and has no identity. A session component supports more than one invocation per instance, has a transient state and no persistent identity. A process component has a behavior that may be transactional, has an explicitly declared state that is managed by the runtime environment and has an identity managed by the client. An entity component is similar to a process component, except for its identity, which is visible to the client but managed by the runtime environment. A component instance is identified primarily by its component reference and secondarily by its set of facet references. Component instances are managed by component homes. A component home acts as a lifecycle manager for all the instances of a specified component type. The CCM also introduces the concept of container. A container is a runtime environment consisting of a specialized portable object adaptor (POA) plus a series of CORBA services to provide persistence, transaction, security and event notification capabilities to the components deployed inside the container. A container allows a client to navigate among the interfaces supported by all its components. A container is also responsible for connecting the provided and required interfaces of its components and connecting and transmitting the supplied and consumed events. 2.3.4 Summary of Implementation Models These component models are considered to be implementation standards for components. These are standards that have been defined for implementing object and component solutions. Unfortunately, instead of a single standard in place there are three, or only two, due to combining CCM and EJB into a single initiative that confronts the Microsoft’s one. As a standard for a higher-level specification of components, UML for graphical representation and IDL for textual representation seem to be natural choices, which will be further elaborated in chapter five of the thesis. Presented component models share similar properties but have a lot of differences. The CCM is an open, vendor-neutral specification, EJB is Java-centric and platform neutral, while .NET is Windows-centric and language-neutral. The CCM shares a base architecture with EJB, extending it to programming languages beyond Java. The last years have witnessed a great debate over EJB versus .NET with opposite arguments from both sides in their comparison (Sessions, 2001; Heineman and Councill, 2001). Since none of these technologies can dominate the software industry, attempts have been made to provide interoperability between .NET and J2EE platforms that enable connecting application on different platforms inside an organization (Guest, 2003). A common conclusion is that the component implementation models are constantly evolving through introducing new and richer versions, and the choice of the component model becomes an important part of an organizations’ IT strategy (Sessions, 2001). 32

The State-of-the-Art of Component-Based Software Systems Development

2.4 Component-Based Development Methods and Approaches While technology is a necessary element of any solution, it is not sufficient on its own. Methods and techniques for developing component-based applications based on business requirements are equally important (Welke, 1994; Dahanayake, Stojanović, and Sol, 2003). A precise plan to follow from business requirements to software implementation must be defined using components of different types and at different levels of abstraction (Atkinson et al., 2002). The IT community has recently started to recognize the importance of new CBD methods, processes, and techniques. The way these methods handle component concepts is significantly influenced by their object-oriented origins (Dahanayake et. al., 2003). The most important CBD methods and approaches will be presented in this section. 2.4.1 Rational Unified Process Rational Unified Process (RUP) (Jacobson et al., 1999) is a software engineering process developed by Rational Software. RUP is the direct successor to the Rational Objectory Process (version 4), which resulted from the integration of the Rational Approach and the Objectory process (Jacobson, Christerson, Jonsson and Overgaard, 1992) in 1995. RUP was the first process to use UML from the beginning (version 0.8). RUP includes development and management of the process and covers the entire software life cycle. The RUP is very well documented and available in books and companion papers, and is supported by a web-based knowledge base that provides all team members with guidelines, templates and tool mentors for all development activities. Many training and consultancy opportunities are available. A family of tools, produced by IBM Rational Company is available to support the process. The key concept of RUP is the definition of activities, called workflows, throughout the development life cycle, such as requirements elicitation, analysis, design, implementation, and testing. Unlike the classical waterfall process, these activities can be overlapping and performed in parallel. Within each of the activities there are well-defined stages of inception, elaboration, construction, and transition. While they occur in sequence, there may be iterations of these until a project is complete. During the design of the solution, CBD support is encouraged but it is rather declarative and implicit. RUP promotes CBD through the use of UML and it is heavily influenced by UML notations and its design approach. UML has an implementation and deployment view on components through component and deployment diagrams. Therefore, RUP’s view on the component concept is still on the level of physical packaging. This is illustrated by RUP’s definition of a component as “a non-trivial, nearly independent, and replaceable part of a system that fulfils a clear function in the context of a well-defined architecture. A component conforms to, and provides the physical realization of a set of interfaces”. RUP suggests the use of UML subsystems for modeling components without a detailed elaboration. It is obvious that RUP is not specifically focused on component-based development. It offers a general framework for object-oriented design and construction that can be used as the basis for other methods. Use of UML as the basic 33

Chapter 2 modeling notation provides a great deal of flexibility in designing, but specific support for key component modeling concepts is lacking and limited to UML notations. In its current improvement and extension of UML (version 2.0), RUP may adapt more complete and consistent CBD principles. One of the main advantages of RUP is that it provides an opportunity for iterative and incremental system development, which is seen as the best development practice. 2.4.2 Select Perspective The Select Perspective method (Allen and Frost, 1998; Apperly et al., 2003) was created by combining Object Modeling Technique (OMT) (Rumbaugh, Blaha, Premerlani, Eddy, and Lorenson, 1991) and the use case driven Objectory method (Jacobson et al., 1992). After the standardization of UML as an object-oriented modeling language, the method adopted the UML notation. The first version of Select Perspective comprised the activities of business modeling, use case modeling, class modeling, object interaction modeling and state modeling. With the growing interest in CBD, Select Perspective was extended with activities related to different aspects of components, business-oriented component modeling, component modeling of legacy assets and deployment modeling (Allen and Frost, 1998). The latest version of Select Perspective published recently (Apperly, 2003) provides more comprehensive and sophisticated support for component-based and service-oriented development. The Select method is well tool-supported. A family of component-based tools, namely Component Factory, Component Architect, Component Manager, and various code generators, effectively support the various aspects of the method. The Select Perspective uses the standard UML enriched with the extensions to support component modeling. For the purpose of business modeling, it uses the notations of the Computer Science Corporations (CSC) Catalyst methodology (CSC, 1995). This notation and technique help to link the business processes, associated use cases and classes. The method also uses Entity-Relationship Diagrams (ERD) for mapping between the UML class model and the relational data model. Select Perspective seamlessly integrates three visual modeling techniques, Business Process Modeling, Unified Modeling Language (UML) and Data Modeling. Components in Select Perspective are executables offering services through published interfaces. The services can, but not necessarily, be implemented using object technologies. Though based on the UML, the method uses a streamlined set of UML modeling techniques, without introducing new concepts that require UML extensions. The component concept is seen as the concept package, defined in UML as “a general purpose mechanism for organizing elements into groups” (Booch et al., 1999). Two basic stereotypes of the packages are distinguished: service packages used in business-oriented component modeling and component packages 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 34

The State-of-the-Art of Component-Based Software Systems Development executable component, i.e., the actual code. When a service package is placed on a node of the network, belonging to the UML deployment diagram, the package effectively becomes a component package. Special attention is paid to component modeling of the legacy assets, i.e., on how to use the component principles to wrap efficiently and further use legacy systems. The latest version of Select Perspective includes support for Web services. The Select Perspective software development life cycle is a set of workflows that are based on an iterative and incremental development approach. The method defines three basic workflows: Consume, Supply, and Manage. The Consume workflow delivers the solution that uses components and services from the component suppliers and then maintains and supports that solution. The Supply workflow delivers and maintains components based on request for services from particular component and service consumers. The Manage workflow is concerned with the activities of acquiring, certifying, classifying and locating components to serve the needs of both component consumers and suppliers. The Select Perspective provides a comprehensive development lifecycle for component-based solutions that supports business-aligned parallel development to reduce time-to-market. The method defines project management features such as iterative working, incremental working and planning, parallel working and monitoring. The method is practical, meaning that it is derived from best practices proven on real projects. 2.4.3 Catalysis Catalysis (D'Souza and Wills, 1999) is a component-oriented approach with its origins in object-oriented analysis and design. Catalysis began in 1991 as a formalization of OMT (Rumbaugh, J. et. al., 1991), and was developed over several years of applying, consulting, and training. It extends second-generation OO-methods such as, Fusion (Coleman et al., 1993) and Syntropy (Cook and Daniels, 1994), including support for framework-based development and defining methodical refinements from abstract specification to implementation. Catalysis is well documented in corresponding books, technical papers and by a dedicated website (www.catalysis.org) offering on-line support. Opportunities for training and consultancy are also provided. Catalysis is effectively supported by the COOL family of tools such as COOL:Gen, COOL:Spex, COOL:Joe, etc. originally developed by Sterling Software. After acquiring Select Software, Computer Associates renamed the tool into Advantage Gen, Advantage Joe, etc. (Computer Associates, 2003). Catalysis is a methodology for modeling and constructing open systems from objects, components and frameworks. Catalysis is mostly a development process, which means that its main purpose is to provide software construction from high-level requirements. Unlike RUP, Catalysis does not cover project management, process measures, tests, and team-task management. Although the details of Catalysis are somewhat complex, the approach is based on a small number of underlying concepts such as types, conformance, collaborations and frameworks, used throughout the approach. The Catalysis component development approach encourages a strong separation of component specification from implementation, using an extended form of UML. This allows technologyneutral specifications to be developed and then refined into implementation in a number of 35

Chapter 2 different implementation technologies. Although Catalysis covers the complete system lifecycle, “from business to code”, the component concept is visible at the implementation level. Catalysis 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 and extended to build something larger”. Higher-level support for the component concept is provided by ‘type’, which is a stereotype of a class, and the collaborations among the types. The type is defined as a representation of some consistent behavior in the domain, while a class is an implementation of the type. External behavior of the type is defined by its interface, which is mapped to class operations. Refinements from abstract to more detailed descriptions of a system are recorded by capturing conformance between types. The interactions among types are modeled as collaborations. This captures a set of actions involving multiple, typed objects playing defined roles with respect to each other. A package is a larger-grained development concept, and acts as the basic unit of a development product which can be separately created, maintained, delivered, updated, assigned to a team, and generally managed as a unit. Units of versioning, configuration management and reuse are defined. Therefore, the source for component-based development in Catalysis is, by implementation in COM/.NET, CORBA Components or Enterprise Java Beans (EJB) component models. Catalysis makes a clear separation between system specification and implementation. It uses concepts of abstraction, refinements, and frameworks to achieve an iterative, non-linear and parallel process with necessary quality assurance. The Catalysis approach is not a rigorous methodology. It is rather a semi-structured set of design principles, advices and patterns throughout the system development life cycle. Therefore, a systematic “roadmap” of the Catalysis approach is lacking, and this can create possible difficulties in applying it in practice. However, the Catalysis approach represents the development methodology with the most comprehensive and complete support for CBD concepts and principles among the available CBD approaches. 2.4.4 KobrA KobrA is a software development method that uses and supports the component paradigm in all phases of the software lifecycle following product-line strategy (Atkinson et al., 2002). It was developed as a result of the KobrA project, funded by the German government and led by Softlab GmbH, Psipenta GmbH, GMD-FIRST and Fraunhofer IESE, as a combined effort of industry and research institutes, from 1999 to 2001. The KobrA approach is influenced by other leading software development methods, such as Fusion (Coleman et. al., 1993) and Catalysis (D’Souza and Wills, 1999). It is also compatible with the Rational Unified Process (Jacobson et. al., 1999) and OPEN (Graham, Henderson-Sellers & Younessi, 1997) process frameworks. The method is documented in the dedicated book (Atkinson et al., 2002), scientific papers, and companion reports. The method is well equipped to support practical software engineering projects, and is supported by Softlab’s specially developed workbench 36

The State-of-the-Art of Component-Based Software Systems Development based on the Enabler repository family. This workbench allows organizations utilizing the KobrA method to assemble their own preferred suite of tools to support KobrA development. Although product-line engineering is fully integrated within KobrA, it is not necessary to develop a product-line when applying KobrA. The aim of product-line engineering is to leverage the commonality within systems in a given business area by building a highly reusable product infrastructure, or framework. KobrA extends the usual “binary” view of components by providing a higher-level representation based on a suite of tightly related UML diagrams. The method defines a component by two main parts: specification, which describes the externally visible characteristics of a component and realization, which describes how a component satisfies the specification in terms of interactions with lower-level subcomponents. The central artifact in KobrA is the framework, which represents a collection of KobrA components organized in a tree-structure based on the composition hierarchy. In KobrA, every behavior-rich element of a system is a Komponent, i.e. a KobrA component. The method uses qualifiers to distinguish between different kinds of components: instance vs. type and specification vs. realization. KobrA supports the principles of architecture-centric and incremental development. Since it is UML-based it can be applied in conjunction with RUP or OPEN. KobrA also includes systematic, rigorous quality assurance techniques, namely inspections, testing and quality modeling. A KobrA component has at the same time properties of a class and a package. The composition of components is defined mainly through containment trees. The authors propose a component notation that is not the standard UML, but rather a custom notation loosely based on UML. The method is based on a number of software engineering principles, parsimony, encapsulation and locality, which are often restatements of generally accepted principles for keeping things simple, separating concerns and minimizing coupling. 2.4.5 UML Components Cheesman and Daniels (2000) propose a method called UML Components that is strongly influenced by Catalysis, RUP, and Syntropy (Cook and Daniels, 1994). The method focuses on the specification of components using the UML. While the method is published in book form, there is no information on its application in practice. The method describes how to architect and specify enterprise-scale, component-based systems using the UML. The book commences with a detailed explanation of the basic principles of software components and component-based development, in a manner that establishes a precise set of foundational definitions that are essential before approaching the reminder of the book. The method discusses how core UML diagrams such as the Use Case can be used in the context of components. Although the method defines the six main workflows (similar to RUP) as Requirements, Specification, Provisioning, Assembly, Test, and Deployment, it primarily focuses on the first two. The specification workflow is the most interesting from the perspective of CBD, and 37

Chapter 2 consists of three main sub-workflows: component identification, component interaction, and component specification. For the purpose of component-based design, the method uses the UML notation enriched with proper extensions, stereotypes and modeling conventions. The method stops with the activity of Component Specification. It does not offer the ways to translate the component specification into implementation and verify that the implementation complies with the specification. The method proposes a number of extensions that are outside the bounds of standard UML, which makes it difficult to apply one of the existing UML-based modeling tools for practicing the method. The method provides precise and detailed guidance on how to extend and customize UML for the purpose of component modeling and specification. In essence, the UML Components method offers a subset of Catalysis concepts together with a much simpler RUP-like process. Components are identified through identifying system interfaces that are related to use cases, and business interfaces that are related to business entity types. Identified components are further specified through the information types that represent the component state, as well as pre-conditions and post-conditions on component operations that specify the component behavior. Generally, the UML Components method contains important, practical advices for developers practicing CBD. 2.4.6 Business Component Factory Herzum and Sims (2000) propose the Business Component Factory (BCF) approach as a way to use components in enterprise system design. Both authors have been active in the OMG’s business object development efforts. The book (method) is about how one develops largescale components for use in enterprise development. The approach is split into 3 parts: i) a conceptual framework that covers CBD and component concepts, ii) component factory set up for putting the factory itself in place and iii) manufacturing component-based software regarding modeling and design considerations. The authors suggest a classification of components that reflects granularity: language class, distributed component, business component, business component system, and finally federation of system-level components. The book provides little coverage of commercial implementation platforms such as J2EE, CORBA or COM+/.NET. The focus of the method is on the business components that are defined as important business concepts that are relatively autonomous in the problem space. Business components can be of the following types: entity, process, utility, and auxiliary. These components are more related to business object theory, which is logical since the authors’ background is in business objects. The BCF approach defines business components as representations of autonomous business concepts and business processes in the domain. Separating entities and behavior, this approach does not provide a uniform view on components. In addition, the role and importance of component interfaces are diminished. The method further presents the set up of the component factory from the viewpoint of the development process, technical and application architectures and the project management 38

The State-of-the-Art of Component-Based Software Systems Development architecture. Finally, the method proposes a number of modeling and design steps and activities by focusing on the functional architecture. 2.4.7 Summary of the Methods In this section we analyze the presented methods by summarizing their main characteristics. We used an evaluation framework introduced in the Table 2.2 as an analysis tool. As a basis for this analysis we use the NIMSAD (Normative Information Model-based Systems Analysis and Design) framework (Jayaratna, 1994). The goal of this analysis is not to rate the methods, but to find out if the elements defined in the framework are considered by the method. If and when the elements are considered, the objective is to investigate how it has been done. This framework was chosen as a basis for the following reasons: it has a wide scope; it is not restricted to evaluation of any particular category of methods; it is practical and has been used in several real-life cases; and, it considers different use situations. According to NIMSAD, methods are evaluated through four elements, which are: the method context, the method user, the method itself, and finally the way the method evaluates the other three elements (Jayaratna, 1994). A summary of the characteristics of the methods is given in the Table below in the form of an evaluation framework, while a detailed explanation of these characteristics can be found in the presentation of methods given above. Table 2.2 Characteristics of the CBD methods RUP Availability

Background Maturity

Book, website, consultancy, training Industry Widely used in practice

Development, Method management concerns Use of a method Regularly used in industry Elements of a development process Method input

Workflows, guidelines, templates Requirements, use cases

Method output Application models and software

Select Perspective Book, website, consultancy, training Industry

Catalysis

KobrA

Book, website, consultancy, training Academic & Industry Used in practice

Book, papers

Academic & Industry Used in Not fully practice applied in practice Development, Development Development, management management Regularly used Catalysis Used by KobrA based methods consortium in industry used Phases, Rough Phases, guidelines guidelines, activities, patterns guidelines Business Use cases, Requirements processes, use domain model specification cases Application Application Application models and specification specification software

UML BCF Components Book, papers, Book, papers, consultancy consultancy

Academic & Industry Not fully applied in practice Development

Academic & Industry Not fully applied in practice Development

Potentially Potentially used in industry used in industry Workflows, Phases, activities guidelines, patterns Use cases, User’s domain model requirements, domain model Application Application specification specification and models and models

39

Chapter 2 RUP

Select Perspective Rational Select Tool support product family Component (Rational Rose, Factory etc.) UML BPM Catalyst, Modeling UML, ERD techniques Implementation Design & View on implement. components Not applicable Service Component package, UML design subsystem Component Component Component package, implementation diagram

Catalysis COOL tool family, now Advantage tool family UML Design & implement. Stereotype type

KobrA

UML BCF Components No specific Enabler No specific tool; Workbench and tool; UMLbased tools used UML-based Repository tools used UML-based UML (with UML-based extensions) Design & Design & Design & implement. implement. implementation Not specific Stereotype of Stereotype of the UML class the UML class

Defined design No patterns No Component repository Software Reusability components

Yes

Package, Software components Yes

Yes

No

Components, patterns

Components, Design-level patterns, and software frameworks components

Design-level and software components

Incremental & Yes Iterative

Yes

Yes

Yes

Realization components

Not specific

Software components

No

No

Yes

Yes

No

No Design and software components, patterns Yes

Yes

2.5 Components and Web Services Further evolution of component plug-and-play concepts and principles has recently led to the Web services paradigm. Web services have been introduced as a promising paradigm for effective enterprise-scale system development and integration. These self-contained and selfdescribing business-driven functional units can be plugged-in or invoked across the Internet to provide flexible enterprise application integration within the Service-Oriented Architecture (SOA) (Kaye, 2003). The notion of a service is an integral part of component thinking. A component by definition provides a service to its environment. The service is the consumer view of component capabilities The W3C’s Web Services Architecture Working Group in its Web Services Glossary defines a service as “an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent” (W3CWS Glossary, 2004). The service forms a contractual agreement between provider and consumer. Beside common interface that defines operation signatures, the service also has attributes of its own such as service level agreement, policies, dependencies, etc. A service interface defines a contract and the parties’ obligations precisely and thus allows the consumer 40

The State-of-the-Art of Component-Based Software Systems Development to use the functionality offered without being aware of the underlying implementation (Apperly, 2003). There are actually a number of parallels between service-orientation, objectorientation (OO) and classical CBD. Like objects and components, services represent natural building blocks that allow us to organize capabilities of the system in ways that are meaningful to the user of the system. Similarly to objects and components, a service is a fundamental building block that combines information and behavior, hides the internal workings from the outside perspective and presents a relatively simple interface to the environment (Kaye, 2003). When using Web services technology, the component itself is not acquired in the traditional manner of taking a copy and executing it in the house, but rather just the services provided by the component are consumed by an application via the Web while the component executes its function in a single location, available to all who subscribe (Newcomer, 2002). The idea of a software system or an application as a service has become well recognized in the last few years, and now it can be fully realized using the Web services technology for systems interoperability (Newcomer, 2002). Web services are the set of protocols by which services can be published, discovered and used in a technology neutral, standard form. What is really important in this new service paradigm is the concept of service and the strategy to expose system capabilities to consumers as services, via the SOA. This implies a clear distinction between service-oriented thinking and service-oriented technology. The SOA framework represents the realization of the service way of thinking considering a business domain as organized into a set of modular services providing business-level functionality that are provided, consumed, brokered and orchestrated into more complex services. The CBD and Web services technology and standards are just the way to implement SOA, i.e. the way to bring the service thinking into practice. While technology achievements “come and go”, the service-oriented thinking represents a promising paradigm for building current and future business information systems. The advanced technology is an important enabler of this paradigm, providing its effective realization in practice. In its essence, SOA is a way of designing a software system to provide services to either enduser applications or other services through published and discoverable interfaces (Kaye, 2003). Whilst the word ‘architecture’ in SOA suggests the focus on architecture perspective, matters such as business design and the delivery process are important considerations. As defined by the W3C’s Web Services Glossary, SOA is “a set of components which can be invoked and whose interfaces descriptions can be published and discovered” (W3C-WS Glossary, 2004). A basis of SOA is the concept of service as a functional representation of a real world business activity meaningful to the end-user and encapsulated in a software solution. As stated in Stojanović, Dahanayake, and Sol (2003b), behind every service in a SOA, there is a component-like entity that realizes it, i.e. a service is a consumer’s view of component capabilities.

41

Chapter 2

Figure 2.2 Basic elements of a SOA As already stated, SOA is not a new notion. Similar initiatives have been proposed in the past, such as CORBA services or Microsoft’s DCOM. The novelty of SOA is that it relies upon universally accepted Web services standards to provide broad interoperability among different vendors’ solutions. The basic elements of a SOA are a service provider, a service consumer and a service broker, as shown in Figure 2.2. The service provider makes the service available and advertises it on the service broker by issuing the service contract. The service consumer finds the service that matches its needs in a service repository of the service broker using the published service contract. The service consumer and the service provider then interact in terms of providing/using the service. It is important to note that the communication between a service provider, a service consumer and a service broker is performed using the same set of interoperable, technology independent standards for communication, such as XML, SOAP and WSDL. Web services technology and SOA are increasingly becoming a business issue based on the new technology’s ability to deliver strategic business value (Berry, 2003). In the business-IT community Web services are emerging as a critical technology for achieving the business objectives of growing revenue, reducing costs and improving operating efficiencies (Marks and Werrell, 2003). It is interesting to highlight the basic technology foundation for Web services and SOA. The W3C’s Web Services Glossary defines a Web service as “a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” (W3C-WS Glossary, 2004) As defined, the basic elements of the Web services protocol stack are the standards for interoperability, XML, SOAP, WSDL and UDDI that provide platform-independent communication of software resources across the Internet (W3C, 2004; Newcomer, 2002). XML that states for eXtensible Markup Language is a flexible markup language representing a text-format layer that can be used to describe any type of data in a structured way. XML 42

The State-of-the-Art of Component-Based Software Systems Development Schema defines the structure, content, and semantics of XML documents. Web Services Description Language (WSDL) is an XML-based language that is used to describe the interface, protocol bindings, and other important details of a Web service. The Simple Object Access Protocol (SOAP) is a lightweight, XML-based protocol that allows clients to invoke services over a network. This protocol is used to communicate between a Web services requester and a Web services provider. Universal Description Discovery and Integration (UDDI) specifies a platform-independent method to describe services, discover business services, and integrate business services using the Internet. Users can search public UDDI directories (like the Yellow Pages for Web services) available on the Internet, or private directories to find available Web services. On top of this basic Web services interoperability stack, new languages and specifications for defining the choreography of services that forms real-world business processes are emerging, such as the Business Process Execution Language for Web Services (BPEL4WS) (BPEL, 2003). By encapsulating software components or underlying applications with Web service interfaces and then orchestrating these fine-grained functional Web services into coarse-grained business services using e.g. BPEL4WS, organizations can define their IT infrastructure so that it meets their business needs much better than before (Kaye, 2003).

2.6 Model-Driven Development and Agile Development Besides using the component and Web services paradigm in system development, it is important to decide what strategy and process should be followed in building complex software systems. In the last years, two increasingly important developments in IT, corresponding to fundamentally different philosophies about how software systems should be built, have emerged. The first, model-driven development, tries to preserve investments in building systems against constantly changing technology solutions by creating formal architecture models that can be mapped to whatever software technology. In contrast, for the agile development approach the software code is the only thing that matters in a software project, due to the ever-changing business requirements that result in rapidly outdated models. These two development process paradigms are explained in this section. 2.6.1 Model-Driven Architecture The activities of modeling and design in building complex service-oriented systems provide a better understanding of the problem and the solution across the project, and better communication among the stakeholders involved, especially when they are physically separated or affiliated to different organizations. Modeling efforts represent a basis of a development process that should be used to guide architects and developers in mapping business requirements into software artifacts. Since technology and standards are constantly evolving, the proper way of modeling and architecting complex Web solutions becomes even more important. Therefore, a new paradigm in system development, called Model-Driven Architecture (MDA) has been proposed (OMG-MDA, 2004; Frankel, 2003). MDA stresses 43

Chapter 2 the importance of platform-independent and platform-specific models to separate abstract domain knowledge from the concrete implementation environment. With the development of advanced tools for mapping models into the working code, depending on the target platform, the role of models has become even more important. Using the MDA approach, models now represent higher-level programming constructs for building business applications that are based on traceable business requirements. Advanced tools can be used to provide automatic generation of XML, Java or other software code based on given models. In MDA, models expressed in a well-defined notation (such as UML) are the cornerstone to understanding systems. System development using the MDA approach is organized around a set of models by imposing a series of transformation between models. MDA defines four models: Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM) and Implementation Specific Model (ISM) (OMG-MDA, 2004). A formal foundation for describing models in a set of metamodels using the OMG standards, UML, Meta Object Facility (MOF), XML Metadata Interchange (XMI), and Common Warehouse Metamodel (CWM), the specifications of which can be found on the Object Management Group (OMG) website (http://www.omg.org), facilitates meaningful integration and transformation among the models and is the basis for automation through tools. Following the strategy that uses models to represent key ideas in both problem and solution domains, MDA provides a conceptual framework for using models and applying transformations between them as part of a controlled, efficient software development process (Kleppe, Warmer and Bast, 2003). One of the limitations of MDA is that it assumes that the business requirements are fully specified and fixed before the models are built, which is rarely the case in today’s dynamic business environment (Ambler, 2002). 2.6.2 Agile Development Parallel to the MDA initiative, the last few years have witnessed considerable interest in the IT community over eXtreme Programming (XP) and other Agile Methodologies (AMs). They have been proposed as a way to build quality software systems fast and to allow them to be easily adapted to rapidly and frequently changing requirements in the environment. Agile processes are focused on early, fast and frequent production of working code using fast iterations and small increments. The processes are characterized by intensive communication between participants, rapid feedback, simple design and frequent testing. Proponents of AMs see the software code as the main deliverable, while the role of the system analysis, design and documentation in software development and maintenance is de-emphasized and to some extent ignored. A number of processes claiming to be “agile” have been proposed so far. The best examples are eXtreme Programming (XP) (Beck, 2000), Scrum (Schwaber and Beedle, 2002), FeatureDriven Development (FDD) (Palmer and Felsing, 2002), Adaptive Software Development (ASD) (Highsmith, 2000), Crystal methods family (Cockburn, 2002) and Dynamic Systems 44

The State-of-the-Art of Component-Based Software Systems Development Development Method (DSDM) (Stapleton, 2003). There have been attempts to apply agile values, principles and practices in earlier phases of the software lifecycle, such as analysis and design, under initiatives called Agile Modeling (Ambler, 2002) and eXtreme Modeling (Extreme, 2003). Efforts have been made to investigate how the Unified Modeling Language (UML) can be used in an agile process, as well as to how the Rational Unified Process (RUP) (Jacobson, Booch and Rumbaugh, 1999) might be used in an agile manner (Larman, 2001; Ambler, 2002). The authors of the listed agile approaches have formed the Agile Alliance and published the Agile Manifesto that represents a condensed definition of principles and goals of agile software development. The basic Agile Manifesto principles are as follows (Agile Alliance, 2001). ♦ individuals and interactions over processes and tools; ♦ working software over comprehensive documentation; ♦ customer collaboration over contract negotiation; ♦ responding to change over following a plan. The Agile Development (AD) paradigm challenges many of the common assumptions made in software development. One of the most controversial is its rejection of significant efforts in up-front design, in favor of a more evolutionary approach. According to its critics this is very similar to the code-and-fix hacking strategy used in software development. XP and other AMs minimize the role of common design techniques in traditional software development such as frameworks, design patterns, modeling tool support, modeling languages, model repositories and reusability. However, AD supporters claim that their methodologies include just enough design for the project to be successful, and that AD design is actually done in a different way than in traditional software processes. In XP, simple metaphor-like design, refactoring, architecture prototypes and test-based design are used for the purpose of software design. 2.6.3 Model-driven vs. Agile Development While both AD and MDA claim to address the challenges of high change rates, short time-tomarket, increased return-on-investment and high quality software, it is obvious that their proposed solutions are actually very dissimilar. On the surface, MDA and AD appear to be contradictory. MDA assumes mainly fixed user requirements and suggests creating formal models around them, whereas AD handles constantly changing user requirements using fast and frequent prototyping and constant communication with the users. The question is in what ways the principles and practices of both development paradigms can be combined to gain the benefits of both approaches. The balance between the two must be made and certain elements from these approaches must be combined into a coherent architectural practice to use the benefits of both paradigms (Turk, France and Rumpe, 2002; Ambler, 2002; Stojanović, Dahanayake and Sol, 2004b).

45

Chapter 2

2.7 New Developments in Component Modeling Recently, new developments regarding the way components are defined, modeled and designed using UML have emerged. First, the UML profile for Enterprise Distributed Object Computing (EDOC) has been standardized as a specification for facilitating the development of component-based EDOC systems (OMG-UML4EDOC, 2004). Further, the new major revision of the UML, version UML 2.0, is in the finalization phase and will be realized soon (OMG-UML2, 2004). Both efforts propose the concepts and mechanisms that provide representing components throughout the development lifecycle, from modeling components during system analysis and design to implementing them using software artifacts. However, they do not propose a method or stepwise guidelines about how to proceed with componentbased design and development from requirements to deployment. 2.7.1 EDOC Profile The UML profile for EDOC is an extension of UML version 1.4 that aims at providing a modeling language for design of enterprise applications. A UML profile is a specialization of UML to be applied in some specification task, in this case in the specification of EDOC systems. The complete specification of the UML profile for EDOC can be found in (OMGUML4EDOC, 2004). The profile consists of a set of five related UML profiles: the component collaboration architecture (CCA), the entities profile, the events profile, the business process profile and the relationships profile. In this section, we will focus on the ways components are represented in the EDOC profile, which is covered by the CCA profile. The CCA is used to model enterprise application components, the way in which these components are interconnected, and the messages and relationships between the components. The main element of the CCA profile is a process component that corresponds to the logical concept of component. A process component can be abstract, i.e. specified only from the outside perspective, or concrete, i.e. with specified internal realization or implementation using some component technology. A process component can be decomposed into finer-grained components or composed with other components to form a coarser-grained process component. Process components communicate among each other by sending and receiving messages via ports. A port defines a point through which a component can interact with other components. A port can be of a different type, such as a protocol port, an operation port, a flow port and a multiport. The order in which a process component sends and receives messages over its ports can be represented as a choreography and modeled by an activity diagram. The CCA defines an interface as a specification of operational ports and flow ports of a component, which corresponds to a typical interface that can be specified by IDL. A process component can also have properties defined to allow its parameterization. The CCA defines component usage as an instance of a process component. The EDOC notation for representing process components is shown in figure 2.3. The process component ProcComp has two flow ports, receive1 and 46

The State-of-the-Art of Component-Based Software Systems Development send1, to receive and send data respectively, and protocol ports Responder and Initiator, which responds and initiates certain protocols respectively. The protocol port Responder consists of flow ports R-receive1, R-receive2, and R-send1, and the protocol port Initiator consists of flow ports I-send1, I-send2, and I-receive1. The bottom part of the component icon is reserved for the component properties, their types and initial values.

Figure 2.3 The representation of a process component using the CCA notation 2.7.2 UML 2.0 While previous versions of UML have primarily implementation focus on components, the new version 2.0 introduces new concepts to support CBD throughout the development lifecycle, from logical components to concrete software components. A part of the UML 2.0 specification is defined as a package. The Component package defines necessary mechanisms for representing different aspects of components. This package relies strongly on the Composite structures package that provides mechanisms for the representation of the internal structure of classifiers, including components. In UML 2.0, a component is a modular unit of a system that encapsulates its contents behind the interfaces and is replaceable within its environment. A component has one or more provided and required interfaces, accessible through ports. Components can be composed together to form a coarser-grained component by wiring compatible required and provided interfaces of components being combined. A component can be also decomposed into finergrained components. A component interface specifies operations, attributes and signals that the component can provide and require. Interfaces of a component can be grouped into a port, which defines an interaction point between a component and its environment, or between a component and particular elements of its internal structure. A component can have additional behavior definitions to specify its external view more precisely, for example, by defining the sequence of operations on its ports and constraints related to this. Figure 2.4 shows an example of two connected components using a notation proposed by UML 2.0. The components are represented as rectangles with the stereotype . Optionally, a component icon as defined in UML 1.x can be displayed in the upper right corner of the rectangle, as a visual stereotype. A Port is represented as a square. A provided interface is 47

Chapter 2 modeled using the classical ‘lollipop’ notation and required interfaces using the ‘socket’, halfcircle, notation. IRequired1

«component» Component1 Port11 Port12

IProvided1 Port21 Port22 «component» IProvided2

Component2

Figure 2.4 Components in UML 2.0 To define how a component realizes its interfaces, the internal structure of the component is modeled using the concepts from the Composite structures package. The internal structure of a component can consist of instances of finer-grained components or of object-oriented constructs. A port of a component can be connected to the instances of the sub-components to indicate that a particular sub-component or other construct is responsible for the realization of interfaces provided at that port. Similarly, required interfaces from the port can be connected to an internal construct or sub-component, which actually requires it. Both the UML profile for EDOC and UML 2.0 propose new concepts and notation for representing components throughout the development lifecycle, and not only at the level of implementation and deployment, which was not the case with earlier CBD efforts. Furthermore, they are standardized or will soon be standardized. A lot of valuable EDOC features are incorporated in the UML 2.0 submission, and it is a common idea that the UML 2.0 specification will supersede the UML for EDOC specification. The UML 2.0 major revision includes many significant improvements over UML 1.x. For the purpose of this research the most important is the ability to represent a hierarchical decomposition of a system-of-systems into systems, subsystems, components, subcomponents, using Composite Structure diagrams and new constructs, such as Ports and Connectors. However, it is important to state at this point that, although both UML 2.0 and the UML profile for EDOC provide concepts, mechanisms and notation for the specification of enterprise-scale component-based solutions, they do not define a process, techniques and guidelines that prescribe how to create that system specification. Therefore, on top of the proposed component-based specifications, new design methods and techniques need to be

48

The State-of-the-Art of Component-Based Software Systems Development defined to construct complex software systems by using concepts and notation proposed in these standards.

2.8 State-of-the-Art Survey Findings The history of software development has shown that every new development paradigm, including the latest, components and Web services, was first introduced through the necessary technology infrastructure, and then, new methods and processes for supporting the whole development lifecycle started to emerge to make use of the available technology in the most effective way. Adoption of an appropriate, well-defined and well-documented development method is essential for successful delivery of software development projects (Butler Group, 2003). The role of the method is to align given business requirements to implemented solutions, to reduce the risk of project failures concerning the time and budget, to define clearly each person’s role in the project and to set a foundation for reusing design models and software code in the future projects. The component technology presented is already firmly settled into practice and used as a de facto standard for component-based software implementation and deployment. However, software entities being implemented as, for example, Enterprise Java beans do not a priori represent well-designed and properly encapsulated components with clear functionality and as few dependencies as possible with the environment (Apperly, 2003). Although application functionality is routinely "packaged" into components today, the essential development processes and approaches that enable application adaptability, widespread reuse and commercialization still have little acceptance (Atkinson et. al., 2002). Complex software systems need to be well designed before coding begins to gain the full benefit of a componentbased approach (Cheesman and Daniels, 2000). Similar issues arise with Web services. Although the standards and protocols for Web services are well established, a way of proper designing and architecting a service-oriented architecture is strongly required, before SOA is implemented using Web services technology (Kaye, 2003). As there is more to CBD than packaging software into Java beans or .NET components, there is more to SOA than simply implementing software entities by rendering interfaces as Web services. As pointed out in Apperly et al. (2003), Atkinson et al. (2002), Williams (2000), Herzum and Sims (2000), one of the biggest challenges facing component-based and service-oriented development is the lack of a methodology for building complex Web-enabled systems using the notion of components and services. The great potential of the component plug-and-play paradigm can be achieved only through appropriate modeling, architecture, design and deployment strategies, and not just at the level of packaging software (Dahanayake et. al., 2003; Berry, 2003). Since the principles for designing Web services and components are very much the same, the common conclusion is that classical CBD and OO methodology practice represents a solid foundation for a new service-oriented process (Apperly, 2003). However, further improvements and extensions of available methods must be made to use them to 49

Chapter 2 design and develop large-grained, loosely coupled enterprise components effectively that offer business meaningful value, are organized in a service-oriented architecture and are supported by the Web services technology (Kaye, 2003; Stojanović et. al., 2003b). In what follows, we will analyze the main characteristics of the six, representative and already presented CBD methods regarding their support to various aspects of components in order to highlight their shortcomings and drawbacks in that respect. The analyzed CBD methods are: Rational Unified Process (RUP), Select Perspective, Catalysis, KobrA, UML Components and Business Component Factory (BCF). This analysis will be used as a basis to derive a set of requirements for designing a truly component-based and service-oriented method that will be presented in the next section 2.9. 2.8.1 Analysis of the CBD Methods In general, evaluation approaches can be divided into three categories: formal experiment, case study and survey (Kitchenham, Linkman and Law, 1994). In the case of CBD development methods, formal experiment and full case study seem to be difficult because they require too much time and show a lack of sound metrics (Ham, Kim, Cho and Ha, 2004). For this reason, we analyzed and compared the given CBD methods according to certain characteristics that reflect their CBD nature and those we found important during the literature survey. It is important to note that two research works have been published treating an evaluation of CBD methods; these are (Dahanayake et al., 2003) and (Boertien, Steen and Jonkers, 2004). The conclusions of both evaluations are rather similar. First, CBD is still not fully integrated with development methods; components are just one of the many things considered. Second, components are poorly defined, which is a serious problem considering that they should be at the heart of these methods. Third, all the methods state that components should be throughout the development lifecycle, but are very vague on how this should be realized. These conclusions show clearly the immaturity of the current CBD methods. Analysis and comparison of these methods are further complicated by the fact that they are composed of informal descriptions, they treat components largely in a different manner, and each one has its own ser of definitions of the concepts and techniques used (Ham, Kim, Cho and Ha, 2004). Further, the methods often have different understandings of CBD objectives and what is meant by a component (Wallnau, Hissam and Seacord, 2001). This makes it difficult to provide a precise and detailed framework to evaluate CBD methods, in the situation when they do not share even the basic component ontology, they have different views on components, they use components in different manners and for different purposes, and the level of significance of the component concept within the methods is different. Therefore, an approach to comparing the methods based on their metamodels that are then confronted with an integrated, common metamodel, as done in (Hong, van den Goor and Brinkkemper, 1993) for the purpose of

50

The State-of-the-Art of Component-Based Software Systems Development comparing OO analysis and design methods, is difficult, if not impossible, to apply here because of the above reasons. We analyze the main characteristics, drawbacks and shortcomings of the presented CBD method along with the main elements of any method, namely: ♦ the way of thinking of the method - a conceptual schema that reflects a problem-solving approach; ♦ the way of modeling of the method – a language and techniques for expressing this conceptual schema; ♦ the way of working of the method – steps, heuristics and guidelines to put the schema into effect through a technical process; ♦ the way of controlling of the method – a management or lifecycle control process. 2.8.1.1 The Way of Thinking As already stated, the presented CBD methods are not primarily focused on components, which are just one among other concepts considered in these methods. The exceptions are UML Components, BCF and a new version of Select Perspective that propose a number of techniques, concepts and principles organized around the component paradigm (Ham, Kim, Cho and Ha, 2004). Components are not always defined in a consistent and precise manner in these methods, which can be a serious problem considering that they should be at the heart of these methods (Boertien, Steen and Jonkers, 2004). In Table 2.3, a summary of component definitions proposed by the given methods is presented. Table 2.3 Component definitions in the CBD methods Method RUP Select Perspective Catalysis

KobrA

UML Components BCF

Definition A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component is an executable unit of code that provides a physical black-box encapsulation of related services. A component is an independently deliverable unit that encapsulates services behind a published interface and that can be composed with other components. It is unit of reuse, composition and packaging. A software component is a unit of composition with contractually specified interfaces and context dependencies only. KobrA components represent a true union of the class and module concepts. A component can take many distinct forms: component specification, component implementation, installed component and component object. A business component represents and implements a business concept or business process that is relatively autonomous in the problem space.

51

Chapter 2 The definitions show clearly that these methods do not define the concepts of component and service in an implementation-independent way (Houston and Norris, 2001). This is the natural consequence of the fact that they have mainly evolved from the object-oriented background and therefore inherit difficulties in recognizing the fundamental nature of components, considering the componentization aspects as ways of code packaging (Wallnau, Hissam, and Seacord, 2001). For the purpose of using components during the whole development process it is important to make a paradigm shift from components as units of deployment to components as units of business functionality, i.e. to move the focus on components from the end of the development lifecycle towards its beginning (Endrei et al., 2004). Components are treated differently in different methods. In RUP, components are rather implementation artifacts, i.e. Java or DLL software packages that are independently deployed. This is a consequence of the way components are treated within the UML 1.3 standard that is used in RUP. In the other methods, components can be used in system analysis and design, represented as a stereotype of an OO concept of class (Catalysis, UML Components), as a subsystem (Select, KobrA), or as a business concept (BCF). The way different methods handle components for the purpose of analysis, design and implementation is shown in Table 2.4. Table 2.4 The way of using component within the methods Method RUP Select Perspective Catalysis KobrA UML Components BCF

Component representation in analysis and design Not applicable Stereotype of subsystem or class Stereotype of class ‘type’, a package that consists of objects and connectors Mix of class and subsystem; has properties such as inheritance and aggregation Stereotype of OO class - correspond to business objects Different types of components – business components, can be process or entity

Component representation in implementation Implementation artifacts, Java or DLL packages of code Component implementation package Implementation components, packages of software Physical components, include construction model and binary Physical components, COM+ and EJB Physical components, COM+ and EJB

As it can be seen from Table 2.4, the advanced CBD methods started using components during system analysis and design as design artifacts used to construct the system architecture. However, components in these methods are primarily identified based on underlying domain entities, such as Order, Customer or Account (Zimmerman, Korgdahl and Gee, 2004). Such components are too fine-grained and entity-oriented to be used effectively in the design and development of complex, Web-based and service-oriented applications (Apperly et al., 2003). Instead of encapsulating domain entities with component interfaces, which would result in a number of small components that manage corresponding domain data structures, coarser52

The State-of-the-Art of Component-Based Software Systems Development grained components that operate across several entity objects and provide a clear, value-added service should be created (Barn, 2004). Such components would represent a basis for organizing business meaningful services provided by these components within a serviceoriented architecture (Kaye, 2003). Next to this, it is important to highlight how these methods define and use the concept of component interface as one of the most important elements in component-based development, but also in service-oriented computing (Barn, 2004). A standard definition of an interface of a component or object in languages such as IDL and Java and in UML 1.x includes only a set of method signatures without related semantics, which usually is not sufficient information for a consumer to understand and use such a component (Quartel, Dijkman and van Sinderen, 2004). The CBD methods inherit this interface definition and some of them, in addition, specify preconditions and post-conditions related to interface methods and interface information types, as illustrated in Table 2.5. However, a more precise and semantically richer view on component interface is needed to use effectively and efficiently components made by a third party or Web services across the Internet (Endrei et al., 2004). This is especially important to be improved for using Web services, where specification standards, e.g. UDDI and WSDL, merely focus on specifying low-level interface definitions, which is not sufficient and expressive enough to provide understanding and using a Web service for inter-enterprise collaboration and integration (Zimmerman, Korgdahl and Gee, 2004). It is often the case in current CBD methodology practice that one type of component fits all. There is no clear definition of potentially different component types in terms of granularity and scope to be used throughout the development process by different stakeholders to address their particular concerns and needs. The way the CBD methods define different component granularity and types is shown in Table 2.5. Table 2.5 Component interface and granularity in different methods Method RUP Select Perspective Catalysis

UML Components

Interface Operation signatures only Operation signatures, pre- and conditions, information types Operation signatures, pre- and conditions Operation signatures, pre- and conditions Operation signatures, pre- and conditions, information types

BCF

Not precisely specified

KobrA

postpostpostpost-

Granularity and types No specific granularities No specific granularities; main types: business and technical components Continuous component granularities through refinements No specific granularities; aggregation and hierarchy between components defined No specific granularities; main types: specification, implementation, component object and deployed component Well-defined granularity types: component system, business components and distributed components

53

Chapter 2 It can be concluded that the given methods, with the exception of BCF, do not pay much attention to defining components of different granularity levels that can be potentially used in different phases of the development process. Specifying different granularity and types of components is widely recognized as an important step towards including components in the lifecycle and providing traceability of business requirements to implementation (Teale and Jarvis, 2004; Herzum and Sims, 2000; Carey and Carlson, 2001). Therefore, it is important to define the set of component types from coarse-grained, stand-alone enterprise components that can be exposed as Web services for the purpose of business process orchestration and integration (see Levi and Arsanjani, 2002) to fine-grained application components ready for implementation as e.g. Java beans (Wallnau, Hissam, and Seacord, 2001). New initiatives and standard specifications, such as UML 2.0 and the UML profile for EDOC, provide improved definitions of component concepts and mechanisms for handling components concepts throughout the lifecycle, from logical to physical software components. To our knowledge, no method has been proposed that uses UML 2.0 as a basis for its component way of thinking. It is worth noting that the UML profile for EDOC will be outdated with UML 2.0, in the sense that certain UML 2.0 component-related concepts will replace EDOC concepts. However, the upgraded version of UML 2.0 will not replace UML 1.5 until it completes its initial maintenance revision sometime around the end of 2004 or the beginning of 2005. Components in UML 2.0 are defined as larger-grained design-time constructs that will typically be implemented using “replaceable" modules. A component interface is enriched with additional elements similar to what is proposed in the UML Components method. Although, UML 2.0 provides mechanisms for designing the interior of a component in terms of collaborating finer-grained constructs, it does not define specific component types and granularity, which is left for a future method based on UML 2.0 to specify according to its purposes. Various concepts and techniques proposed in UML 2.0 to support components will be presented in more detail in chapter five. 2.8.1.2 The Way of Modeling Regarding the way of modeling, it is important to define proper modeling techniques and notations that satisfy the needs of all stakeholders in a development process, from business analysts to software developers. In this way, the main goals of the modeling activities in providing for common understanding and better communication across the project are well satisfied. The standard object-oriented modeling language UML is the basis for most of the current CBD methods and approaches. However, the currently standardized version of UML (this is version 1.5 at the moment of writing) does not provide the necessary modeling and specification constructs for representing various component and service concepts, mainly as a result of its OO focus and of it introducing component concepts as afterthoughts (Apperly et al., 2003). The standard UML offers a number of extension mechanisms that enable the user to extend the UML foundation with new modeling constructs according to his/her purposes. The way of modeling of the CBD methods related to component concepts is shown in Table 2.6. 54

The State-of-the-Art of Component-Based Software Systems Development All methods are based on UML, but use different techniques to represent components depending on their view on components. This varies from UML component diagrams used for representing implementation aspects to stereotypes of the UML concepts of class and subsystem. Collaboration between components is also expressed in different ways, reflecting a particular method’s view on this subject. Finally, although considered to be crucial for using third-party components and Web services across the Internet, defining a precise component specification is not well supported by the methods (Conrad and Turowski, 2003). Table 2.6 CBD methods’ support to component modeling Method

Modeling techniques used

Component representation

RUP

UML

Select Catalysis

UML, ERD UML

UML physical component Subsystem

KobrA

UML-based

UML Components BCF

UML with extensions UML-based

Catalyst,

‘Type’ stereotype of class, package Subsystem and/or class ‘Component’ stereotype of class Free-form notation

Component collaboration modeling Component diagram Collaboration diagram Using ports and connectors Aggregations and hierarchy Provided and required interfaces Provided and required interfaces

Precise component specification No To some extent No No To some extent To some extent

Today, the emerging standard OMG specifications, such as the new version of UML 2.0 and the UML profile for EDOC provide more sophisticated modeling notation and mechanisms for modeling and specifying different aspects of components. No method has been proposed based on UML 2.0. Perhaps new versions of some of these methods, for example Select Perspective, will adopt UML 2.0 as a modeling standard. Beside a graphical notation, it is possible to offer a human-understandable textual notation by extending an IDL-like language, and a machine-readable notation based on XML that extends e.g. WSDL. These different, but mutually related and isomorphic, modeling notations are able to serve the needs of different actors in a development process. A human-understandable textual notation is a way to represent the models in a textual form, which is very much like a pseudo-code. It is programming language independent, but can be mapped easily to a programming language of choice. The example of this is IDL, a new version of 3.0, proposed for CORBA components to specify component interfaces (Siegel, 2000). It can be a basis for more formal specification language for specifying components and services in a clear, precise and detailed way. For the purpose of Web service specification, WSDL is normally used today (W3C-WSDL, 2004). However, it lacks certain properties and expression mechanisms, such 55

Chapter 2 as preconditions, post-conditions to become a real contract-based (Barn, 2004; Kaye, 2003). It also lacks certain coordination mechanisms that specify the time order of functions in the service interface so that it must be accompanied with e.g. WSCI or BPEL4WS to express these properties (Berry, 2003). WSDL can be further enriched with the non-functional parameters and configuration parameters to provide a complete specification of a Web service used across the Internet and adaptable to different contexts of usage. Having these various modeling techniques is especially important for the purpose of modeldriven development to create models at different levels of abstraction, starting from UML and ending in IDL or WSDL before implementing a component or a Web service respectively (Zimmerman, Korgdahl and Gee, 2004; Endrei et al., 2004). Although there is no support for specifying components using IDL or WSDL in these methods, some of them claim to support certain elements of model-driven development, namely KobrA, UML Components and to some extent Catalysis through model refinements. For the purpose of MDA it is interesting to provide mappings between these different notations. Some initiatives for UML to IDL mapping have already been proposed in the past. Some initiatives are under way to provide mapping between the models expressed in UML to the models readable by computers in the form of XML-based language for the purpose of web services (Gardner, 2003). This might represent the basis for future model-driven design and development of SOA. As already stated, the new major revision of UML, version 2.0, proposes a number of modeling techniques and elements to represent various component-related concepts. A more detailed presentation of this will be given in chapter five. 2.8.1.3 The Way of Working The way of thinking of a method guides the software development process through the set of activities needed to transform a user’s requirements into a software system (Jacobson et al., 1999). A method’s way of thinking defines a predefined and organized collection of techniques and a set of rules which state in which order and what way the techniques are used to achieve or maintain some objectives (Tolvanen, 1999). We analyze here only the elements of the CBD methods’ ways of thinking that are related to different aspects of components, e.g. how components are identified, specified and implemented or whether there are techniques for mapping between component models at different levels of abstraction as a basis for modeldriven development. The way the presented CBD methods treat components is closely related to the way they define component concepts and to the role components have within these methods. The CBD methods and approaches proposed so far, especially those based strictly on UML 1.x such as RUP, use mainly components as the way of packaging software code in the final phases of the development process.. Components are often used late in the lifecycle, for the purpose of encapsulating highly cohesive objects and deploying them on the distributed computing resources (Houston and Norris, 2001). In this way, the current CBD methodology practice 56

The State-of-the-Art of Component-Based Software Systems Development does not fully recognize the power of component and service concepts to represent a common ground between business and IT and the way of balancing business service needs and software entities supporting these needs (Endrei et al., 2004). The way the presented CBD methods support various aspects in of the component lifecycle and the development process, namely component identification, analysis and design, and implementation, is analyzed in Table 2.7. Components are often identified late in the development lifecycle as potential code packages, or based on domain entities during the system analysis and design. The CBD methods do not truly recognize one of the roles of components and services to provide a bridge between the requirements and software architecture. As stated in Zimmerman, Korgdahl and Gee (2004) the components and services they provide can represent a way to organize business requirements in a way to be meaningful for both a business analyst on the one side and a software architect and developer on the other side. Table 2.7 Support of the methods for the elements of the component lifecycle Method RUP Select Perspective

Component identification Packaging related software objects together Based on domain entities

Catalysis

Based on domain entities

KobrA

Based on domain entities

UML Components

Based on domain entities and use cases

BCF

Based on business entities and processes

Component-based analysis and design Not performed Structural and behavioral, using stereotypes of classes, subsystems and interaction diagrams Structural and behavioral, using OO types, classes and collaborations Structural and behavioral, using OO concepts of hierarchy and aggregation Use OO-UML modeling techniques, concepts and specification Define different component types used within different layers of architecture

Component implementation Use component technology Use component technology, EJB and .NET

Assume using the component technology Assume using the component technology Not specified

Assume using the component technology

New component-based and service-oriented technology and standards are constantly emerging. Therefore, it is important that the approach is technology-independent but that it is able to provide mapping of complete and precise component-based system specification to any of the available component implementation models, .NET, EJB or CCM, using transformation patterns, decomposition and implementation rules in an iterative and incremental development 57

Chapter 2 manner (Kruchten, 2003). The main artifacts of the approach are models at different levels of abstraction. This suggests using the concepts and principles of Model-Driven Development. However, the CBD methods do not define mechanisms and techniques for effective transformations of component models at different levels of abstraction and the generation of component implementation code based on the models (Frankel, 2003). Today, one of the challenges for Web services to become a reality rather than hype is the lack of a design and development process (Kaye, 2003; Endrei et al., 2004; Zimmerman, Korgdahl and Gee, 2004). The real benefits of the component and service way of thinking can only be achieved if the components and services are properly identified, specified, designed and then implemented. New technology offers a lot of advantages in business applications engineering, but only a well-articulated design approach provides a real business value out of IT infrastructure. Therefore, the component and service concepts need to be integrated into each of the phases of a development process in a more formal and systematic way than before (Taele, 2004). The current CBD approaches can be used as a basis for the purpose of designing a service-oriented architecture, but they must be extended with new concepts, strategies and techniques that bring service and component concepts above low-level implementation issues and closer to the business user. An analysis of the variety of support mechanisms and techniques, potential or real, defined in the CBD methods for the purpose of the component-based development process, MDD and Web services is given in Table 2.8. Table 2.8 Support of the methods for the development process, MDA and Web services Method RUP Select Perspective Catalysis

KobrA UML Components BCF

58

Component support in a development process Implementation and deployment Detailed design and implementation Partially in analysis and design, and implementation Design and implementation Analysis, design and implementation Analysis, design and implementation

Potential support for MDD New version of RUP with UML 2.0 probably Partial support, some model transformations defined Use pre-MDA strategy of model refinements Claim the support, in reality only the basic one Well-equipped to support model transformations Has some potential, happened before MDA hype

Potential support for Web services Not really defined New version has a built-in support for services Does not consider Web services, happened before Does not consider Web services Has a potential documented in later publications Does not consider Web services, but it can be adapted to support them

The State-of-the-Art of Component-Based Software Systems Development Another potential drawback of the current component-based methods is their complexity. The size of the methods makes it difficult for users to understand them easily and to apply them correctly in practice. These methods are often founded as a semi-structured set of design principles, advice and patterns, scattered throughout the system development lifecycle, rather than as a set of predefined, prescriptive guidelines and well-defined method steps with wellcontrolled inputs and outputs of the steps. That is especially true for Catalysis, KobrA and BCF. The methods define a number of modeling artifacts together with a complex way of using them, which results in low flexibility and adaptability of the methods and developed system solutions. These characteristics make such methods difficult to apply in practice where projects can vary greatly in size, complexity, available time and the structure of project teams (Ambler, 2002). Therefore, it is important to design a method that is lightweight, workable, practical and easily used in, and adapted to, varying circumstances (Boertien, Steen and Jonkers, 2004). A CBD method, that has a set of clear and prescriptive steps and activities, is easy to understand and practice, and flexible enough to match the needs of different projects would have real value for the success of real-life CBD projects (Ham, Kim, Cho, and Ha, 2004). As already stated in section 2.4, all the CBD methods propose techniques and guidelines to ensure incremental and iterative development to ensure that the software functionality produced that is produced matches, as closely as possible, given business requirements and goals of the user. Although UML 2.0 and the UML profile for EDOC have brought new developments in the way components are defined and modeled, they do not specify any particular way of working, i.e. the way these concepts and notation can be used within the development process in the form of a set of activities, steps, guidelines and rules. 2.8.1.4 The Way of Controlling Concerning the way of controlling, a successful approach defines a set of directives and guidelines for managing the component-oriented development process focused on components and their collaborations as the main artifacts of the development process, together with the management of time, resources and quality aspects. This aspect is largely not supported sufficiently by the CBD methods proposed so far (Wallnau, Hissam, and Seacord, 2001). Some of the CBD methods, e.g. RUP and BCF, provide certain elements of the management process, where some of them in BCF are focused especially on component-based aspects of the process. Among the most important aspects to consider are: the roles of people related to different facets of components during the lifecycle, the results of the development process phases in terms of components, and time and quality management regarding component design, implementation, testing and maintenance (Boertien, Steen and Jonkers 2004). A component-based management process can inherit easily the elements not particularly related to components from e.g. the RUP process. 59

Chapter 2

2.9 CBD Method Requirements As stated in the first chapter, we followed an inductive-hypothetic research strategy in this research. Therefore, a first step was to perform an extensive literature survey of CBD, concepts, definitions, principles and practices. Then, we conducted an analysis and evaluation of existing CBD methods based on their main characteristics, advantages and shortcomings, using a subjective/argumentative approach, discussions and interviews with experts and students and experience culled from their applications in case studies published in the literature. Based on these findings, we defined a set of requirements that a component-based design and development method should fulfill to gain the full benefits of component and service thinking throughout the development process. These requirements for a CBD method have been published in (Dahanayake et. al., 2003) and (Stojanović et. al., 2004a). First, we will present the set of basic method requirements that are common for any advanced software development method today. Then, the method requirements related to different aspects of component-based and service-oriented paradigm will be given. These requirements are organized into the four concerns, i.e. way of thinking, way of modeling, way of working and way of controlling, defined in (Sol, 1990) as a complete set of fundamental aspects that characterizes an information systems development method. 2.9.1 Basic Method Requirements In terms of general quality properties of a component-based system design and development method, it is important that a method is designed to posses a set of essential characteristics, similar to the goals set when designing the KobrA method (Atkinson et. al., 2002). A method needs to be: ♦ simple – the method should define a minimal set of coherent concepts, principles and design guidelines. The simplicity of the method is the key for its wide and effective usage in practice. ♦ systematic – the method should provide a stepwise process to guide the development of models, in which details are added systematically according to the objectives or intended use of the models. An approach should prescribe what should be done and in what way to produce models, rather than describe what may be done. ♦ flexible - the method should be used in a variety of situations, easy to modify and adapt to satisfy a particular purpose. ♦ scalable - the method should be scalable both with respect to granularity and complexity of the problem domain. ♦ practical - the method should be applicable in practice in an easy and effective manner. It should be compatible with the current achievements in development practice, available technology and system specification standards.

60

The State-of-the-Art of Component-Based Software Systems Development 2.9.2 Requirements for Component-Orientation Based on the literature survey findings we define the following set of requirements that a fully component-based and service-oriented method should fulfill to gain the maximum benefits of the component and service thinking, from organizing business requirements into a consistent and well-structured service component architecture, to implementation of this architecture using advanced component and Web services technology. The requirements are categorized into the way of thinking, the way of modeling, the way of working and the way of controlling. The underlying way of thinking of a CBD method should support the following: ♦ the component as a focus of a development process; ♦ clear, consistent and technology-independent definitions of the component concepts; ♦ an enriched and enhanced definition of a component interface that is beyond the simple list of operation signatures, and above the pure technology level; ♦ service-based components, rich in behavior and functionality, rather than data-driven components that only consist of data attributes and set and get operations on this data; ♦ different types, scope and granularity of components to fit into different phases and aspects of the system development lifecycle; ♦ different perspectives on components, such as conceptual, logical, implementation, deployment, to make the component concept traceable from business concepts to deployment. The underlying way of modeling of a CBD method should support the following: ♦ a graphical component modeling techniques and notation, using for example UML with extensions; expressive enough to provide communication and understanding among different actors in the development project; ♦ a textual component modeling techniques and notation that can be understood by human actors and mapped easily and straightforwardly to programming language constructs, using IDL or template-based forms; ♦ a machine-readable component modeling techniques and notation that can be used for communication between automated systems, i.e. an XML-based extension of WSDL; ♦ a means to model various aspects of components in a clear and consistent way; ♦ a means to model collaboration, coordination and (de)composition of components in a clear and appropriate way; ♦ rigorous component specification that enables the consumer to use the component without knowing how it is realized internally, e.g. as a legacy asset, a Web service, a COTS component, or a simple application. The underlying way of working of a CBD method should support the following: ♦ the full component lifecycle from identification to realization; ♦ component concepts in all the phases of a development process, from business to implementation; 61

Chapter 2 ♦ ♦ ♦ ♦ ♦

business-driven identification of components so that components are identified as providers of services that satisfy business goals and subsequently refined into application and implementation artifacts; the integration of different viewpoints on the component architecture, business, information, application and implementation, to give a coherent system architecture specification using components; implementation-independent component-oriented design that can be mapped onto the technology of choice; iterative and incremental component-based development process combined with regular iterations, small increments and frequent prototyping; flexibility and adaptability of the component-based development process .

The underlying way of controlling of a CBD method should support the following: ♦ managing and measuring the progress of component-based project activities, and planning deliveries of artifacts; ♦ determining human roles in the component-based project, guide team activities, and allocate resources to team parts. 2.9.3 Evaluation of CBD methods We will now give an evaluation of existing CBD methods set against the requirements defined above. This evaluation is based on the CBD method evaluation given in (Dahanayake et al., 2003) and refined slightly to adopt some new developments in the field, such as Web services. The evaluation given in (Dahanayake et al., 2003) is based on a combination of the evaluations of master students on the course related to systems analysis and design at Delft University of Technology, experts in the field and of the authors, based on their experience with the methods discussed and extensive literature studies. The experts were asked to evaluate only the methods they were familiar with, while the students were presented with the main characteristics of all the methods. The evaluations of the different target groups, experts, students and authors, were similar in most cases, in a few cases, where the difference was greater than two points, an average was taken. Discussions with the experts and students helped us to refine and strengthen our CBD method requirements. A summary of the evaluations of the CBD methods, RUP, Select Perspective, Catalysis, KobrA, UML Components and Business Component Factory (BCF) is presented in Table 2.9, in which: ♦ ‘-’ indicates a method does not match the requirement, i.e. the requirement is poorly supported, not supported, or not applicable at all; ♦ ‘+’ indicates a method matches the requirement to some extent, i.e. the requirement has been supported and/or defined informally or in an inconsistent manner; ♦ ‘++’ indicates a method matches well the requirement, i.e. the requirement is supported in a satisfactory and well-defined way.

62

The State-of-the-Art of Component-Based Software Systems Development Note: the UML 2.0 and the UML profile for EDOC specifications define a conceptual framework and a modeling notation for components, but do not provide a development method or stepwise process guidelines for building applications using these concepts and notation. Therefore, these specifications are not taken into account here. Table 2.9 Evaluation framework and the evaluation results of the CBD methods Way of thinking The component as a focus of a development process Clear, consistent and technology-independent definitions of the component concepts Enriched contract-based component interface construct Focus on service-based, rich-in-behavior components rather than simple data components Defining different scope and granularity levels of components Defining different perspectives on components

Way of modeling An appropriate graphical component modeling techniques and notation Human-understandable textual component modeling techniques and notation Machine- readable component modeling techniques and notation Modeling various aspects of components in a clear and consistent way

RUP _

Select Perspective ++

_

+

_

++

_

Catalysis KobrA + +

+

UML Components ++

BCF ++

+

++

++

+

+

++

+

+

+

+

+

+

_

+

+

_

_

++

_

+

+

+

++

++

RUP +

Select Perspective ++

_

Catalysis KobrA

UML Components ++

BCF

+

+

+

_

+

+

+

_

+

+

_

_

_

_

_

+

+

+

+

++

63

Chapter 2 Way of modeling Modeling collaboration, coordination and (de)composition of components Providing the rigorous component specification Way of working Covering the full component lifecycle Component concepts in all the phases of a development process Business-driven identification of components Integration of different architectural viewpoints using components Implementationindependent componentoriented design Iterative and incremental component-based development process Flexibility and adaptability of the development process Way of controlling Management and measurement of the progress of project activities Determine human roles in the project, guide team activities, and allocate resources

RUP _

Select Perspective +

_

++

RUP _

Select Perspective +

Catalysis KobrA +

+

+

+

Catalysis KobrA _

+

UML Components _

++

UML Components ++

BCF +

+

BCF ++

_

+

+

+

++

++

_

+

+

+

+

+

_

+

+

_

_

+

+

++

+

+

++

+

++

++

++

++

++

++

+

+

+

+

+

+

RUP +

+

Select Perspective +

++

Catalysis KobrA _

+

_

_

UML Components _

_

BCF +

++

2.9.4 Evaluation Findings Summarizing our findings, we see that the concepts and principles of CBD and SOA are not fully integrated as yet in the investigated methods. Components and services have not yet 64

The State-of-the-Art of Component-Based Software Systems Development become the real focus of the methods. The concepts of component and service are not defined properly in such a way that the definitions can be used effectively throughout the development lifecycle beyond pure implementation aspects. Semantics and characteristics of components and services are mainly defined informally using prose text. More recently, CBD method developers have proposed an extended version of the interface concept beyond simple signatures of operations. They specify pre-conditions and post-conditions on operations, and information type models of the interface, but still lack, among other things, the coordination aspects of operations, configuration mechanisms and non-functional parameters. The importance of defining different scope and granularity levels of components and their recursive composition, has been truly recognized only in the Business Component Factory approach. Regarding the way of modeling, the investigated methods are based on the current version of UML (1.x) and corresponding extensions are defined to represent the necessary component and service concepts these methods use. Modeling from different viewpoints is an important mechanism in the Business Component Factory. Rigorous component specification is to some extent provided in Catalysis and UML Components, while model reusability is an important aspect of Select Perspective. The collaborations and choreography between components and services are not well specified in the methods. Although the collaboration concept is a firstclass citizen in Catalysis, this is still at a lower level of abstraction than needed for the purpose of defining a truly service-orientated architecture. Regarding the way of working, the more recent CBD methods (UML Components, KobrA, Business Component Factory) provide more complete component and service lifecycles and traceable component concepts from business to technology. Business-driven and behaviordriven identification of components and services is not yet fully supported by the methods. Modeling from different viewpoints becomes an important mechanism in managing system complexity by separating the concerns. The techniques for the transformations of models that are at different levels of abstraction and their further mapping to software code are not yet fully supported by the methods. All of the methods provide an iterative and incremental development practice that is a de facto standard in software system development. However, the methods presented are inherently complex, monolithic and therefore not flexible and adaptable enough to satisfy the needs of development projects of different scales. These characteristics make the methods complex and difficult to utilize in today’s business environment where system solutions and the methods required to build them should be adapted as business changes: Catalysis (D’Souza and Wills, 1999), KobrA (Atkinson et al., 2002) and the Business Component Factory (Herzum and Sims, 2000) are all characterized by complexity and inflexibility The way of controlling of the investigated methods should be further improved in the spirit of CBD. The ways of measurement for non-functional process parameters and a proper process management approach must be specified in a more effective way. 65

Chapter 2 2.9.5 Conclusion Based on the review and evaluation, we argue that, to improve current CBD and serviceoriented computing theory and practice, a new component-based and service-oriented design and development method is required. The requirements classified into ways of thinking, modeling, working and controlling of the method defined above provide guidelines towards a systematic and integrated approach to component-based development. The requirements have the potential to provide comprehensive, theoretical and practical methodological support for the CBD and Web services paradigms, and can be seen as a first step towards arriving at truly component-based and service-oriented systems development methodology engineering. Following the requirements defined using the framework of the ways of thinking, modeling, working, and controlling, we can create a method that can be fully applied in CBD and the new service-orientation paradigm. The new CBD method that we propose should cover the whole system lifecycle with the component concepts and principles integrated in each of the phases in a consistent and systematic way. Integration of business, information, application and technology concerns must be provided effectively. This can be done using general, well-grounded and technologyindependent component theory, as the means to bridge the different perspectives and viewpoints. A common CBD “language” that can be used throughout the life cycle for the integration of different principles, concepts and perspectives, and a smooth transition between the different principles must be ensured. Finally, the approach that we propose should support effective business-IT alignment, by defining concepts, languages and modeling notations that seamlessly integrate business and IT concerns. At the same time, the method provides a way to map business requirements into software implementation using components. The method enables a higher-level of flexibility of software solutions to satisfy changing business needs by simply reconfiguring components, services and their collaboration and coordination. With respect to the way of thinking and the way of modeling of a component-based design and development method we propose in this work, the promising standardization efforts made recently, the UML profile for EDOC and the new version of UML 2.0, need to be taken into account. We plan to utilize certain concepts and modeling notation proposed in these standard specifications for defining the component-oriented way of thinking, modeling and working, and to make these the cornerstones of our component-based design and development method. In the following chapter a case study on building an Airport Business Suite is analyzed to get more insight into the necessities for a component-based approach when designing a complex software architecture. Further insight is needed into modeling and specification elements required for precise specification of the application ready to be implemented in any technology, and into the design steps that are necessary to be taken from business requirements to implementation. The needs for an effective CBD approach in the ABS project is identified using the framework of requirements defined in this chapter along the ways of thinking, modeling, working and controlling. 66

3 Component-Based Development in Practice A case study of the Airport Business Suite (ABS) project that was carried out at the Delft University of Technology by the Airport Development Center (http://www.adc.tudelft.nl) is investigated in this chapter. Possibilities, characteristics and potential benefits of a componentbased strategy used in the project of building this complex system, that involved a number of stakeholders and was limited by the short time-to-market, are explored. The underlying motivation for this investigation was to support the findings from the literature survey given in chapter two in the form of the set of requirements for creating a truly component-based and service-oriented design and development method. This motivation was accomplished by justifying the method requirements using the experience gathered through, and conclusions derived after, following an intuitive CBD strategy in this real-life project. Besides being an observer, the researcher also actively participated in the ABS project becoming involved in theory application, prototype implementation and testing.

3.1 Airport Business The airport business is dynamic, competitive, complex and unpredictable. The development and growth of any large airport depends on its ability to balance business realities, long-term expansion requirements and societal requirements. An integrated set of models, called the Airport Business Suite (ABS), has been developed, that can help advisors involved in Airport Strategic Exploration (ASE) quickly and easily to explore future scenarios and policy options, to improve understanding and insight into the main business drivers and risk factors and to generate information for decision making in an efficient, effective and consistent manner (Walker et. al, 2003; Visser et. al., 2003). 3.1.1 Airport Strategic Exploration The ability of the air transport system as a whole to accommodate market-driven growth in traffic demand depends, to a significant extent, on the available capacity of the airport infrastructure. In recent years, opportunities to accommodate this growth have become increasingly more restricted due to environmental and safety constraints. If the resulting mismatch between demand and capacity is allowed to grow unchecked, this will lead to significant increases in congestion at the major airports, with obvious consequences for the efficiency of the airport operations, and for the level of service that can be provided to the traveling public. Congestion represents just one of the issues the airport business community 67

Chapter 3 is currently confronting (Walker et. al., 2003). In the last decade, the airport business environment has become highly competitive, complex, dynamic and increasingly more unpredictable. Development and growth of any large airport will thus heavily depend on an ability to balance business realities, long-term expansion requirements and societal demands. The main objective in airport strategy exploration is to determine how the airport organization can create added value in a sustainable way by accommodating a specified (but uncertain) future market demand. This means it is necessary to decide what resources have to be made available and which policies should be pursued over time to accommodate market demand in a way that creates the best potential for sustainable added value for the airport. To achieve this objective, management teams need to evaluate a variety of options over a time horizon of years to decades, which is the typical time-scale for airport adaptations like runway additions or terminal expansions. An airport manager with decades of experience on ASE processes was consulted to help us develop a causal map driving the strategic objective of sustainable airport development for the purpose of the ABS project, as presented in Figure 3.1 (Walker et. al., 2003). Other practitioners with experience in ASE processes validated the resulting map. The key factors covered in the map are: market demand, capacity supply, airport services and products, and financial performance. It is possible that the experts’ judgment of the map’s validity may change over time, due to changing insights into the dynamics of airport systems. Furthermore, the causal map is largely based on insights developed at one specific airport. As such, the map cannot be guaranteed to be applicable to other airports. However, the map is expected to be applicable to a number of commercial airports (Visser et. al., 2003). Operational costs

Turnover

Investments Retail Real estate

Airport fees Flights

Desired Schedule Capacity / Quality

Regulation

Capacity scenario

Pax

Freight

Market scenario

Figure 3.1 Interrelationships among key airport business factors

68

Component-Based Development in Practice 3.1.2 A Support for Airport Strategic Planning Although airport strategic planning problems are often amenable to analytical treatment, they seldom have a linear, pre-determined path for problem solution or plan evaluation. This classifies them as ill-structured problems (Simon, 1973). In general, an ill-structured problem cannot be solved in a straightforward manner. Using simplification and structuring techniques such a problem is decomposed into several well-structured problems. Simplification and structuring, however, imply ignoring some aspects of the problem, while stressing others, and therefore significantly affecting the outcomes of the analysis. Human judgment is thus required to assess the validity and consequences of such analytical assumptions. Moreover, insight regarding the validity of these assumptions may change during the process. Flexibility, with regard to analytic assumptions and their consequences, is therefore required (Walker et. al., 2003). Given these constraints, computer-based support could provide real value when performing the analytical tasks involved. Keen and Sol (2004) define Decision Enhancement Services (DES) as a composite of methods and tools built on a fusion of people, process and technology for dealing with ill-structured problems. DES is considered as a suitable way to benefit from the computer’s analytical capacities while preserving the primacy of human judgment. The ABS project participants decided that a DES approach could improve ASE’s efficiency and effectiveness by: ♦ providing models for rapid estimate calculation of the various aspects of performance of the airport system under a range of user-defined situations; ♦ providing different levels of aggregation, to do quick initial scans and more detailed analyses when required; ♦ maintaining consistency among all of the models; ♦ presenting information on the full range of decision-relevant criteria in an integrated, easy to understand format; ♦ presenting information on the main factors driving decision-relevant criteria, to identify bottlenecks; ♦ preserving decision-making memories of results for cases already run; ♦ enabling fast and thorough comparisons of any number of ‘what-if’ cases. The Airport Business Suite (ABS) was developed to provide a DES for airport strategic exploration, to realize the aforementioned benefits (Visser et. al., 2003). Its target users were the advisors of decision-makers involved in ASP, since they were expected to benefit most from the analytic capabilities offered by the ABS. An important part of the ABS’s functionality is realized by an integrated set of models designed to provide the information needed by airport strategic planners. The other components of the ABS facilitate the use of the model system and enable the users to design, run and compare cases based on various preconditions and criteria. The main design and development principles and elements of the ABS are described in the next sections. 69

Chapter 3

3.2 The Airport Business Suite The ABS is a computer-based system for decision support that enables the advisors of an airport’s strategic decision-makers to obtain, through a single graphical user interface, consistent information about all facets of the airport’s present business and for future situations at the desired level of aggregation. The main properties of the ABS structure and the prototype implementation will be presented in this sub-section. 3.2.1 The System Structure The purpose of the ABS is to provide support for analyzing the various facets of airport business, i.e. a wide range of operational and strategic problems at the appropriate level of aggregation. Due to the inherent complexity and comprehensiveness of the problem and the solution being developed, the strategy of ‘separation of concerns’ was applied at the beginning. The ABS was initially divided into the five main functional units (modules) or models as called by the project members (Visser et. al., 2003). These models were specified according to the knowledge of domain experts who decided what the functionally and semantically separated important concerns of the airport business are. This division of the ABS domain into the models resulted directly from the representation of the airport business process shown in Figure 3.1. The five high-level ABS models, shown in Figure 3.2 are: 1. Unrestricted demand for airport capacity 2. Supply of airport capacity 3. Matching demand and supply 4. Airport turnover 5. Investments and operational costs

Models

5 Investments 5 Operational

costs

1. Demand for airport capacity 4 Turnover

2. Supply of airport capacity

3. Matching demand and supply 3

Flights

4. Airport turnover 2

Available capacity

1

Desired schedule

5. Investments and operational costs

Figure 3.2 Five high-level models of the ABS

70

Component-Based Development in Practice The business process and the models are related in the following manner. At the beginning, an unconstrained primary demand for air transport is transformed into a desired schedule for flights at the airport by airlines (Model 1). The airport’s capacity depends on its physical and operational situation, quality requirements, and government regulations (Model 2). Model 3 directly involves the user in the analysis process. The user is enabled to inspect the match between unconstrained demand and available capacity. It is then up to the user to decide whether it makes sense to continue the analysis in the current scenario. At this stage, the user is allowed to make changes in the flight schedule that reflect strategic choices related to flight schedules, aircraft characteristics, and airline networks. This should allow the user to gain insight into decisions regarding the types and amounts of demand the airport would like to accommodate. The user can make changes in the airport’s infrastructure, i.e. in numbers of runways, use of runways, sizes of terminals, allocation of space in terminals, etc., to investigate the best way to accommodate this demand. The user can also make changes in the airport’s revenue and expense structure to investigate the financial viability of the policies being explored and ways to increase revenues or reduce costs. Flight activities generate airport fees and passengers generate revenues at the airport’s shops. Furthermore, indirectly, real estate activities lead to real estate income. All of these revenue sources are combined into the total turnover for the airport (Model 4). Excluding a shareholder margin, the turnover is then used to pay for the operational costs of running and maintaining the airport and to acquire new facilities and infrastructure to improve the capacity and/or quality of the airport (Model 5). 3.2.2 Prototype Implementation Currently, two ABS prototype implementations have been developed, both for a hypothetical airport. The first prototype was developed around a fixed user interface design and a hardcoded implementation of models, primarily implemented in the Borland Delphi programming language. The second prototype was developed as an integration of previously developed prototypes of the individual models under a common user interface based on Microsoft Visual Basic controls and forms. This version includes fully integrated working versions of all five models. Both prototypes are, therefore, able to facilitate an analysis of the entire business process depicted in Figure 3.1. The second prototype has the following characteristics. ♦ It supports the detailed evaluation of scenario cases, providing results in several categories and formats under user control. ♦ Substantial numbers of policy options are available for the user to use in his/her strategy explorations, e.g., modifying the network, adding runways, changing fees, eliminating flights. ♦ Although the models are linked in an integrated system, they exist as separate modules, which allows for easy maintenance and replacement.

71

Chapter 3

3.3 Design and Implementation of the ABS Rather an intuitive and loose, than a disciplined and well-defined CBD strategy was used within the ABS project. One of the reasons for this was a limited project time and the need to build a prototype and a working system as soon as possible. The other reason is certainly a partial lack of expertise in software architecture and development methodologies and willingness to apply them among involved domain experts and software engineers. Using the simple modular approach that divided the problem and the solution into the models as presented above, the ABS is designed to be easy to modify to meet changing needs. It can be used to deal with unanticipated problems and it can be adapted as circumstances change (Visser, et al., 2003). These requirements for flexibility, adaptability, and easy maintainability led to a system that is built out of integrated models designed for specific purposes, instead of being built as one, or a few, complex and monolithic models. Furthermore, this modular approach makes it easier for domain experts to understand and justify the models built into the suite, their interconnections and functional roles within the ABS (Walker et. al., 2003). 3.3.1 The Basic Component Architecture of the ABS The initial design decision to divide the ABS into five components, called models by the ABS project members, had a positive influence on the design and development of the ABS. At the same time, it formed the basis for introducing a component way of thinking in designing and implementing the ABS. Although it was not the original intention of the domain experts in the project to follow explicitly a CBD paradigm, separating the solution into components and further decomposing these components into finer-grained components is the natural approach to follow according to general system requirements given above and in (Walker et. al., 2003). The ABS architecture consists of five main components. These components were basically identified in a top-down fashion as a result of the grouping of business functionality given in the ABS business process and defined by the domain experts involved in the project, as illustrated in Figure 3.1. The knowledge of the domain experts in the project was used for component identification and specification, while some elements of technological reality were taken into account (bottom-up strategy), such as the functionality already implemented by others and used in the project as Commercial Off-The-Shelf (COTS) components. The high-level component architecture of the ABS, which consists of the five main components of the system together with collaborations and relationships between components, is shown in Figure 3.2. These components are considered to be logical in a completely technology-independent manner. Therefore, a computing infrastructure and programming facilities were not taken into account during the analysis phase of the project. The defined model components are well encapsulated and autonomous but not independent since the model components must collaborate to produce the ABS functionality. The main challenge in defining the component architecture is to define the interfaces of the components in a clear 72

Component-Based Development in Practice and precise way to reflect the roles of particular components inside the ABS. It is necessary to keep these interfaces stable and well defined during the project lifecycle. Each change of an interface due to adapting to new requirements has to be agreed between the component providing that interface and the component(s) using the interface. In this way, the changes of functionality according to new requirements are localized on the interfaces between components without affecting a components’ interior in an uncontrolled manner. 3.3.2 Decomposition of the Main Model Components The five main components were further decomposed into lower-level components. This decomposition was done using a combination of top-down and bottom-up criteria. From the top-down perspective the decomposition of the components into subcomponents was done by identifying encapsulated units of functionality that fulfill a clear and well-defined role in the business context of the ABS. This was done by the domain experts involved in the project. Note that the existence of already implemented functionality influenced this decomposition. Existing legacy assets are encapsulated using well-defined interfaces to the rest of the system and therefore represent black-box components of the system. For example, the goal of the model component 1, namely demand for airport capacity, is to produce a flight schedule, based on models of unrestricted demand for air-travel. This model component is decomposed into three lower-level components, the Unrestricted Demand Model (UDM) component, the Frequency Demand Model (FDM) component and the Flight Scheduling Model (FSM) component, shown in Figure 3.3. The UDM component gives a forecast of unconstrained primary demand for air transport from, to, and through an airport, based on the predictions of particular socio-economical factors, such as expected GDP growth compared to the situation today, airline service levels, passenger profiles per route and the development of fast train connections in the future. The UDM component was developed by the University of Amsterdam and used as a COTS component in the project. The interfaces of the other components were adjusted according to the functionality provided by the implemented UDM component. The FDM component is used to produce a forecast of unconstrained demand based on particular technical factors. There was no available realization of the FDM component at the time the project was carried out. Based on this, and with the aim to produce a first prototype of the ABS fast, the ABS project managers decided not to include the FDM functionality in the first version of the ABS. Using the outputs of UDM and FDM when implemented as its input in terms of the forecasted number of airplane flights per different time units, the FSM component produces different forms of the flight schedule. The FSM component was built by the project members using specifications of the necessary module functionality given by RAND Europe (RAND, 2001). The sub-components of the ‘demand for capacity’ model component are shown in Figure 3.3.

73

Chapter 3 The airport capacity component (model No. 2) is decomposed into three subcomponents: Airside Capacity Model (ACM) component, Environmental Capacity Model (ECM) component and Landside Capacity Model (LCM). The ACM component is further decomposed into the runway capacity model component and the delay model component. A runway capacity model was already available in the form of an MS DOS program, done by the Federal Aviation Administration (FAA) (Swedish, 1981) and was used in the project as a COTS component. In recent years, more advanced capacity assessment models have emerged (Stamatopoulos, Zagrofos and Odoni, 2000). The component-based structure of the capacity model component, and ABS as a whole, easily allows for the FAA airside capacity model to be replaced by a more advanced alternative model in future updates of ABS.

Figure 3.3 Main elements of the capacity demand component There were two possible delay models that could be used. One was a simple model with only one differential equation, realized using the MATLAB package for technical computing (http://www.mathworks.com). The other delay model was realized by the Faculty of Aerospace Engineering, at Delft University of Technology, and consists of about 100 differential equations. Both models give comparable output. Therefore, depending on factors such as processor power, computing resources, and solution scalability, either one can be included in the ABS. The simpler MATLAB-based model realization was used as the delay model for the first ABS prototype. The Environmental Capacity Model (ECM) component was implemented using the Integrated Noise Model, developed by the FAA (FAA, 2003). This is a user-friendly model that enables the calculation of noise contours based on total flight movements and use of runways for a given year. The Landside Capacity Model (LCM) component is designed to allow a rapid and easy assessment of a specified terminal building, i.e. its infrastructure capacity and the capacity of its processing facilities, including check-in, security screening, passport control, and baggage handling, given the peak hour values of a given 24-hour flight schedule. The component also identifies the capacity-restricting elements that are estimated to be future bottlenecks at the terminal. The results can be used to suggest where further investment might be made to 74

Component-Based Development in Practice increase overall terminal capacity. The LCM component was implemented based on analytical capacity formulas recommended by the International Air Transport Association (IATA, 1995), which were then applied to the desired flight schedule. These different capacity model components were integrated in the airport capacity model component (model No.2) and together with other model components provide the ABS functionality according to the flowchart indicated in Figure 3.4 (adopted from Visser et al., 2003). The integration is designed specifically to capture the propagation of delays across the various elements of the ABS.

Figure 3.4 ABS components integration and functional flow (Visser et al., 2003) The process of decomposing the other main ABS model components, numbers 3, 4 and 5, into subcomponents will not be explored here. For further details we refer to (Walker et al., 2003) and (Visser et al., 2003). 3.3.3 Implementation of the ABS Components The design phase of the project resulted in the specification of a technology-independent, logical architecture for the ABS. The components identified in this phase were business-driven in nature, since they encapsulated functionalities that add business value from the business domain point of view, and were typically large or medium in size. The interfaces between the components were carefully maintained and every change was discussed and negotiated between the project members responsible for particular components. 75

Chapter 3 The implementation of designed components is considered in the next phase. Existing software modules were used for the implementation of particular components. These legacy assets were encapsulated by the component interface to fit properly into the component-based architecture of the ABS. Other components used in the ABS were built by the ABS team developers. For the purpose of component implementation, it is necessary to consider them in terms of the typical tiers of a three-tier architecture – consumer interface tier, application logic tier, and data tier. Each component can potentially have elements in all these tiers, i.e. a subcomponent for managing collaboration with consumers of the component, a subcomponent for implementing the component logic and a subcomponent for accessing and handling necessary data from other components or from a data storage. Consumer interface components were implemented as Application Programming Interfaces (APIs) in the case of a component-to-component interaction or as elements of the Graphical User Interface (GUI) in the case of a direct user-to-component interaction. The GUI subcomponents of all model components were combined to give an integrated GUI for the ABS using the UI facilities of Visual Basic, Microsoft Excel, or Borland Delphi, depending on the target technology platform and the version of the ABS prototype. Application logic subcomponents were implemented as Visual Basic or Delphi software code components packaged as ActiveX Dynamic Link Libraries (DLLs) (Sessions, 1998a). The running ABS application consisted of a number of DLL files representing realized components of the system. Data subcomponents were realized using ActiveX Data Objects and further mapped to corresponding tables and records of the integrated ABS database realized in Microsoft Access. As presented above, design and implementation of the ABS were conducted in a componentbased way. The coarse-grained business components were identified and specified based on business domain knowledge and needs to define a high-level component-based ABS architecture. In the further decomposition of the business components, the decision to encapsulate and use existing legacy assets was important as it was based on the knowledge of domain experts about how further to decompose airport business processes. Finally, design components were mapped into software implementation components using available component technology infrastructure. This allowed traceability from business processes to software code to be achieved in a component-based manner. 3.3.4 The Role of the Researcher The researcher had two roles, one: that of an observer, a role designed to gain more insight into applying basic CBD principles in practice. And, two: that of an active participant in all the phases of the ABS project. At the beginning of the project, the researcher was involved in creating an overall component-based architecture of the ABS system. His role was to define main architectural principles and styles, maintain the interfaces between the high-level business components, and create blueprints of the graphical user interface and database management of the ABS system. In the next phase of the project, the researcher’s 76

Component-Based Development in Practice responsibilities were focused on the design and implementation of model component 1 and he was assigned to design the functionality for specifying an unrestricted demand for airport capacity, as described in sub-section 3.3.2. This functionality was further implemented by the researcher in a component-based manner by decomposing the unrestricted demand model component into subcomponents, encapsulating existing legacy software packages and maintaining the interfaces between the subcomponents themselves, as well as between the model component as a whole and other model components. The researcher regularly participated in the meetings of the ABS team, where important questions about the model components and how the components could be best fitted together to provide the ABS functionality were discussed. The complete implementation of model component 1 was a constituent part of the ABS final software package.

3.4 The Role of CBD in the ABS Project The particular characteristics and requirements of the ABS project implied the use of a modular approach in the design and development of the ABS. ♦ The foundation of the ABS project was to integrate heterogeneous functionality specified by different domain models into the single suite. ♦ Project members had different backgrounds and were often physically distributed into separate teams. ♦ The project was limited in time and there was a need to quickly produce a prototype. ♦ The project aimed at using existing software assets that realized parts of ABS functionality. ♦ There was a potential need for flexibility, scalability and adaptability of the ABS for adopting potential future requirements. ♦ There was a need for a technology-independent system specification since programming technology and tools were not selected and fixed at the beginning of the project. 3.4.1 System Flexibility and Adaptability The component approach applied during the development of ABS, although rather informal, and not well defined, helped the project team to achieve some of the main design principles that were seen as crucial at the beginning of the project, i.e. the ABS should demonstrate flexibility, adaptability and maintainability. These properties of the ABS were achieved by building the system through the integration of components into a meaningful whole instead of creating one complex, monolithic system. This approach has made the ABS relatively easy to adapt to a wide variety of circumstances, availability of data and types of analyses without having to use large amount of time, to provide skilled workers, and to deal with confusion when reprogramming. Eventual changes in technology, procedures or business requirements affected one or a few connected components and therefore the ABS system could be better

77

Chapter 3 maintained, than this would be the case for a monolithic system where changes can propagate throughout the system in an unpredicted and uncontrolled manner. In addition to mitigating the problems inherent in building a single large system, the applied component approach made it easier for project members to understand and accept the functional components of the ABS. The challenge was to build interfaces among the ABS components that were both convenient and adaptable to changes. A common, centralized and integrated database for the use of all of the components was selected to ensure consistency of results. The database retained all relevant information for reports, inquiries, and input to components in an organized, systematic manner. Information generated by one component was automatically available to all other components requiring that information. All the components of the ABS were designed to be flexible, reshapeable, well documented and easily updated. Flexibility and adaptability were further enabled by decomposing large, complex components into finer-grained, simpler and more easily maintainable components. These components can be easily modified to analyze new situations or answer new questions in a dynamic environment. 3.4.2 Project Team Organization The applied component approach had a great influence on the ABS project management. Separation of the problem space into components provided managers with the possibility to assign the task of developing each component to a particular group of designers and developers. There was a possibility to carry out parallel work that resulted in significant time savings, while some other project activities were done in a sequential order. At the beginning of the project, five teams were created, each one responsible for one of the five main ABS components (see sub-section 3.2.1). In addition to the five teams, there was an integration team, whose task was to oversee the functioning of the complete system, consisting of the integrated set of components. Each of the five individual teams focused on the inner workings and detailed specifications of their respective model components. However, the teams were able to produce a consistent and integrated set of model components using the ‘black-box’ approach to constructing software systems. In this approach, the various teams share information about inputs and outputs, and interfaces of the components for which they are responsible, but they do not need to understand the internal functioning of another team’s components in detail. The ABS project was a joint effort of the ADC and other external parties. Successful functioning of a joint project team requires continual interaction, good information flows, and close working relationships among the team members. This was a challenge for the ABS project team, because its members were widely separated and the ADC was a virtual organization. However, the ABS team organization successfully addressed these challenges using the black-box component approach and the strategy of recursive decomposition of components.

78

Component-Based Development in Practice 3.4.3 Iterative and Incremental Development During the ABS project lifecycle, some components were developed in parallel to others, and some were developed sequentially, in a priority order. The use of a particular component could begin whenever it reached the point that a user felt comfortable enough to try to use it. The development of each particular component was an iterative and incremental process, characterized by small increments in component development where the component functionality was gradually enriched to fulfill additional requirements. The iterative and incremental development process included the following: ♦ conceptual component design; ♦ mathematical specification, which includes mathematical modeling, estimation of the parameters of the model, and validating the model using historical and hypothetical data; ♦ programming a stand-alone prototype of the component; ♦ testing and using the prototype for some or all of its intended functions; ♦ evaluating the test; ♦ revising and improving the mathematical specification, which includes adding features to the component; ♦ adapting and preparing the component for inclusion in the system; ♦ integrating the component into the system. All of these steps were done for each component, though the development of each component did not necessarily involve carrying out the steps sequentially. There was a lot of iteration among the steps. For example, testing of the prototype might reveal problems that would return development of the model to any of the previous three steps, even to as far as rethinking the conceptual design. Due to the strict deadline of the project, frequent prototyping was very important for the rapid and controlled progress of the project. The prototypes included some, but not all, of the functional features of the final versions of the components. In most cases, the inputs, outputs and user interactions of the prototypes were different from those planned for the final ABS. However, there were several good reasons for using them in early versions, for example: ♦ problems with the models could be identified and corrected early in the process; ♦ users were able gradually to become familiar with the concepts, procedures, and models of the ABS; ♦ it was possible to create a demonstration version of an integrated set of components was possible to be created in a very short time. Quality control of the components’ functionality throughout the project lifecycle was extensive and thoroughly done. The most important reason for frequent unit testing is to ensure that the system remains component based. When a unit test breaks at any given point, it is likely that someone has coded dependencies into the component that do not belong there.

79

Chapter 3 The key is to create and perform unit tests before the component is available to the rest of the project team.

3.5 Lessons Learned Practicing CBD Although the CBD approach used in the ABS project was informal and intuitive rather than disciplined and well-defined, it played an important role in successful completion of the project. However, certain problems with, and pitfalls found when, practicing this CBD approach in the ABS project were noticed. In this section, the CBD approach applied in the project is evaluated against the set of requirements for a truly CBD method presented in section 2.7. Finally, conclusions are derived regarding the improvement of the CBD methodology practice and the set of previously defined CBD method requirements are justified as the starting point for designing a component-based design and development method, described in the following chapters of the thesis. 3.5.1 The ABS Component-Based Approach Today, project teams are made up of domain experts, designers and developers drawn from different backgrounds with different experiences and motivations, they do not all think alike. At first glance, everyone may seem to understand a component-based approach to designing and developing a solution very well, but at the end everyone will interpret the approach differently. Without proper caution, the resulting system will be anything but modular and well structured. It will potentially be realized with delays and without built-in capabilities to match properly evolving user requirements. This was partially the case when conducting the ABS project. The ABS project team consisted of participants with different backgrounds, having different viewpoints on the ABS, e.g. socio-economical, airport business related, system architecture related and software coding related. There was a significant lack of overlap among the team members’ areas of expertise. While the domain experts were talking about business functions and business rules that constrain the functions, the software developers were talking about object-oriented classes, methods and implementation details. The separation of concerns defined in the business domain by defining the different airport business functionalities that formed the suite and the corresponding modularization of the system in the form of the five components formed the common ground between the business and IT-oriented participants. Further, there was a need for common understanding among stakeholders using a coherent set of concepts defined properly and represented using easy-tounderstand and -use modeling techniques. At the beginning of the project, among other reasons, physical separation of project participants dictated the need to break the problem into five main modules and to attach the different modules to different project members. The ABS team members had overall knowledge about how a modular approach can lead to more flexible, adaptable and maintainable systems that can be built from components developed by various project sub80

Component-Based Development in Practice teams. The componentization principles were introduced into the project in a loose and informal manner, without a proper encapsulation of defined components. Component interfaces were defined and handled at the very basic level by specifying just the input and output parameters of the components. Collaboration among components was also handled at the basic level, by considering whether the outputs of one component matched the input needs of the other one. This loose component design resulted in long lists of component parameters, often of non-corresponding types, at different abstraction levels and frequently changing, which made the matching between two components’ interfaces very difficult to obtain. This caused lengthy discussions among project participants and wasted a significant amount of time. For the purpose of communication between participants, the components of the ABS were specified informally using mainly prose text and simple block-and-line diagrams. There was no unified way of representing ABS components using a previously agreed textual and/or graphical notation. Such a well-understood and easy-to-use notation would certainly have resulted in better understanding and communication across the project, and in clear documented and consistent architecture models of the different aspects of the system. The process of moving from business requirements to software implementation, although based on components, was not defined in a systematic and simple manner using techniques, guidelines, prescribed steps to be taken and quality control of intermediate results. The lack of discipline in the development process often led to a need to apply code-and-fix strategies. This resulted in certain project problems, delays and higher risk of project failure. Moreover, the solution was not always flexible enough to accommodate changes coming from the user requirements side and it was not always possible to control the impact of changes made in one part of the software system on the rest of the system. It is often said that the only constant in developing software systems is that user requirements change continuously. This was also the case while conducting the ABS project. Although the requirements were generally defined at the beginning of the project, they were changed during the project lifecycle, even during the later development phases near to project completion. Very often, the requirements were changed after finalizing and presenting prototypes, when, based on shown functionality, the domain experts got new ideas about more advanced functionality that might be provided, or about some existing functionality that needed to be refined. In this way, the requirements for the ABS would be better negotiated by using frequent prototyping then by creating a precise, formal requirements specification at the beginning of the project, as this would very soon be out dated once the first prototype of the system was realized. Such circumstances required a more flexible development process, with fast iterations, frequent prototyping and intensive communication among the project members, especially between domain experts and developers.

81

Chapter 3 3.5.2 Evaluation of the ABS component-based development approach As shown above, the CBD approach applied in the ABS project brought a lot of benefits but suffered from a number of shortcomings. Without them, the project would have certainly gained full benefits of CBD regarding the factors such as higher level adaptability of the system, better communication among stakeholders sharing the knowledge about CBD principles, shorter time-to-market and more effective plug-and-play of existing components. In this section, we show the evaluation of this approach along the set of requirements for a truly CBD method defined in the previous chapter. The evaluation was performed through the discussion among several ABS project participants experienced in CBD after the project completion. This evaluation has helped us to support and strengthen our CBD method requirements derived originally from the literature survey and to use it as a basis for defining the ways to improve CBD practice in future practical projects. The evaluation results are given in Table 2.1. A meaning of the marks given in the table is as follows: ‘-‘ does not match the requirement at all, ‘+’ match the requirement to some extent; it has been applied and/or used informally and/or in an inconsistent manner, ‘++’ a good match of the requirement, N/A = not applicable. Table 2.1 Evaluation of the ABS/CBD approach Way of thinking

ABS Component Approach The component as a focus of a development process + Clear, consistent and technology-independent definitions of the _ component concepts Enriched contract-based component interface construct _ Focus on service-based, rich-in-behavior components rather than + simple data components Defining different scope and granularity levels of components ++ Defining different perspectives on components _ Way of modeling

ABS Component Approach An appropriate graphical component modeling techniques and notation _ Human-understandable textual component modeling techniques and + notation Machine- readable component modeling techniques and notation _ Modeling various aspects of components in a clear and consistent way _ Modeling collaboration, coordination and (de)composition of _ components Providing the rigorous component specification + 82

Component-Based Development in Practice Way of working Covering the full component lifecycle Component concepts in all the phases of a development process Business-driven identification of components Integration of different architectural viewpoints using components Implementation-independent component-oriented design Iterative and incremental component-based development process Flexibility and adaptability of the development process

ABS Component Approach + + ++ _ + + _

Way of controlling

ABS Component Approach Management and measurement of the progress of project activities + Determine human roles in the project, guide team activities and allocate N/A resources

3.5.3 Evaluation Findings and Conclusions We will discuss the results of the evaluation shown above in this section. As already stated, although the CBD approach used in the ABS project was loosely defined and followed in an informal manner, applying basic CBD principles and practice in the project showed its advantages. One of the positive characteristics of the ABS development process was that the basic component design was conducted early in the lifecycle, immediately after specifying user requirements. This is, to some extent, the opposite of the traditional software development practice where projects start with a hierarchy of low-level domain classes and the associations among the classes (Krutchen, 2003). If the design of a complex system, such as ABS, starts by creating domain classes, a number of interleaved, fine-grained classes/objects are created, which causes difficulties in system development and maintenance. Therefore, the design decision to start with defining coarse-grained business components was appropriate regarding the complexity of the problem and the need to adapt and maintain the system according to changing requirements. However, the evaluation given above shows that the ABS development approach failed to match some of the defined requirements, which caused problems and delays in the project, as well as not gaining the full benefit of the CBD paradigm. There was a need to define precisely a set of coherent component concepts at the beginning of the project, to be expressive enough and sufficiently technology-independent, and, therefore, well and easily understood by different stakeholders in the project, but this did not happen. Using well-defined component definitions would provide the project members with a common understanding of the software architecture building blocks and a common sense about the advantages of the component-based ‘black-box’ development approach reflecting in hidden 83

Chapter 3 interior of the components and controlled and precisely agreed interfaces between the components. Although all the phases of the ABS development lifecycle were based on components, there was no clear and consistent set of component concepts defined and agreed in the project. Without this, the participants dealt with the modularization of ABS rather intuitively, using common sense knowledge about practicing ‘separation of concerns’ and ‘divide and conquer’ strategies in technical disciplines. Through discussions among the project participants after the project completion, it was generally concluded that using a coherent set of clear, technology-independent component concepts would have enabled a common conceptual basis and better communication, about the component paradigm followed in the project, between the participants with different backgrounds. A complex project requires modeling activities to be regularly performed for the purpose of better understanding and communication among the team members. If the project team wants to practice CBD, then a modeling and specification notation is required to represent various component concepts throughout the project lifecycle. The advantages of defining a unified modeling notation to be used in the project are manifold: it provides a means for the participants to understand each other’s components without going into low-level implementation details; a domain expert can briefly express his/her ideas to developers in a clear, simple and still precise way; the developers can represent their implemented software code using higher-level abstractions in communicating with domain experts and other developers. Moreover, the models of system artifacts done in a proper notation represent a basis for system documentation that continues to live after the project is finished, or when some developers are substituted by others, because exploring models to find out a system’s functionality is much easier than exploring someone’s software code. The lack of an agreed component modeling and specification techniques was one of the characteristics of the ABS project. The participants used mainly simple ‘block and line’ diagrams, or semantically poor textual notation. The lack of common modeling expressions understood by everybody was, to some extent, substituted with personal contact between participants, but even then, there was not always an easy understanding between them. Therefore, an intuitive, easy to understand, consistent and precisely defined, graphical and/or textual modeling notation is required for practicing effectively the CBD approach in real-life projects. For example, the standard UML notation can be used to provide a basis that can be extended to enable the representation of various component concepts, but also domain-related concepts such as airport business entities and rules. Finally, an effective and flexible development process is required for transforming a project from one phase to another, to lower the risks of unsuccessful projects, to provide a final system solution on time and to match user requirements, maintained with proper quality control. The ABS project, to some extent, lacked a disciplined and well-defined componentbased development process. The project started with the identification of high-level components in a business-driven manner, and tried to provide traceability of these business 84

Component-Based Development in Practice components to finer-grained implementation components. However, the component architecture of the system was not always clearly and precisely defined, which, coupled with frequently changing user requirements, raised the risk of ending up in a code-and-fix strategy. Coding without first designing can result easily in unmanageable and interleaved software code, which could make the maintenance of the system and its adaptation to changes very difficult. Therefore, a strategy of creating a set of component-based models, and transforming models at the higher level of abstraction to lower abstraction level models, in a top-down fashion and at the same time adopting bottom-up technology constraints, should be applied. In this way, the project gradually moves from business requirements to software implementation using small increments and regular iterations. Then, the complete, technology independent specification of the system is easy and straightforward to implement in a programming technology of choice. In the ABS project, although only partially followed, this strategy gave the project team the possibility to implement the prototype of the system using Borland Delphi or Microsoft Visual Basic programming tools, without changing the system specification. Due to the constantly changing user requirements, some principles of agile development in project management was applied, but not to the full extent, such as intensive collaboration among the project participants, especially between developers and domain experts, early and constant prototyping, creating architectural blueprints, frequent unit testing and frequent releases of an integrated system to get an impression of the system as a whole. The main role of the ABS case study in this research was to support and justify our CBD method requirements. On the one hand, the case study showed a potential power of CBD even if it is followed informally and partially. On the other hand, it highlighted some significant drawbacks of the followed approach that prevented the project team to gain the full benefit of the component paradigm. Some problems and pitfalls in building the ABS could have been avoided, if a truly CBD method, aligned to the method requirements, had been used, as described earlier in this section. As a conclusion of this case study we can state that, for the purpose of practicing CBD effectively, a component-oriented design and development method is required which should provide a coherent set of technology independent component concepts (way of thinking), modeling mechanisms for representing different aspects of a component-based problem and solution space (way of modeling), and a stepwise process to system design and implementation that uses defined component concepts and component models for mapping business services to implementation assets. In the following chapters of this thesis, we present a component-based and service-oriented software systems engineering method that was created to satisfy the set of CBD method requirements defined in chapter two and supported in a practical case in this chapter. The way of thinking, the way of modeling and the way of working of the method will be presented in chapters four, five and six respectively.

85

4 Component Concepts and Definitions The component-based design and development method proposed in this thesis should fulfill the method requirements defined and classified into the ways of thinking, modeling, working, and controlling in chapter two and justified in chapter three. The main component concepts and definitions of the method will be introduced in this chapter to give the way of thinking of the method according to the given requirements. Since components can be of a different type, form, granularity and nature, any attempt to provide a single definition of a component covering all its possible aspects is likely to be insufficient. Therefore, instead of a single definition, we will examine and present a set of essential properties, features, aspects and forms that a component must, or can, have. Since our approach is to use a consistent way of thinking during the whole development lifecycle, from business concepts to software deployment, our aim here is to define general, clear and implementation-independent component concepts. It is our strong belief that the component, defined basically as an encapsulated manager of services provided to, and required from, its environment can be equally well understood from both a business and an IT system perspective, and therefore the component can represent common ground for business and system concerns (Stojanović and Dahanayake, 2003). Recently, new concepts, principles and definitions regarding the way components are handled throughout the development lifecycle, from logical components to physical software components, have emerged, such as the UML profile for Enterprise Distributed Object Computing (EDOC) (OMG-UML4EDOC, 2004) and the new major revision of the standard UML, version UML 2.0 (OMG-UML2, 2004). Certain concepts and definitions proposed in these specifications will be incorporated in the way of thinking of the method presented in this chapter.

4.1 Basic Component Concepts The word ‘component’ is derived from the Latin componere, which means ‘to put together’. According to the Webster dictionary, a component is a constituent part, an element or an ingredient. A component can be defined as a kind of an entity, which means something that exists as a distinct, independent, or self-contained unit with a clear purpose of existence and clear boundaries. As a starting point for the discussion about essential characteristics of a component we use a slightly modified version of the component definition given by Szyperski (1998): A component is a unit of composition with hidden interior, contractually specified

87

Chapter 4 interfaces and explicit context dependencies. In what follows we will consider some parts of this definition in more detail. 4.1.1 Components and Composition Defining a component as a unit of composition actually means that the purpose of components is to be composed with other components to form a meaningful whole. At the same time, a component can be considered to be a composition of lower-level components. The concepts of component and composition are fundamentally tied. The existence of a component implies a specific kind of composition for that component to be assembled into. The concept of a composition only makes sense when there are components to form it. This recursive composition, where each component, at the same time, is a part of a composition and can be decomposed into sub-components, is an important characteristic of the component paradigm. Similar definition of the concept of composition can be found in the UML profile for EDOC (OMG-UML4EDOC, 2004). Regarding the concept of composition there are basically two kinds of components: ♦ primitive components, those that cannot or need not be decomposed into sub-components either because they represent a very basic behavior for which it is not possible or useful to decompose the component further into meaningful sub-components, or because they represent monolithic structures that cannot be easily decomposed into sub-components, for example a component that is built by encapsulating a legacy asset; ♦ composite components, components that are built from other components to provide a more complex behavior; composite components are defined using a composition. It is worth noting that the composition of components is not defined just in the sense of the part-of relation, where sub-components are aggregated and encapsulated together in an arbitrary fashion inside the composite component. Collaboration between components within a composition is their meaningful interaction to provide a higher-level cooperative behavior on behalf of the composite component that is bigger than the sum of the behaviors of all the sub-components. It is essential to determine coordination between component activities, which denotes the order in time and causality of component interactions in terms of sequencing, parallelism, conditional activation, loops, etc. Only by coordinating their activities properly, are sub-components able to provide the behavior of the component they compose. The characteristics of the composite component are determined by the characteristics of its subcomponents and the way they are combined. Well-defined behavioral dependencies and coordination between components are very important for achieving a common goal. As a summary, we can say that the concept of composition is fundamentally related to components and represents a coordinated collaboration between components in creating a higher-level behavior, i.e. component.

88

Component Concepts and Definitions Two aspects can be defined in relation with the concept of component composition: decomposition and assembly. Decomposition is the process of identifying the sub-components of a given composite component in a top-down fashion. Decomposition can be done in more than one way. Different decomposition processes do not necessarily give the same result, i.e. the same defined sub-components. The resulting decomposition strongly depends on the principles, concerns and rules applied during the decomposition process, as well as on the main aims of the process. Assembly is the process of combining existing components to form a new component in a bottom-up fashion. The new component has a behavior that is greater than the sum of behaviors of its parts. The behavior of the composite component depends on its sub-components and on the way they collaborate and coordinate their behavior inside the composition. 4.1.2 Component Essentials The next essential characteristic of a component is explicit separation between the external and internal aspects of the entity being encapsulated to represent a component. In other words, a component has a hidden interior and exposed interfaces. This means that only the question ‘what’ is considered: What useful services are provided by the component to its context? And not the ‘how’: How these services are actually realized by the interior of the component? A component does not exist in isolation; it fulfils a particular role in a given context and actively communicates with the context. A component encapsulates its content, i.e. internal realization, by exposing the contract to its context. The context can rely on the component’s contract alone and not on its content. Therefore a component can be represented as a tuple . The context represents the environment of a component, defined in RM-ODP as a part of a problem domain that is not a part of the component (ODP, 1996). A component naturally depends on its context; it provides services to the context and uses services obtained from it. The context can be broadly defined to cover issues from logical and domain settings to necessary technology infrastructure. The context of a component, in its simplest form, is defined as a set of components that must be available for that component to collaborate with. The dependencies of the given component with the components that form its context must be explicitly defined to support assembling of components. The content of a component is the internal realization of its contract, which is not seen from the outside of the component, i.e. from its context. The realization of the contract is performed through the collaboration and coordination of lower-level components and other structures that jointly provide the necessary behavior of the component. According to the concept of encapsulation, the contract of a component is separated from how that component is realized. The contract specifies the ‘external view’ of the component. The content of a component is its ‘internal view’, i.e. the way in which the component fulfills its contract in terms of collaborating sub-elements. 89

Chapter 4 The contract of a component represents a formal and detailed specification of the behavior the component exposes to its context and the behavior it expects from the context for it to work properly. As defined in (ODP, 1996), the behavior of a component is a collection of its actions with a set of constraints on when they may occur. A role is a name or an identifier for a behavior. Therefore, a component fulfills a particular role in a given context. The role of the component determines the nature of its participation in a coordinated collaboration with other components to create a higher-level behavior or functionality. Since, a component does not exist alone, outside a certain context, it can be generally said that a component provides a service to its context. A service is defined as the performance of duties or responsibilities for the benefit of others. At the same time, a component needs services from components that belong to its context to expose its behavior properly. The responsibilities, or duties, of a component that are elements of its services can be of the following two kinds: ♦ passive – a component provides information; it contains information or it represents a contact point for some information; ♦ active – a component performs activities, transformations and/or control; it transforms input information into outputs to serve the consumer’s needs. A component can have both kinds of responsibilities simultaneously. Certain context settings and purposes require a specific type of component so that when defining a component one kind of responsibility can be more important and, therefore, more emphasized than the other. An interface of a component is an essential part of its contract. An interface defines a set of public features and obligations that constitute a coherent service offered by a component. The interface can be provided, offered by the component to other components, and required, used by the component from other components to perform its responsibilities. An interface is normally specified as a cohesive set of operations provided and required by the component, including their parameters and parameter types. However, this representation of an interface is rather syntactic in nature. Since the interface of a component is the only visible element of the component from the external perspective, and since consumers of the component rely only on its interfaces when using it, richer semantics of the interface need to be provided. The semantics of the interface becomes increasingly important since off-the-shelf components are normally delivered without source code. Moreover, it is crucial to provide sufficient information about the component features when the component interface is exposed to its consumers in the form of a Web service. A semantically rich interface should guarantee that invoking and using the services over the Web must be properly done in the ‘24 hours x 7 days’ manner in order to avoid risks and failures of business processes realized by the Web service. There are several ways to incorporate semantics into the definition of an interface. They will be briefly listed here and further explained in section 4.2 where the mechanisms for component specification are presented: ♦ defining pre-conditions, post-conditions, invariants and effects for each operation of an interface in terms of design-by-contract as given in (Mayer, 1997); 90

Component Concepts and Definitions ♦ ♦ ♦

defining the activation sequence of operations and timing constraints among them using conditions such as before, after, parallel to, if-then-else selections, loops, etc.; defining the information model of an interface that represents the types of parameters of component operations and associations among them; defining configuration parameters of an interface using the context in which a component behavior can be adapted and fine-tuned to fit better to the changing context, without changing its interior.

An interface, semantically enriched using the elements listed above, specifies a formal contract of the features and obligations that a component provides to its consumers and those that it requires from other components in the system. A contractual interface represents formally the component’s role in its context, and the responsibilities and activities it has to fulfill in the given role. A contractual interface is the external appearance of the component. A consumer of the services of a given component relies only on the component’s contractual interface and it can use the component properly without knowing the details of its internal realization. The metamodel of the essential component concepts presented above is given in Figure 4.1 using the standard UML notation for classes and associations. It is important to note here that the aim of this metamodel is just to represent in a clear, graphical manner the main component concepts, elements and semantic relations among them. Our intention here is not to create metamodels of elements of our method to compare them with corresponding metamodels of other CBD methods, as it was done in the case of OO methods in (Hong, van den Goor and Brinkkemper, 1993). As already stated in section 2.8 of the thesis, due to immaturity of the CBD methods regarding the support for components, this approach would be hardly possible, An integrated metamodel as a common denominator for different metamodels against which they could be compared would be rather trivial, if not empty. +abstracts

Content

Contract

+exposed to

Context

1..*

+reliazed by Composition

+is a

1.. *

+has

1..*

Component

+participates in

+defined in

+exists in

Role

+plays 1..*

+collaborates in

+ful filled in

Coordination

+represents

Collaboration

+specifies

Figure 4.1. Metamodel of the essential component concepts 91

Chapter 4 As usually defined, a component can have multiple interfaces i.e. multiple cohesive sets of component features that are provided or required by the component (Szyperski, 2002). However, we consider this capability of a component to be potentially dangerous for the nature of a component. If a component provides several interfaces that differ in scope and functionality area, then this component probably fulfills too many responsibilities and its behavior is not well encapsulated, which can result in splitting the component into several finer-grained components that will provide a cohesive functionality. This topic is related closely to the coupling and cohesion characteristics of components, which will be described later in this chapter. The generalization/specialization relation between two components in terms of inheritance can be defined similarly to inheritance in object-orientation. However, a difference between two types of inheritance must be made, namely implementation inheritance and interface inheritance. Implementation inheritance means inheritance of software code from the base entity when creating a derived entity, so that the instances of the base entity are used as a way to implement instances of the derived entity. With interface inheritance only the operation declarations are inherited, and not the implementation. In this way, the new entity exposes all of the features specified in the base entity, while their implementation must be provided separately. While in object-orientation both types of inheritance can be applied, in componentorientation only inheritance of interface is applicable, since applying implementation inheritance would break the encapsulation rules for creating components, which lie in the foundation of CBD. 4.1.3 Different Views on Components In the discussion about the context, contract and content of a component, we can define two basic views on a component: one, a black-box view or specification view, and two, a whitebox view or internal realization view. The black-box view is the external perspective on a component in terms of component’s behavior that can be seen from the context. The black-box view results in a complete and precise specification of a component that can show everything about the component behavior without considering the internal realization. This specification of the component can be used to properly assemble and integrate the component into an overall solution for a given problem, to substitute the component with a compatible component if necessary, to browse an eventual catalog of components to find one that matches the required specification, or to reuse the component in a different context. The white-box view is the internal perspective on a component that defines the way in which its interface is realized in terms of existing sub-components and other elements that collaborate inside the component to produce its behavior. As already stated, the realization of the component is not visible from the outside of the component. The specification of a component is independent of underlying realization, which means that the same specification 92

Component Concepts and Definitions can be realized in many different ways. From the perspective of component composition, the specification of a component is more important than the way that specification is realized internally. It should be possible to replace one component with another that has an equivalent specification without affecting the composition. Clear separation of component specification from component realization is therefore another important characteristic of a component. A component defines its contractual interface in such a way that it is precisely and completely specified by the component specification, and realized by the component internal realization, as shown in Figure 4.2. A component can have one or more different specifications given in different specification mechanisms, and one or more realizations, i.e. different ways to realize the component interface. Specification

+specifies

+realizes

Interface/ Contract

Reali zatio n 1..*

1..* +defines

+has

Component

+has

Figure 4.2 Specification and internal realization of a component Given these views on components, we can also define an assembly view that takes into account how a system solution, assembled from components, fits into a wider context, for example a business context, and how it fulfills its responsibilities as a whole. Based on the different views on components we can define the different roles of the actors that deal with components and whose concerns are related to a particular view. ♦ A designer of components creates a component specification and design according to the requirements for the given functionality coming from a business domain or an existing software solution. A designer provides a complete, detailed and precise specification of a component, which represents a basis for its implementation and further assembling. ♦ A developer of components has a white-box perspective on components. He or she realizes the interior of components to fulfill a defined component specification. A developer has little interest in the purpose of particular building blocks. His or her main concern will be that the realized product meets the component specification. ♦ An assembler of components uses available components to assembly a system solution that fulfills a given role in the context. In doing this, the assembler uses component specifications and is not able to handle and change the internal realization of the components. He or she must ensure that the provided and required interfaces of the components used for the assembly match, given a need for possible fine-tuning and configuring using parameters available on the component interfaces. ♦ A user of a component-based solution benefits from the fact that the solution is assembled from components, thus gives higher flexibility and adaptability to context changes and 93

Chapter 4 new requirements. A user will often be aware of how reusability and replaceability of components inside the solution can reduce the costs and provide a shorter time-to-market when building new versions of the solution.

4.2 Component Specification As stated above, for the purpose of effective use of a component when creating an assembly, it is essential to provide a clear and detailed specification of the component. A component specification represents the complete set of necessary information about that component required by an assembler to use the component without knowing its internal realization. The specification provides a complete, unambiguous and precise description of the external view of a component that is ready to be assembled into a solution. We propose that the specification of a component is done according to different viewpoints that define the different concerns that arise when handling components, similar to the viewpoints defined in the Reference Model of Open Distributed Processing RM-ODP (ODP, 1996). It is not necessary to use all the viewpoints when specifying components, this depends on the particular situation and specification goals and needs. The complete specification of a component is achieved by integrating the specifications from all the viewpoints. The consistency of the viewpoint specifications is ensured by the fact that all viewpoints specify the same component, though from different perspectives. Therefore, the elements of different viewpoints are mutually related and can be cross-referenced if necessary. The main specification viewpoints defined in this research are as follows, and are shown in Figure 4.3. ♦ The Context Viewpoint of a component defines a purpose, scope, the position of the component in the context, and policies, rules and obligations from the context that are applicable to the component. ♦ The Behavior Viewpoint of a component specifies behavior the component provides to, and requires from, its context, and constraints and conditions on this behavior. ♦ The Information Viewpoint of a component specifies types, semantics, dynamics and the constraints of the information resources handled by the component. ♦ The Realization Viewpoint of a component specifies the constraints and requirements related to component implementation and deployment. 4.2.1 Context Viewpoint Specification In this section we give some basic elements of the component specification from the contextual viewpoint. Component Identifier - A component is identified in context by its unique and unambiguous name in the naming space and/or a unique identifier. The name of the component should clearly indicate its purpose in its context and the goal of its existence.

94

Component Concepts and Definitions Non-functional (Quality) Parameters - A component can have a set of so-called nonfunctional parameters defined that characterizes the “quality” of its behavior in its context. Non-functional parameters are, for example, Performance, Reliability, Fault Tolerance, Priority, and Security. Component specification from the contextual viewpoint can be enriched with more business context issues, such as business policies, rules, business goals, business terminology related to the services offered by a component, etc. This is especially important for components and Web services that offer business functionality and that provide specific parts of the business processes of an organization.

Figure 4.3 Specification viewpoints of a component 4.2.2 Behavior Viewpoint Specification A component is a behavioral unit representing a manager or provider of services. According to the role(s) a component plays in the given context, it exposes corresponding behavior by providing services to, and requiring services from, its context and emitting events and receiving notifications about events it subscribes. The services a component provides and requires are the basic part of its contract. Services can be of different types, such as performing computation, providing information, communication with the consumer, etc. The services are fully specified in a contract-based manner using pre-conditions, post-conditions, invariants and effect (D’Souza and Wills, 1999). A precondition is a logical statement associated with a service that must be true before that operation, or service, is activated. A post-condition is a logical statement associated with a service that must be true after that operation (or service) finishes its performance. Using preconditions and post-conditions as 95

Chapter 4 guards for services is one of the most popular approaches to add semantics to the interface representation. An invariant is a logical statement associated with an interface that a component assumes is always true. Finally, an effect is a logical statement associated with an interface that must be true after any operation, or service, of this interface is activated. The component, with its services, collaborates with other components in its context to provide richer, more complex behavior. It is important to define proper coordination conditions among the provided and required services of a component and the events that are published by the component and the events about which the component has been notified. This basically represents how component services are coordinated with the services of other components to reach a higher-level goal. For example, there is a situation where the component must first receive the service from another component to provide its service to its context, as in the case of an e-commerce component Order Processing where it has first to receive the information about the customer from the Customer component to activate its service CreateOrder. Therefore, the coordination conditions between provided and required services, and published and subscribed events, must be precisely defined in terms of relations before, after, parallel to, if-then-else, do-while, etc. To further encapsulate the component content from its context, we can define a concept of port in a simular way this concept is defined in UML 2.0, the UML profile for EDOC, and Architecture Description Languages (ADLs), such as Acme (Garlan, Monroe and Wile, 2000). The role of the port can be manifold. First, it provides a logical grouping of cohesive, provided and required operations, services and events to represent a complete communication protocol between the component as a provider and its consumers to satisfy a certain goal. Second, it represents an interaction point between the component and its context. Operations that are grouped by the port specify the mechanisms of interactions that can occur over that port between the component and its context. Finally, a port represents some kind of a façade that encapsulates and isolates the elements of the component content that are responsible for the realization of its contract and the component context. In this way, a port represents a mechanism that transfers the requests for some operation to the element of the component interior that realizes it, if any, or exposes the realization of an operation done by an interior element in the form of an interface to the component context. The definition of context-aware configuration parameters is an important part of component specification. A component is often dependent on the context of its existence. In order to be used in different contexts, or to be adaptable to the changes in its context, a component can define configuration parameters that can be used to adapt the component behavior to fit into possibly new requirements coming from the outside. In this way, the component can be effectively used in different circumstances and “survive” possibly frequent changes in the context. An example of configuration parameters is the Quality-of-Service (QoS) required for different profiles of component consumers and related to different component locations in

96

Component Concepts and Definitions time and space. Configuration parameters can be assigned default values when the component is used for the first time. 4.2.3 Information Viewpoint Specification A component must handle, use, create or simply be aware of certain information resources to provide its services properly. The component contract defines what types of information are of interest to the component, and the constraints and rules on them. This does not necessarily mean that the component owns, or contains, that information; the contract defines what information the component needs for exposing the proper behavior. These information types can be considered as the types of operation parameters and the information (data) types related to them. The specified information types are abstract and they indicate that the component instance, or instances of its sub-components, should handle the information of those types in terms of creating, modifying, storing or simply using them. Therefore, having a certain information type listed in the component specification does not necessarily mean that the component instance, or instances of its sub-components, is responsible for the whole lifecycle of instances of the type, it can also suggest that it needs these instances as parameters for its operations from the context in the run-time. The model of information types defines the types of data that the component is able to recall, either because it stores this data, persistently or transiently, between operation executions, or because it has the ability to obtain this data from other components. This model provides an accurate summary of types of the data the component “knows about”. It defines some constraints that are applied to the instances of these information types. The model can also define possible transformations of the instances of the given information types in time by activating or receiving services using some kind of the state machine. The information viewpoint specification of a component is to some extent similar to the logical information model as defined in UML Components (Cheesman and Daniels, 2000) and to properties owned by component interfaces in UML 2.0 specification that imply that the conforming instance should maintain information corresponding to the type and multiplicity of the property and facilitate retrieval and modification of that information (OMG-UML2, 2004). 4.2.4 Realization Viewpoint Specification The technology requirements, constraints and properties of component implementation and deployment can be a part of the component specification. For example, an operating system, corresponding computational resources as deployment nodes for a component, a programming language in which the component is implemented, and requirements for permanent data storage can be specified to get a complete picture of a component, from its business context to its technology environment. In the case of a Web service, in addition to the technology specifications given above, we need to specify the network protocols that will be used to invoke services across the network, the binding mechanisms and the Uniform Resource 97

Chapter 4 Identifier (URI) where the Web service resides. This realization viewpoint specification has, to some extent, a similar scope and aim as RM-ODP technology viewpoint for specifying technology aspects of an ODP system (ODP, 1996), or as a service grounding as defined in the semantic Web services initiative to specify the details of how an agent can access a service in terms of a communication protocol, message formats, and other service-specific details such as port numbers used in contacting the service (DAML, 2004). The metamodel of the main component specification concepts is given in Figure 4.4 using the standard UML notation for classes, associations, aggregations and inheritance. Note that the technology specification elements are excluded from this figure. The goal of this metamodel is to provide the clear view on the elements of component specification and semantic relationships among them. Name

Purpose

Emitted

Scope

Event

Notified by

Ident ificat ion

Non-function al parame ters

0..*

0.. * +specified by

Information

Component +uses

Required

+id enti fied by +exposes

Behavior

+coordination of

Invariant

+affects

0..*

Provided

+constrained by

+constrained by

0..*

Service 1..*

+adapted by

0..*

+affects

Condit ion

Context-Aware parameters

Pre-condition

Post-condition

Coordination

Figure 4.4 Component specification concepts Depending on the context of use of a component, the specification of a component can be presented in a particular way. The possible notations for representing the component specification in the context of software development process are: ♦ textual notation as an extension of an Interface Definition Language (IDL) or objectoriented programming languages such as C++ and Java; ♦ graphical notation using diagrams of different kinds, such as the UML notation with addition of Object Constraint Language (OCL) notation for specifying constraints; ♦ machine-readable notation based on eXtensible Markup Language (XML), for example derived from Web Services Description Language (WSDL) and enriched with necessary constructs to represent all specification elements of a component; ♦ high-level spoken language that can be standardized to serve the purpose of a particular domain. 98

Component Concepts and Definitions The various modeling and specification notations used to represent component concepts will be the subject of chapter five in which we present the way of modeling of the method. 4.2.5 Component Specification vs. Interface Defining the component interfaces is a major part of creating a component specification. We can say that the interface represents the external view of the component from the perspective of the component that interacts with it, while the specification represents the external view of the component from the perspective of human user of the component who assembles it into the final solution. Therefore, the interface of the component includes the identifier of the component, its behavioral aspects, the information types that it handles and some aspects of the technology perspective such as the mechanisms of binding in the case of Web services. Additionally, the specification adds more information from the contextual perspective, such as the name of the component producer, non-functional component properties and business policies and the rules applied to the component in the business context. Moreover, the specification can give some more information about the programming tools and languages used to build the component, and about the operating system where the component will be installed at run-time.

4.3 Components in the Development Lifecycle Some basic principles and aspects of using components throughout a system development lifecycle are presented in this section. 4.3.1 Coupling and Cohesion Some of the basic design principles that should be used when designing components are low coupling and high cohesion. Coupling is a measure of how strongly one component is connected to, has knowledge of, or relies on other components. The number of relations and dependencies of a component with a low, or weak coupling with other components is optimized and minimized. A component with high, or strong, coupling relies on many other components. The possible problems of highly coupled components are: ♦ changes in related components can produce local changes; ♦ it is difficult to understand in isolation outside the context of related components; ♦ it is difficult to use and reuse because at the same time related components must be used. The way in which components interact must be precisely defined to permit collaboration and the fulfillment of a higher-level goal, and it is also necessary to preserve their loose coupling so that the components can evolve independently. A proper balance must be achieved between the necessity to interact and yet provide as much independency as possible, often called being autonomous. The interaction between two components is usually unidirectional. A bi-

99

Chapter 4 directional dependency between two components suggests tight coupling, and combining these two components into a single component need to be considered. Cohesion can be seen as a measure of how strongly related and focused the responsibilities of a component are. A component with highly related responsibilities, and which does not do a tremendous amount of work, has high cohesion. A component with low cohesion tends to fulfill many unrelated responsibilities, or to do too much work. Such components imply the following problems: they are difficult to comprehend, difficult to use and reuse since they are too big and/or unfocused, and difficult to maintain because of the size, complexity and constant changes. If a component has too many unrelated responsibilities, splitting the component into several sub-components with more cohesive responsibilities should be considered. 4.3.2 Component Facets During the development lifecycle of a component-based system, a component will have the following essential facets. ♦ Component Conceptualization is a conceptual definition of the component through using main properties and capabilities in a computation and technology independent manner. ♦ Component Specification is a precise definition of the component contract that provides sufficient information to the component consumer without knowing its internal realization. ♦ Component Implementation is the design and realization of the component interior and/or software artifacts that realize the component specification. ♦ Component Deployment is a set of modules that is installed on possibly different computational resources during the run time. Component conceptualization is concerned with the description of the main component properties and capabilities from an external point of view without going into details about possible automation and implementation of the component. The main concerns addressed by the component specification are the precise definition of the contractual interfaces of the component, including its context, behavior, information and realization information (see section 4.2). Component implementation is concerned with the configuration management aspects of component development using programming language tools and constructs, such as functions, classes/objects, user interface tools, database connections, etc. Component deployment is concerned with what gets shipped and installed on the computational resources, i.e. the computers, as the run-time version of the component. A fully specified component at the level of specification is normally implemented by one or more components at the implementation level, using e.g. CORBA, COM+ components, or EJBs, and deployed on different computers connected to the network using binary software code packages.

100

Component Concepts and Definitions The proposed definition of a component attempts to capture its important property of having a conceptual unity of design, construction, and deployment (Kozaczynski, 1998). One of the most difficult and important roles of an architect is to decompose a system into components that will transcend all the system development phases. A direct consequence of the proposed definition is that a specified component at the level of system design becomes a collection of multiple artifacts at the level of implementation that includes multiple executables at the level of deployment. Component Conceptualization

+defines

Component Concept

+specified by

1..*

Component Specification

+spec ifies

Component Contract

+implemented by

1..*

Component Implementation

+realized as

Implementation Artifact 1..*

+packaged into

*

1..*

Component Deployment

+deployed as

Component Executable 1..*

Figure 4.5 Component Facets It is interesting to map the basic component concepts and component specification concepts presented by metamodels in Figure 4.1 and Figure 4.4 respectively to the component facets given above. The basic component concepts, context, contract, content, composition and collaboration, can be related to all these different component facets, although in a different way and having a different form and purpose. Similar to this, the specification component concepts can be defined and used with all the component facets, although their main role lies at the level of component specification when they are used to specify a given component precisely and in great detail for the purpose of its further implementation or using as thirdparty software component. For the purpose of component conceptualization not all the specification concepts are considered or detailed, depending on particular needs. At the level of component implementation, the realization in software of the specification concepts is considered, for example services can be mapped to methods of session EJBs or functions of .NET components, while a component information types can be mapped to OO classes, data structures or entity EJBs. For the purpose of component deployment, deployment aspects of previously implemented specification concepts are considered, for example an URI address for invoking component services, or permanent data storage of information type instances.

101

Chapter 4 4.3.3 Component Granularity and Types Components can be of different types, scope and granularity. It is very important to specify different kinds of components that are characteristic for the particular domain and the relations among them to identify and specify correctly components in a domain. Determining granularity levels is very much context related. What is a coarse-grained component in one context can be a finer-grained component in another context. The size of components is not a dominant differentiating factor when defining granularity levels. Granularity is more related to the semantics of a component, the comprehensiveness and nature of its interface, the scope of its responsibilities and the level and complexity of information the component handles. Therefore, there can be components that are large in size but at a lower level of abstraction, and, in contrast, small-size components can represent entities at a higher abstraction level. Component granularity types can be specified in two different ways. According to the first way, the granularity of components is specified using the set of predefined discrete levels. The characteristics of each of the levels are precisely defined and their differences highlighted. Using this strategy, components that belong to a higher granularity level are made up from components of its subsequently lower level and there is no granularity level defined in between. Such a definition of component granularity types is given e.g. in (Herzum and Sims, 2000) and (UML-EDOC, 2004). Another way to treat the question of granularity is to use continuous recursive composition, as defined in Catalysis (D’Souza and Wills, 1999), KobrA (Atkinson et al., 2002) and UML Components (Cheesman and Daniels, 2000). This strategy does not predefine specific granularity levels for the components. It specifies that finergrained components can be combined to give a larger-grained component, and a component can be decomposed to give finer-grained components, without precisely specifying what is the type and scope of functionality of these components with regard to the context. We used the first strategy of discrete, predefined set of component granularity levels in this research. Although many variants of components can be defined at different levels of granularity and/or abstraction, for the purpose of this work we define the following types of components: Enterprise Component, Business Component, Application Component and Program Component, as shown in Figure 4.6. An Enterprise Component is a coarser-grained type of component that can exist as a standalone system within an enterprise to provide automation of its core business processes, or it can be used for inter-enterprise integration and creating complex information systems that cross enterprise boundaries and represent a basis for virtual enterprises. An Enterprise Component interacts mainly asynchronously with other components of the same enterprise, people or automated systems, or with components outside the enterprise’s boundaries across the network. An Enterprise Component can be realized as the collaboration of finer-grained

102

Component Concepts and Definitions enterprise components and/or business components, but it can also be realized as a monolithic structure without the possibility to be further decomposed. Enterprise Component 1..*

1..*

Business Component 1..*

1..*

Application Component 1..*

1..*

Program Component 1..*

Figure 4.6 Different types of components A Business Component provides services that have meaningful, perceivable and measurable value in the context of a particular business domain. Business services provided by a Business Component represent a coherent set of functionality defined to satisfy a defined business goal. A Business Component is responsible for supporting and the realization of one of several automated steps of an enterprise-level business process. To provide its services, a Business Component uses the information about associated business entities and applies a certain set of business polices and rules. A Business Component mainly fulfills ‘active’ responsibilities, so it is a unit of computation that is rich-in-behavior in terms of providing activities instead of only static information. An important characteristic of a Business Component is that it can be spread across the typical tiers of a multi-tier architecture, namely presentation, logic and data. This means that a Business Component can have elements in all or some of these tiers, which together contribute to its business functionality. The power of the Business Component concept is that in defining these components one is encapsulating, and possibly reusing, the business knowledge and important patterns of business functionality. A complex business application can be designed easily by assembling business components in the same way the business process steps, these components support, are assembled into a complete business process. Business Components represent a way to decompose a given business domain that is at the same time meaningful for business domain experts and for the designers and developers of the underlying implementation. A Business Component can be realized as a collaboration of finer-grained business components and/or application components, but it can also be realized as a monolithic structure without further decomposition. An Application Component provides some finer-grained services that do not have a business meaning and purpose. An Application Component in collaboration with other components 103

Chapter 4 creates functionality that is meaningful in a business domain. Application Components are usually defined as placed in a particular tier of the network, such as consumer interface components, e.g. dialog forms and interaction controls, application logic components and data access components, e.g. database application programming interfaces (APIs). Application Components can be of different types, those that have only ‘active’ or ‘passive’ responsibilities, or that have both. Application Components with passive responsibilities placed in the application logic tier, often called entity components, usually encapsulate and provide the information about a business or application entity. An entity application component is the part of the information viewpoint model of the business component that contains it. Components with active responsibilities placed in the application logic tier, often called process components, provide some lower-level activities or application-related computation. Today, it is a widely accepted design pattern that entity components can be accessed only via process components that form a kind of a façade around them. This strategy suggests that behavior-rich process components encapsulate entity components, achieving the encapsulation of data by behavior, although at a higher level of abstraction, which is in line with classical object-orientation theory. An Application Component can be realized as the collaboration of finer-grained application components and/or lower-level constructs called program components, but it can be realized in a monolithic fashion without further decomposition. Program Components are components that exist within a single application program. They belong to the same address space and communicate via simple method calls. Examples of Program Components are standard OO classes at the design level and objects of these classes at the instance level. 4.3.4 Component Reusability and Replaceability Although reusability and replaceability are often listed among the main component properties in many component definitions, for example in Booch et al. (1999), in our opinion they are not inherent characteristics of a component. Reusability and replaceability are rather a result of good component design according to the principles given above, such as hidden interior, exposed interfaces, low coupling and high cohesion. Reusability is not easy to achieve and it is also a function of social, organizational and technical issues. If something is reusable, it does not automatically mean that it represents a component with characteristics given above. At the same time, an entity defined as a component is not necessarily reusable. It strongly depends on the context of component usage, issues of trust and security in using components developed by third parties, the level of generality/specificity of the component, and the coupling to the particular technology and implementation mechanisms. The level of reusability is closely related to the level of generality of a component. A more general component can be potentially more reusable since it can be used in a number of cases. 104

Component Concepts and Definitions In contrast, a specific component can be used only for specific cases, i.e. the cases the designer had in mind when designing the component. A more general component tends to be less focused, as it provides and fulfills a number of potentially divergent responsibilities. This makes the component less useful in particular situations since such a component is not sufficiently cohesive and is less understood by a potential user. Therefore, the right balance between generality and specificity needs to be made when designing components. Replaceability is a characteristic of a component that allows it to be replaced, during the design time or run-time, by a component that offers equivalent functionality based on compatibility of their contractual interfaces. The component used to replace an existing component should provide at least (minimally) the services that are provided by the original component, and should require at most (maximally) the services that are required by the original component. If these conditions are satisfied, this replacement is transparent from the point of view of the component context. Replaeability is especially important in the case when the new version of a component is introduced offering a contract compatible with the contract of the old component, but realized internally in a more efficient and/or effective way.

4.4 Representing Web Services Using Component Concepts Although the Web services technology is crucial for interoperability and communication of business applications across the network, we have to go above the pure technology to realize that a proper design of business-critical information, of services that use and create the information and collaboration scenarios among the services to satisfy given business goals, is of primary importance for the success of a service-oriented computing paradigm. The notion of a service is an integral part of component thinking. A component by definition provides a service. The service is the consumer view of component capabilities, shown in Figure 4.7. The concepts of component and service are complementary: components are providers of services, and given a service, one can determine a lot about the component that is supposed to provide it. The service forms a contractual agreement between provider and consumer. Beside a common interface that defines operation signatures, a service also has attributes of its own such as, a service level agreement, policies, dependencies, etc. A service interface defines a contract and the parties’ obligations precisely and thus allows the consumer to use the functionality offered without being aware of the underlying implementation (Apperly, 2003).

Figure 4.7 A service as the consumer’s view on a component

105

Chapter 4 There are a number of parallels between service-orientation and classical CBD. Like components, services represent natural building blocks that allow us to organize the capabilities of a system in ways that are meaningful to the user of the system. Similarly to objects and components, a service is a fundamental building block that combines information and behavior, hides the internal workings from the outside perspective and presents a relatively simple interface to the environment (Kaye, 2003). When using Web services technology, the component is not acquired in the traditional manner of taking a copy and executing it in the house, but rather the services provided by the component are consumed by an application via the Web while the component executes its function at a single location, available to all who subscribe (Newcomer, 2002). While their deployment perspectives are significantly different, the implementation and, especially, specification aspects of Web services and components are very similar. Since Web services are seen to be effective mechanisms for providing functionality in widely distributed architecture, their design should be considered in the light of minimizing the traffic on the network. Therefore one of the key design principles when designing Web services is very weak coupling that is required between the solutions using the Web services and the Web services being used. Effective usage of the Web services paradigm is not just exposing some object-oriented methods of an application as a Web service. This can create a limited benefit in the sense of application interoperability and integration, and it can also result in application maintenance problems and tight-coupled communication across the network (Zimmerman, Korgdahl and Gee, 2004). Therefore, design principles that ensure creating Web services with a proper granularity, cohesive functionality and loosely coupled from the rest of the system are of crucial importance for building enterprise applications that use the Web services paradigm effectively (Endrei et al., 2004). Web services are typically coarse-grained and fulfill clear business functions. This makes it easy and straightforward to model and specify them using the business component concept defined above. The main characteristics of Web services, similar to components, include: (1) they are self-contained executable units that provide a specific business service; (2) they have a standardized interface, which is used to communicate with other Web services; and (3) they are published on the Internet and can be used in a context that is unanticipated by their initial designers. Since Web services communicate via the network, it is crucial to define a proper business granularity of services to minimize potential communication overhead. The business components, as defined in this work, can be exposed as Web services for inter-enterprise communication and integration due to their coarser granularity and the business added value. They can also be used for intraenterprise integration and communication between business applications of a larger organization. In contrast, application components as defined here, because of their finer granularity and more technical focus, can be exposed as finer-grained Web services mainly for communication between the application parts inside the same organization. The reason for this is that potentially intensive communication between tightly-coupled, fine-grained components 106

Component Concepts and Definitions can result in too much overhead in a distributed, transaction-oriented environment that crosses the boundaries of an enterprise. The concepts of services and Web services help to provide common ground for the business and IT design and implementation perspective. So far, business people have not really understood the IT architecture made of objects, functions and subsystems. Now, they can easily express their business processes in terms of collaborating services. As in the case of components, two separate perspectives of Web services can be defined, that of a producer of a Web service and that of its consumer. From the service provider perspective it is important to define what component of the system can be exposed as a service, offering a business value to the consumer, while at the same time being, as much as possible, decoupled from the rest of the system. From the service consumer perspective it is important to determine what part of the system logical architecture can be realized by invoking a particular service over the Web, and how that part can interface with the existing organization’s system services and components. Balancing the needs of the service provider and the service consumer is crucial to achieving the true benefits of a service-orientation for business agility and inter- and intraenterprise integration. Further details about service-oriented modeling and design using proven component-based concepts and principles such as interface-based design and designby-contract will be given in chapter 6.

4.5 Discussion and Conclusion In this chapter we proposed the way of thinking of our component-based and service-oriented design and development method which fulfills the requirements on the way of thinking for a method defined in section 2.9 and justified by conducting the case study project discussed in section 3.5. Here, we introduced and defined the main component concepts that represent the foundation of the method. Instead of one single definition of a component that fits all possible forms and facets of components, we defined the essential properties, features, aspects and forms a component must or can have. Although many of the concepts and elements of our method’s way of thinking presented here are not completely new, i.e. built from scratch, there is no CBD method or approach that considers all different aspects of components to a sufficient detail, as stated also in (Ham, Kim, Cho and Ha, 2004) and (Boertien, Steen and Jonkers, 2004). The cornerstones of our component conceptual schema are as follows: ♦ basic component concepts that explain very nature of a component as a design as well as an implementation construct; ♦ specification component concepts that provide the complete information about the component without knowing its interior –a kind of the component contract to its context; ♦ different facets, forms and aspects of a component within a development process; ♦ precisely defined component-related terms such as reusability, replaceability, cohesion and coupling; 107

Chapter 4 ♦ ♦

discrete component granularity types as a basis for the use of component throughout the development process, from business to implementation; business components as service-based units well-suited for designing Web services.

We intentionally avoided proposing a single component definition that covers all possible purposes, views and component forms, since such a definition would be trivial. Instead, we went for defining the set of component concepts, properties and characteristics related to component usage and place in the development lifecycle. If we compare our component theory given in this chapter with the state-of-the-art survey findings presented in chapter two, especially in sections 2.8 and 2.9, we can conclude the following. Our component is mainly a design-level unit that represents the part of the solution architecture that will typically be implemented using software modules. This contrasts with the implementation and packaging view on components of most existing CBD methods and is similar to the definition of component given in UML 2.0. In this way, our component is a unit of domain or business functionality rather than a unit of deployment, as it is often defined, e.g. in (Szyperski, 1998) and (Booch et al., 1999). The basic component concepts, in a clear, technology-independent and consistent way, define the essential properties of components. These definitions can be applied easily to fields outside of software engineering, such as business engineering, organization engineering and system engineering. Features that are largely missing in most of the CBD methods and approaches presented in chapter 2 are an enriched and enhanced concept of component interface and a complete specification of it to represent a kind of a contract between the component and its consumers. While some of the CBD methods treat an interface as a simple set of method signatures (e.g. RUP), other methods enhance it with preconditions and postconditions defined on methods and with an interface information model to represent information types handled by the interface (e.g. UML Components). We go a step further in this direction to provide a complete interface representation and specification containing concepts from context to technology. Further, we consider coordination constraints among the provided and required services, and published and subscribed events of a component to be of very important elements of the component interface specification, which defines the full semantics of a component from the consumer point of view and provides correct and effective usage of its features. This coordination aspect of an interface is, in some form, present in the UML profile for EDOC, but more emphasized in Web services choreography standards, such as WSCI and BPEL. Our list of component specification concepts is by no means complete and closed. It can be extended with elements of interest in each of the four viewpoint categories depending on current purposes. For example, in a more business context features such as price, reliability and the level of trust may be more important and therefore added, or in a technology context, a communication message format and port number may be significant and considered accordingly.

108

Component Concepts and Definitions Due to their rather implementation perspective on components, the current CBD methods do not specify clearly the different forms and facets a component can have during the development process. They define implementation and deployment components (e.g. RUP) and some methods additionally use the specification view on components (e.g. UML Components and KobrA). However, there is no method, except BCF to some extent, that recognizes the conceptual power of the component paradigm as a mechanism to bridge business and IT concerns and as a way to organize business requirements and goals in a manner equally understandable to both business analysts and software architects. While the UML 2.0 specification does not consider this topic, the UML profile for EDOC proposes a similar role for the component concept within its enterprise collaboration architecture (ECA). When using components in system engineering, it is essential to define the levels of component granularity that can differ regarding scope, purpose, size, the level of abstraction, the way of using, etc., as stated in (Herzum and Sims, 2000; Boertien, Steen and Jonkers, 2004; Carey and Carlson, 2001). We define here four distinct component granularity types together with their main properties and ways of applying them within a development process. However, the presented CBD methods, as shown in section 2.8, mainly do not pay much attention to this topic. Even the UML 2.0 specification does not propose any discrete granularity types. Component granularity is well defined in BCF in the form of component systems, business components and distributed components, and in the UML profile for EDOC in the form of e-business components, application components, distributed components and program components. The focus of BCF is on business components that by their characteristics correspond to our application components, while our business components, as the focus of our method, correspond more to BCF’s component systems. This shows that the emphasis of BCF is rather on finer-grained components, business entities and elementary processes, while we are focused more on the higher-level business meaningful functionality that adds value to the user and can be exposed as a web service for the purpose of interenterprise collaboration and integration. The ‘UML for EDOC’ components, although having similar names to our component types, have different scopes, properties and heuristics than ours. Most of the presented methods consider components in an entity-driven manner, by defining components based on underlying domain entities, as it is the case in KobrA, UML Components, Catalysis and, to some extent, BCF. The importance of service-based, processoriented component units for bridging the business/IT gap and for the purpose of modeling and designing Web services and SOA is well defined in chapter 2. We define here a business component as a service manager that provides user-perceivable, business goal-oriented services for that reason. This is, to some extent, similar to BCF’s process components and component systems. A new version of Select Perspective also recognizes the importance of service components for designing Web services. In the UML profile for EDOC specification, a process component is defined as a component that performs some processing, which differs from static entity components. Finally, the UML 2.0 specification does not make a distinction 109

Chapter 4 between more process-like components and entity components, since it is not yet dedicated to support Web services and SOA A summary of the results reported in this chapter is given in what follows. The essential component properties namely, context, contract and content as the main elements of the blackbox and white-box views on a component and its context dependencies were introduced. We also discussed the essential property of every component defined as the ability to compose and/or be decomposed. This principle of recursive composition represents one of the cornerstones of the component way of thinking. A component needs to be precisely specified to be used in different contexts without knowing how its interior is realized. We proposed four viewpoints, namely context, behavior, information and technology, from which the specification of a component can be done reflecting the different aspects of a component. A complete component specification represents an integration of the viewpoint specifications. The defined component concepts must be placed in the context of a development lifecycle to design and build systems out of components. We defined the basic design principles for creating components, such as low coupling, high cohesion, the needs for reusability and replaceability, the balance between generalization and specialization, and different component facets during the component lifecycle. Since there is no one type of component that fits all purposes in component-based design and development, it is important to define the different types, granularity levels and scope categories that a component can belong to. We defined the following kinds of components and the relationships between components: enterprise components, business components, application components, and program components, each component having a particular set of characteristics and position in the development lifecycle. With the advent of the Web services paradigm, one of the challenges is how to represent, define and design services beyond pure technology. We proposed here a way to map the basic concepts of service-orientation into our component way of thinking and the component concepts presented here. Since our components are defined as service managers with contractbased interfaces, a representation of Web services using the concepts presented in this chapter is rather straightforward. Further details about the way our method fulfills the requirements of Web services and the service-orientation paradigm will be given in chapter six. UML 2.0 and the UML profile for EDOC propose a lot of well-structured object-oriented and component-based concepts and principles defining the way components are handled throughout the development lifecycle. We considered certain elements of these specifications when creating the way of thinking of our method. However, they are much richer in terms of number of concepts defined and, therefore, more complex than our component conceptual schema. Our intention was not to compete with these specifications in completeness and semantic power, rather to provide a consistent and rich enough set of component concepts that can be used as a foundation for a workable, simple, systematic and practical method that can be easily extended with concepts drawn from e.g. UML 2.0 if necessary.

110

5 Component Modeling Techniques and Notations The component concepts proposed in the previous chapter need to be modeled and specified in a way that provides clarity, understanding and communication among stakeholders throughout the development lifecycle. Therefore, proper modeling techniques and notations for representing component concepts will be introduced in this chapter. They constitute the way of modeling of the method and should be aligned with the requirements for modeling components defined in section 2.8. Depending on the kind of stakeholders that use the models for communication and mutual understanding, modeling techniques and an associated notation used for component modeling can be of different types, levels of detail and levels of abstraction. Three basic categories that we consider here are: ♦ a graphical modeling techniques and notation that use a classical box-and-line style and is illustrative enough to provide a common understanding among people involved in designing business and application architecture; ♦ a textual modeling techniques and notation that use the constructs of the 3rd generation programming languages such as C++ and Java, or that follow certain textual templates, and are therefore familiar to the persons involved in different levels of software development; ♦ a textual modeling notation that is readable by computer systems but not easily understandable for humans except for highly-skilled IT persons. Such notation is used for the communication between computer systems to expose the functionality of particular components in the form of Web services and for dynamic discovering and binding to the components across the Internet. We use the Unified Modeling Language (UML) as a basis of the graphical modeling language for components. This is a widely used standard object-oriented modeling language and therefore a natural choice. We use the standard Object Management Group (OMG) Interface Definition Language (IDL) to provide a basis for a human-understandable textual modeling for components (OMG-CORBA, 1999; Siegel, 2000). Finally, we base our computer-readable component modeling techniques and notation on the standard eXchange Markup Language (XML). It is important to note here that our aim is not to invent yet another modeling technique and notation, than rather to show how our component concepts introduced in the previous chapter can be expressed in various ways using existing modeling paradigms and standards. In what follows, we will show how these basic modeling notations can be extended to provide a modeling support for expressing the component and service concepts we 111

Chapter 5 introduced in chapter four. These different but mutually related and isomorphic modeling notations are able to serve the needs of different actors in a development process.

5.1 Modeling Components Using UML The versions 1.3, 1.4 and 1.5 of UML do not provide the necessary modeling and specification constructs to represent component concepts beyond the implementation level, as already stated earlier in this work. The Component Diagram in UML 1.x regards any physical software element as a component, thus it has an implementation and deployment focus on components. Component-based design and development methods that strictly follow the UML are forced to use the UML 1.x notation for components as implementation artifacts (Booch, Rumbaugh and Jacobson, 1999; OMG-UML 1.3, 1999). To represent components at the design level using UML versions 1.x it is necessary to make use of the extension mechanisms of UML, such as stereotypes, constraints and tagged values. Development approaches more focused on the component way of thinking use semantically more proper ways to represent components. To model components properly throughout the development lifecycle, Cheesman and Daniels (2000) use a corresponding stereotype of the class concept, Atkinson et al. (2002) and Apperly et al. (2003) use the UML concept of subsystem as a stereotype of package, while Herzum and Sims (2000) use simple free-form box-and-line notation for this purpose. However, a major revision of UML, version 2.0, is (at the moment of writing this thesis, 2004) being finalized (OMG-UML2, 2004). UML 2.0 represents a significant upgrade to UML. Among other improvements it provides mechanisms to define and use components throughout the development lifecycle, from modeling to implementation, see sub-section 2.7.2. Therefore, for the purpose of providing a graphical modeling notation to represent the component concepts proposed in chapter four, we will use version 2.0 of UML, although it has not yet been finalized, as our starting point. 5.1.1 Modeling Basic Component Concepts As already presented in sub-section 2.7.2 of the thesis, UML 2.0 introduces new concepts on top of the previous versions to support component-based design and development throughout the development lifecycle, from logical components to physical software components. The Component package is a part of the UML 2.0 specification that defines necessary mechanisms for representing different aspects of components. This package uses the Composite structures package to provide a representation of the internal structure of components. New elements introduced by UML 2.0 on top of UML 1.x and that are related to component concepts, include the following. ♦ Modeling of required interfaces that the component requires from other components is introduced. While UML 1.x offers just the provided interface and uses the stereotyped class icon for provided interfaces, in UML 2.0 both the provided and required interface 112

Component Modeling Techniques and Notations

♦

♦ ♦ ♦

can be represented using extended notation, and the ‘lollipop’ and ‘socket’ icons as shorthand visual notation. The concept of a port that represents an interaction point between the component and its context is introduced, similar to the corresponding concept in Architecture Description Languages. A port groups one or more services that specify the nature of the interactions that may occur over a port. Ports can support unidirectional or bi-directional communication. The interior of a component is fully isolated from its context by the port. The concept of a connector is introduced to represent the way communication occurs between two components or between the component and its internal structure. A connector can be of the assembly or delegation type. An explicit representation of component collaboration is provided by connecting a provided interface of one component with a required interface of another component using an assembly connector. Specifying the component decomposition is supported by modeling the interior of a component through the collaboration of internal components and their interaction with the component context through component ports and delegation connectors.

In UML 2.0, a component is a modular unit of a system that encapsulates its contents behind the interfaces and is replaceable within its environment. A component has one or more provided and required interfaces, accessible through ports. Components can be composed to form a coarser-grained component by wiring the compatible required and provided interfaces of the components being combined. A component can be also decomposed into finer-grained components. A component interface specifies operations, attributes and signals that the component can provide and require. Interfaces of a component can be grouped into a port, which defines an interaction point between a component and its environment, or between a component and particular elements of its internal structure. A component can have additional behavior definitions to specify its external view more precisely, for example, by defining the sequence of operations on its ports and constraints related to this. In what follows, the UML 2.0 modeling notation for expressing main component-related concepts will be given. A set of most important component-related modeling concepts and corresponding notation is given in Appendix A.

A 4.00 Unregistered ICustomerInfoTrial A 4.00 Unregistered Trial Port2

Port1

AIOrderMaker 4.00 Unregistered «component»Trial OrderManagement

A 4 00 Unregistered Trial Figure 5.1 Component representation in UML 2.0

113

Chapter 5 The component OrderManagement is shown in Figure 5.1 using a notation proposed by UML 2.0. The components are represented as rectangles with the stereotype . Optionally, a component icon, as defined in UML 1.x, can be displayed in the upper right corner of the rectangle, as a visual stereotype. A port is represented as a square. A provided interface is modeled using the classical ‘lollipop’ notation and required interfaces using the ‘socket’ (half-circle) notation. Several interfaces can be grouped in a port which can be named. An interface can also be represented in an extended format, using a rectangle symbol with the keyword «interface» preceding the name and with the lists of operations and attributes in separate compartments, see Figure 5.2. «interface»

egistered Trial Versio IOrderMaker +

OrderNo: int

+ makeOrder(char, : void egistered Trialint)Versio +

seeOrder(int) : Order

Figure 5.2 Component interface in UML 2.0 If this notation for interface is used, then providing an interface is modeled with a dashed line with a closed arrowhead at the end and with the stereotype , while requiring an interface is modeled with a dashed line with an open arrowhead at the end and with the stereotype . The same component OrderManagement from the example above is presented in Figure 5.3 using an extended notation for interfaces in the form of rectangle symbols.

stered Trial Version EA 4.00 Unregistered T «interface» IOrderMaker

stered Trial Version EA 4.00 Unregistered T stered Trial Version EA 4.00 Unregistered T «realize» Port X1

«interface» stered Trial Version «use» EA 4.00 Unregistered T ICustomerInfo

«component» Port X2

OrderManagement

stered Trial Version EA 4.00 Unregistered T Figure 5.3 Extended notation for modeling component interfaces To define how a component realizes its interfaces, the internal structure of the component is modeled using the concepts from the package for Composite structures. The internal structure of a component can consist of instances of finer-grained components. A port of a component can be connected to the instances of the sub-components to indicate that a particular subcomponent is responsible for the realization of interfaces provided at that port. Similarly, required interfaces from the port can be connected to an internal instance of the sub-

114

Component Modeling Techniques and Notations components that actually requires it to produce their services. A detailed model of the internal component structure is very important for considering the further decomposition of a component in the course of the development lifecycle in terms of finer-grained components that in collaboration realize the behavior of the given component. In UML 2.0, a delegation connector links the external contract of a component to its internal realization. A delegation connector can only be defined between interfaces of the same kind, e.g. between two provided interfaces or between two required interfaces. The internal (white-box) view of the component OrderManagement in the UML 2.0 notation is shown in Figure 5.4.

ial Version EA 4.10 Unregistered Trial Version EA 4.10 Unr «component»

Order Management

ial Version EA 4.10 Unregistered Trial Version EA 4.10 Unr «component» ial Version «component» EA 4.10 Unregistered Trial Version IRelationEA 4.10 Unr Order

CustomerRelation

ial Version EA 4.10 Unregistered Trial Version «delegate»EA 4.10 Unr IOrder

Port2 EAICustomerInfo ial Version EA 4.10 Unregistered Trial Version 4.10 Unr «delegate»

ial Version EA 4.10 Unregistered Trial Version EA 4.10 Unr Port1

ial Version EA 4.10 Unregistered Trial Version EA 4.10 Unr IOrderMaker

ial Version EA 4 10 Unregistered Trial Version EA 4 10 Unr Figure 5.4 The internal view of the component Now, that we have highlighted the basic component modeling notation given in UML 2.0, we need to define how the component concepts we define as necessary for component specification in Section 4.2 can be represented using UML 2.0 artifacts with some extensions if necessary. 5.1.2 Component Context in UML First, we have elements of the component context specification as defined in sub-section 4.2.1 namely a component identifier given its name, purpose and scope, its non-functional parameters, so called ‘ilities’ and elements that provide a richer representation of the component context, which is especially important in the case of business components. Since the information about these elements is mainly of a textual nature, we do not need to use the graphical elements of UML to represent them. Instead, we can use a textbox element of UML called note, defined as an annotation attached to an element or a collection of elements that

115

Chapter 5 provides some additional textual information about that element and that has no semantics, as shown in Figure 5.5.

al Version EA 4.10 Unregistered Trial Version Purpose: To make an order for the customer ICustomerInfo

Scope: Internet-based Conditions: Customer must be registered

al Version EA 4.10 Unregistered Trial Version al Version EA 4.10Port2 Unregistered Trial Version Port1

«component» alIOrderMaker Version EA 4.10 Unregistered Trial Version OrderManagement

al Version EA 4 10 Unregistered Trial Version Figure 5.5 A note containing context information about the component OrderManagement 5.1.3 Component Behavior in UML In the specification of component behavior, the UML 2.0 provides a good foundation for a graphical representation of it. However, we need to add some new elements and combine existing elements to represent properly the concepts of behavior component specification given in section 4.2.2. While in UML 1.x, a component defines only the provided interfaces, in UML 2.0 both the provided and required interfaces of a component can be specified. This reflects much more closely the nature of a component, which provides some services and interfaces to other components in the context, and also depends on its context in the sense that it uses some services and interfaces from other components to produce its behavior and satisfy its contract properly. This consuming aspect of a component in terms of specifying required interfaces is important at both design and implementation level. During component design, defined required interfaces of a component show the boundaries of the responsibilities of that component, and, as more important, in what way it is dependent on other components in the context. At the level of component implementation, the way to actually implement these dependencies should be decided upon, in terms of e.g. synchronous or asynchronous method calls, communication using a common data storage, or event publisher/listener interaction. The event is defined as “the specification of a significant occurrence that has a location in time and space and can cause the execution of an associated behavior.” The concept of event is mainly placed in the context of state diagrams where it is mostly related to an occurrence that can trigger a state transition. Although behavior in UML 2.0 is defined as “the observable effects of an operation or event”, in the definition of the behavior features of a classifier, in our case a component, only operations are mentioned explicitly and not events. Accordingly, an interface as a declaration of behavior features that a component offers and uses specifies only operations that it groups, but not events. Because of the importance of event-based intercomponent communication for further loose coupling between components, our opinion is that the concept of event needs to be further strengthened and formalized in the context of 116

Component Modeling Techniques and Notations components as an important part of a component interface, similar to how it is defined in the CORBA Component Model described in sub-section 2.3.3 (Siegel, 2000). Parallel to this, the UML Profile for EDOC specifies the separate Events profile that defines the integration of systems and components using events (OMG-UML4EDOC, 2004). Events can be published or received by entities and processes, and can be forwarded synchronously or asynchronously. According to the UML for EDOC, the event publishing and subscribing ports are usually attached to entity components, since the main source of a business event is a state change to a business entity. Our opinion is that the ports for publishing and subscribing events must be a part of the contract of a component of any kind and granularity to specify its event-driven communication with the context in either a synchronous or asynchronous way. The concept of interface in UML 2.0 is further improved on top of definitions given in UML 1.x and this fits well for describing our component concepts. In the current proposal of UML 2.0, interfaces, besides operations, can have properties that represent the types of attributes of these operations. The realization of the interface must provide a functionality that maintains the state represented by the properties of this interface. These properties actually represent a logical information model of the component, i.e. the instances of what information types, and their relationships, the component must be aware of and handle in different ways to produce its behavior. This will be further explored later in the text in the context of the component information specification. Interfaces in UML 2.0 are also enriched in other ways, which helps us to represent our concepts using the UML standard without defining too many extensions. Various types of constraints and obligations can be associated with an interface in the form of pre-conditions, post-conditions and guarantees. This provides us with the way to model fully contract-based interfaces using the concepts of the ‘design-by-contract’ theory defined, among other sources, in (Mayer, 1997) for the purpose of creating the programming language Eiffel. It is important to note that there is a mapping between domain conditions presented in the context viewpoint in informal way and the constraints on corresponding services in the behavioral viewpoint presented in a more formal way. For example, the context condition from Figure 5.5 that a customer must be registered before the component OrderManagement is activated is mapped into corresponding formal pre-conditions that guard invoking services of the component unless the condition is fulfilled. The best way to represent these constraints is to use the standard Object Constraint Language (OCL), now also in the process of finalization towards the version 2.0, as this raises the expressive power of the previous version (Warmer and Kleppe, 2004). The version 2.0 of OCL brings a number of improvements over the old version 1.4. For example, an OCL message expression that represents the sending of a signal, or the calling of an operation, has been added. This allows the specification of assertions and side-effects, which is very useful in designing component based applications. Further, additional attributes and operations to a class or a component can be defined in an OCL expression. These attributes and operations 117

Chapter 5 can be used in any OCL expression. OCL constraints can be placed inside the notes that are associated with the interface on which the constraints are applied, as shown in Figure 5.6.

10 Unregistered Trial Version EA inv: 4.10 Unregistered Tria context Order - pre and post-conditions pre: 10 Unregistered Trial Version EA 4.10 Unregistered Tria Order.Amount > 0 Order.Customer = Customer.Name

10 Unregistered Trial Version EA 4.10 Unregistered Tria post: Customer.Balance = Customer.Balance - amount

10 Unregistered Trial Version EA 4.10 Unregistered Tria «interface» 10 Unregistered Trial Version EA 4.10 Unregistered Tria +

IOrderMaker OrderNo: int

+ +

makeOrder(char, int) : void seeOrder(int) : Order

10 Unregistered Trial Version EA 4.10 Unregistered Tria 10 Unregistered Trial Version EA 4.10 Unregistered Tria Figure 5.6 Interface constraints in OCL As we stated in section 4.2.2, we need a way to represent the order in time of provided and required operations, and published and submitted events of a component, since this defines constraints on interactions through the interface. We call this type of constraint a coordination constraint. These coordination constraints cannot be represented in UML 1.x, but now UML 2.0 provides the techniques to specify them using the protocol state machine modeling concept. In this way, the behavior viewpoint of a component can be specified more precisely in terms of what sequence of interactions, operations or events, can occur exactly on the ports of a component so that it produces expected behavior. We propose the use of a UML activity diagram for the purpose of representing coordination constraints that exist among the services and events within a component interface, where nodes of a diagram are operations and events of the component that need to be coordinated, as shown in Figure 5.7. This model accompanies other models that express a given component in detail. A similar idea is presented in the UML for EDOC for representing the protocol of communication between two components. Coordination constraints on the operations of a component interface can be also represented in terms of pre-conditions and post-conditions related to the operations. For this purpose, the OCL constructs can be used, enriched with particular temporal predicates, such as before, after, and parallel to, similar to what is given in (Conrad and Turowski, 2003). Regarding the behavior viewpoint, we need to specify context-aware configuration parameters that allow the customization of a component according to its context. While both UML 1.x and UML 2.0 do not provide a mechanism to specify eventual configuration parameters of a component, that possibility exists in the UML profile for EDOC. In UML for EDOC, a configuration parameter is called a property and it is defined by its name, type and initial value. The definition of configuration parameters of a component through the three given 118

Component Modeling Techniques and Notations elements is placed in a separate compartment of the rectangle icon used to represent a process component. This is a mechanism that also needs to be included in UML 2.0, especially because UML 2.0 is supposed to supersede the UML for EDOC specification. We propose that configuration parameters of a component can be represented by placing the template in the component icon, but also as a note attached to the component icon. 0 Unregistered T rial Version EA 4.10 Unregistere Start

0 Unregistered T rial Version EA 4.10 Unregistere 0 Unregistered T rial Version EA 4.10 Unregistere M akeOrder 0 Unregistered T rial Version EA 4.10 Unregistere 0 Unregistered T rial Version EA 4.10 Unregistere CheckOrder

0 Unregistered T rial Version EA 4.10 Unregistere 0 Unregistered T rial Version EA 4.10 Unregistere Order Correct? Yes

0 Unregistered T rial Version NoEA 4.10 Unregistere 0 Unregistered T rial Version EA 4.10 Unregistere SendOrder

TerminateOrder

0 Unregistered T rial Version EA 4.10 Unregistere 0 Unregistered T rial Version EA 4.10 Unregistere 0 Unregistered T rial Version EA 4.10 Unregistere Success

Fai lure

Figure 5.7 Coordination constraints represented by an activity diagram 5.1.4 Component Information in UML From the information viewpoint we need to specify the information types that are related to the interface properties described above and the associations between these types. These types can be considered as the types of operation parameters and the information (data) types related to them. The specified information types are abstract and they indicate that the component instance, or instances of its sub-components, should handle the information of those types in terms of creating, modifying, storing or simply using them. Therefore, having a certain information type listed in the component specification does not necessarily mean that the component instance, or instances of its sub-components, is responsible for the whole lifecycle of instances of the type, it can also suggest that it needs these instances as parameters for its operations from the context in the run-time. The component should simply be aware of the

119

Chapter 5 existence of such an information type, its format and structure, and should know how to obtain the instances of the type when it is necessary. The set of information types associated with a component, together with the associations among them, represent a logical information model of that component. This suggests that the component maintains these information types at the logical level by specifying them in its contract specification, but it is not necessarily responsible for maintaining their whole lifecycle at the instance, physical level. Information types that belong to the logical information model of a component are represented using a standard class diagram, with listed attributes only. The constraints on instances of an information type are called invariants, and they must be true for all the instances of that type. Invariants can be represented using the OCL constructs according to the design-by-contract theory (Meyer, 1997), and placed in the textual notes associated with the icon of the information type. Associations among the types are represented together with associated multiplicities. A logical information model of a component is shown in Figure 5.8. «business-entity» Order

«business-entity» Customer

tered Trial Version EA 4.10 Unregistered Tria -

AmountMoney: long ID: int CustomerInfo: char

1..*

-

ID: int Name: char

tered Trial Version EA 4.10 Unregistered Tria tered Trial Version EA 4.10 Unregistered Tria 1..*

tered«business-entity» Trial Version EA 4.10 Unregistered Tria OrderItem - Name: char tered Trial Version EA 4.10 Unregistered Tria - Number: int

tered Trial Version EA 4 10 Unregistered Tria Figure 5.8 A logical information model of a component If a component maintains the whole lifecycle, from creation to deletion, of the instances of a certain information type listed in its contract, a discrete behavior of these instances through the finite transition of states is represented using the state-transition modeling constructs. UML 2.0 offers a behavioral state machine for this purpose, which is an object-based variant of Harel statecharts and that can be used to model the discrete behavior through time of information type instances, as shown in Figure 5.9. Constraints can be associated with edges of a behavior state machine diagram to show what operation causes the transition of an information instance from one state to the other and under what conditions. These constraints are naturally represented using OCL.

120

Component Modeling Techniques and Notations Trial Version EA 4.10 Unregistered Trial Version EA 4 Start CreateOrder( ) Trial Version EA 4.10 Unregistered Trial Version EA 4 Order Created

Trial Version EA 4.10 Unregistered Trial Version EA 4 CheckOrder( Trial Version EA) 4.10 Unregistered Trial Version EA 4 Checked Order Sent SendOrder( ) TrialOrder Version EA 4.10 Unregistered Trial Version EA 4 Final1

Trial Version EA 4.10 Unregistered Trial Version EA 4 DeleteOrder( ) Deleted TrialOrder Version EA 4.10 Unregistered Trial Version EA 4 Final2

Trial Version EA 4 10 Unregistered Trial Version EA 4

Figure 5.9 A behavior state diagram for the instances of the type Order 5.1.5 Component Implementation in UML The implementation perspective of components in UML 2.0 is presented using deployment diagrams that are strongly linked with component diagrams. A deployment diagram represents the execution architecture of a system. It provides a relationship between physical elements of the system as nodes, such as computers, Web clients, servers, peripherals, etc., and software artifacts that reside in these nodes of the network in the run-time system. A deployment diagram consists of nodes and connections between these nodes. As defined in UML 2.0, a node is defined “a run-time computational resource, which generally has at least memory and often processing capability. Run-time objects and components may reside on nodes.” The nodes can be defined in a nested manner, which means that several smaller nodes can be part of a single larger node. A connection between nodes depicts the communication path used by the hardware to communicate and usually indicates the protocols such as TCP/IP. The nodes in a deployment diagram host artifacts. An artifact in UML 2.0 is defined as “a physical piece of information that is used or produced by a development process.” The artifacts can be, for example, source files, binary files, tables in a database, scripts, library files, etc. An artifact may constitute the implementation of a deployable component. An artifact defined by the user represents a concrete element in the physical world. An artifact is presented using an ordinary class rectangle with the stereotype «artifact». An artifact is a manifestation of one or more model elements such as logical components. This relationship between a model element and a physical artifact, that is its manifestation in the run-time, is notated as a dashed line with an open arrowhead labeled with the keyword from the artifact icon to the icon of component that this artifact manifests. Furthermore, it is possible to specify the artifacts of a component that hold the executable code to realize the component in the “artifacts” segment of the component icon, if desired. Further details about the technology view on a component, such as a programming language to be used for its implementation, an operating system where it can reside, the network protocols and bindings 121

Chapter 5 to be used for communication with the component across the network, can be specified in a separate textual document or as a note textbox associated with the component icon. An example of a deployment diagram is shown in Figure 5.10. g

g Application Serv er

egistered Trial Version EA 4.10 Unregistered Trial Version EA 4.1 Client Tier «artifact»

«artifact»

TCP/IP

Customer.java «artifact» egistered Trial Version EA 4.10 Unregistered Trial Version EA 4.1 OrderForm OrderMake.java

egistered Trial Version EA 4.10 Unregistered Trial Version EA 4.1 egistered Trial Version EA 4.10 Unregistered Trial Version EA 4.1 TCP/IP egistered Trial Version EA 4.10 Unregistered Trial Version EA 4.1 Data Tier

egistered Trial Version EA 4.10 Unregistered Trial Version EA 4.1 «artifact» Customer.db

egistered Trial Version EA 4.10 Unregistered Trial Version EA 4.1

Figure 5.10 A deployment diagram of a system 5.1.6 Component Stereotypes The component can be labeled with various stereotypes to represent different kinds and variants of components in UML. In UML 1.x the stereotypes of components are, for example, , , , ,

, etc., which clearly shows an implementation perspective on components in UML 1.x. In UML 2.0 other component stereotypes are defined that reflect a logical perspective on components on top of a physical perspective, such as , , , and . A component labeled with an entity stereotype is a component that represents a business concept and handles persistent information. A component labeled with a process stereotype represents a transaction-based component that performs some activities and transactions. A component with a service stereotype represents a stateless, functional component that produces an output based on an input without persisting information. In UML 2.0 a subsystem is a subtype of a component concept, which is an attempt to resolve the confusion about these two concepts in the past versions. A subsystem is defined as a unit of hierarchical decomposition for large systems that is commonly instantiated indirectly. It may define specification elements and realization elements that realize them, similar to those defined in the previous UML versions. Beside abovementioned stereotypes, we can define the stereotypes that represent different types of components that we defined in sub-section 4.3.3, namely enterprise components, business components, application components and implementation components. It is worth noting that the definition of stereotypes for our component types is orthogonal to the stereotypes defined in UML 2.0 in a sense that a component can be labeled with two stereotypes simultaneously, one stereotype from the UML 2.0 group and another one from our 122

Component Modeling Techniques and Notations group of stereotypes. For example, an enterprise component can be labeled as process or subsystem, a business component as process, service, or subsystem, application component as process, service or entity, and an implementation component can be labeled using all four stereotypes. The UML 2.0 component stereotypes represent the type and associated characteristics of a stereotyped component. In addition to this, our stereotypes are used to express the place of the component in the development lifecycle, and the level of its abstraction from technology details. The entities of the component information model can also be stereotyped using e.g. stereotype, or, if organized as a component, using stereotype. Each stereotype can be accompanied by a set of constraints that more precisely define the properties and peculiarities of a certain component type. Properly used, the stereotypes and their constraints raise the expression power of UML for representing different types of components and different aspects of their usage throughout the development lifecycle. 5.1.7 Component Package All the elements of a component specification described above and taken together provide the complete picture of a component through different aspects – context, behavior, information and implementation. We can group the UML modeling elements that represent different aspects and concepts of a component in the form of a UML package that serves as a specification document about the component in UML. In UML 2.0, a package is used to group elements and provide a namespace for the grouped elements. A package can also own other packages. A package in UML 2.0 is shown as a large rectangle with a small rectangle attached to the left side of the top of the rectangle. The members of the package are placed within the package rectangle or might be placed outside the package and connected to it using branching lines. We can organize a component package into a component context package, component behavior package, component information package and component implementation package, each of them reflecting a particular viewpoint on a component. Further package decomposition is possible depending on needs. A set of most important component-related modeling concepts and corresponding notation is given in Appendix A. In Table 5.1 we summarize the mapping between the elements of component contract specification defined in chapter four and the constructs of UML 2.0 used to model them. When the concept is not supported by the current version of UML 2.0, we use particular modeling mechanisms of the UML profile for EDOC. Based on Table 5.1 it can be concluded that UML 2.0 (with some additions of UML for EDOC) and OCL 2.0 provide sufficient modeling mechanisms and techniques to represent our component concepts introduced in chapter four. When necessary, built-in extension mechanisms of UML, stereotypes and tagged values, can be used to enhance expressive power to present our concepts in a detailed and more precise way.

123

Chapter 5 Table 5.1 Mapping of the elements of component specification to UML 2.0 constructs Component concepts Purpose, scope, policies Non-functional parameters Provided and required interfaces A set of cohesive interfaces (services) Events – published and consumed Parameters of interfaces Constraints on operations (pre-conditions and post-conditions) Coordination of operations and events on interfaces Configuration parameters Information types Information types instances lifecycle Constraints on information instances Component implementation Component executables Component technology details Component granularity types Component composition using interfaces Component composition using operation flows

UML 2.0 constructs Text within the notes Text within the notes Interfaces Port Parts of the Event profile in UML for EDOC, not explicit in UML 2.0 Properties OCL 2.0 constructs as a text within the notes Activity diagram, protocol state machine or OCL 2.0 constructs in the notes Properties in UML for EDOC, not explicitly supported in UML 2.0 Class diagrams Behavior state machine OCL 2.0 invariants within the notes Deployment diagram Artifacts Text within the notes Component stereotypes Assembly connectors Component sequence or communication diagrams

5.1.8 Modeling Component Collaboration The collaboration of components is modeled using the assembly connector that represents wiring or assembling components assuming the compatibility between a provided interface of one component and a required interface of another component. An assembly connector is represented using a “lollipop-and-socket” connection, as shown in Figure 5.11. Com pone ntX

P o rtX Compone ntY P o rtY

Figure 5.11 Assembling two components using an assembly connector An assembly connector can only be defined from a required interface to a provided interface. The provided and required interfaces assembled by a connector must be compatible, i.e. the

124

Component Modeling Techniques and Notations contract specified by a provided interface of one component must satisfy the requirements of the required interface of another component. A coarser-grained component can be composed by assembling two or more components in this way. In this case, assembled components are placed inside the rectangle icon of the composed component and represent an internal realization of its contract. it is possible to represent how interfaces of a composed component are realized in terms of interfaces of its sub-components by using the concepts of ports and delegation connectors, as already explained in sub-section 5.1.1 and shown in Figure 5.4. To represent more detailed aspects of interactions between components in fulfilling a particular goal at the level of single operation flows, we suggest using UML interaction diagrams that can be in the form of sequence diagrams and communication diagrams, formerly collaboration diagrams in UML 1.x. We prefer to use sequence diagrams because of their high expressive power and a number of improvements defined in UML 2.0. While in UML 1.x the sequence diagram is used mainly to show the flow of method invocation between the objects of given classes that are represented on the horizontal axis of the diagram, in UML 2.0 it has a wider meaning and purpose. The sequence diagram in UML 2.0 represents the exchange of messages and occurrences of events among a number of interacting entities defined as lifelines. We represent a collaboration, or interaction, among components by introducing the instances of components as lifelines, creating in this way a component-based sequence diagram, as illustrated in Figure 5.12. If a certain component is indirectly instantiated, meaning realized by several sub-components, then these sub-components can be placed as separate lifelines in the diagram, showing at the same time the interaction of the composed component with the context, internal interaction among sub-components and the interaction between the component context and content. Other, more sophisticated capabilities of the UML 2.0 sequence diagram can be used to represent the whole protocols of interaction between components, such as sequences, alternatives, parallelism, loops, time constraints, etc. OrderForm CustomerRelation Order Sender 4.10 Unregistered Trial VersionOrderManager EA 4.10 Unregistered Trial VersionOrderDB EA 4.10 Unregistered Tr Customer

4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Tr Fill Order

4.10 Unregistered TrialProcess Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Tr Order 4.10 Unregistered Trial Version EA Check 4.10Customer Unregistered Trial Version EA 4.10 Unregistered Tr Details InfoUnregistered Checked 4.10 Unregistered Trial Version EA 4.10 Trial Version EA 4.10 Unregistered Tr Order Store 4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Tr Send Order

4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Tr Acknowledgment

4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Tr Order Sent OK

4.10 Unregistered Trial Version EA 4.10 Unregistered Trial Version EA 4.10 Unregistered Tr

Figure 5.12 A component-based sequence diagram 125

Chapter 5 5.1.9 Alternative Component Modeling The UML notation need not be the only notation used to represent component concepts during the development lifecycle. For particular projects that follow more agile development strategy, this extensive modeling can slow down the progress of the project, cause ‘analysis paralysis’ and result in not delivering the final solution on time. In such projects, a simpler modeling notation can be used to sketch easily the problem and solution area, provide a common understanding across the project and among business and IT participants, and to easily create a blueprint of a component-based system architecture. For the purpose of high-level business component modeling as an alternative way we propose a Component-ResponsibilityCoordinator (CoRC) card, shown in Figure 5.13, which represents a variant of a well-known Class-Responsibility-Collaborator (CRC) card (Wirfs-Brock, Wilkerson and Wiener, 1990).

Figure 5.13 Component-Responsibility-Coordinator (CoRC) cards Using the cards, the basic properties of a component are specified without going into detail, which is an effective solution for communication with business users (analysts) of the system. The upper part of a CoRC card is reserved for a component name and eventually its scope and purpose if that is not clearly reflected by its name. The left part of the card icon is reserved for component responsibilities that can be of two basic types: (i) knowing something, dealing with some information or being a contact point for information, and (ii) doing something or performing some activity, transformation of information, or control. The right part of the card icon is reserved for the list of components and their particular interfaces the given component interacts with, as well as the coordination in time of doing-something responsibilities as provided interfaces and required interfaces from components listed in the compartment ‘Coordinator’. Collaboration and coordination among components can be represented further using links between corresponding CoRC cards labeled with the consecutive numbers that represent their sequence in time. The next step in representing a component using a CoRC card is to provide a provisional grouping of its responsibilities using high-cohesion and low-coupling principles. This represents an initial decomposition of a component into its sub- components that can be also represented using CoRC cards. A sub-component inherits the coordination relations with other components from its parent component.

126

Component Modeling Techniques and Notations

5.2 Textual Representation of Components The graphical modeling notation using UML presented above satisfies the main purpose of modeling as means of providing better communication and mutual understanding, according to the saying that “a picture is worth a thousand words”. However, a textual notation can be more appropriate for particular purposes and the context of usage. For example, not all the properties of the modeled elements can be derived from graphical diagrams unless the attached textual documents or property dialogs of a modeling tool are considered. Graphical models often serve to suppress some details of a modeled situation to enhance understanding and reduce complexity. Therefore, to express all the properties of the modeled elements, it is often more convenient to represent them using a linear textual format. Furthermore, a textual notation that follows a grammar style taken from third generation programming languages, such as C++ and Java, provides, especially for IT people, a way to communicate ideas using familiar declarations and syntax, but still at a higher abstraction level than the software code. IT developers may prefer to create models using a textual language-independent notation rather than using graphics. Because of syntax and semantics similarities, this textual notation can be easily mapped to the software code statements and vice versa using advanced tools. Finally, using a textual notation provides a more formal way for the specification of system constructs than it is the case with graphical models. In the following sub-section, we will explore the possibility of defining a textual modeling notation for representing the component concepts given in chapter four in terms of what is currently available to serve our purpose and in what ways that can be extended and improved to satisfy all our requirements. Our starting point will be Object Management Group’s Interface Definition Language (IDL), which represents an ISO International Standard, number 14750:1999 for specifying interfaces of distributed components in the context of CORBA Component Model (OMG-CORBA, 1999; Siegel, 2000). There are also different proprietary variants of IDL such as Java IDL and Microsoft IDL that share a lot of commonalities with the OMG IDL presented here. 5.2.1 Component Modeling using IDL The OMG IDL is a purely declarative language designed for specifying programminglanguage-independent interfaces of computing entities in a distributed environment. OMG specifies a mapping from IDL to several different programming languages, including C, C++, Smalltalk, COBOL, Ada, and Java. When mapped, each statement in OMG IDL is translated to a corresponding statement in the programming language of choice. The IDL typically specifies component interfaces in terms of module names, interface names, structured types, and signatures of operations. A signature defines the operation name, return type, argument modes and types and possibly, an exception type. The last version of IDL 3.0 that forms a part of the CORBA Component Model (CCM) standard provides important mechanisms for defining components in a language-independent way as a basis for their deployment to the 127

Chapter 5 platform and language of choice (OMG-CORBA, 1999). A component in CCM is defined as having various surface features through which the consumers of its services can interact with it. These surface features in CCM are called ports. The CCM supports the following basic kinds of ports as already described in sub-section 2.3.3 – facets, receptacles, event sources, event sinks and attributes. The previous version of CORBA IDL was enriched with the grammar constructs to represent these component ports. A component definition in IDL implicitly defines an interface that supports the features defined in the component definition body. It extends the concept of an interface definition to support features that are not supported in interfaces. In what follows, we will present the most important elements of a component representation using IDL 3.0. A component definition starts with the component header that consists of the keyword component, an identifier that names the component type and the equivalent interface, an optional inheritance from a component type defined previously, and an optional support for one or more previously defined IDL interfaces. Next to the header, a component body is defined. A component body can contain the following kinds of port declarations: ♦ Provides – declarations of facets, i.e. provided interfaces; ♦ Uses – declarations of receptacles, i.e. required interfaces; ♦ Emits or publishes – declarations of event sources; ♦ Consumes – declarations of event sinks; ♦ Attributes – declarations of component configuration parameters. The declarations of facets, receptacles, event sources, event sinks and attributes map onto operations on the component’s equivalent interfaces that are defined in IDL. The types of their parameters also need to be defined for these interfaces. The IDL specification supports the definition of basic types and constructed types. Basic types include integers, floating point and fixed-point real numbers, characters, strings, Boolean, etc. Constructed type includes the structure, union and enumeration. Furthermore any CORBA object can be also defined as an IDL type so that CORBA object references can be passed throughout the system as parameters in operation invocations. More details about IDL 3.0 can be found in (OMG-CORBA, 1999). An example of the IDL description of component OrderManagement is given in Figure 5.14. In comparison to the capabilities of UML 2.0 to express the structural, behavioral and dynamic views on component specification, described above, the OMG IDL 3.0, although providing a set of useful component and interface-based constructs, still has lower expressive power. IDL describes the syntactic part of a component's interface, but it does not help to specify semantics. Therefore, to be used effectively for specifying the component concepts that we define in this research, it needs to be extended in several important ways.

128

Component Modeling Techniques and Notations interface IOrderMaker { struct Order { string name; integer number; }; Order create(in string nm, in integer No); void delete(in integer No); string status(in integer No); }; interface ICustomerInfo { struct Customer { string name; integer Id; }; Customer C_info (in integer p); }; component OrderManagement { provides IOrderMaker toClient; uses ICustomerInfo fromCustomer; };

Figure 5.14 IDL description of the component OrderManagement 5.2.2 A Component Definition Language to extend IDL Since IDL is a general purpose declaration language for defining object interfaces in distributed settings, a number of IDL extensions and supplements have been proposed to satisfy the needs for expressing the characteristics of various domains including real-time, quality of service, behavioral, synchronization annotations, etc., see (Jacobsen and Kramer, 2000). Our aim here is not to propose yet another extension of IDL in detail, but rather to define the ways and mechanisms that need to be incorporated into the IDL to specify the component concepts we define in chapter four of this thesis. A component definition language (CDL), that extends and complements current IDL 3.0 to address our component concepts and features need to support and express: ♦ OMG IDL syntax for constant, type and operation declarations so that it represents a strict superset of IDL; ♦ information about a component’s purpose, scope, policies, as well as non-functional parameters related to its operations; ♦ constraints on interface operations in terms of pre-conditions, post-conditions and guarantees for specifying semantically rich behavior; 129

Chapter 5 ♦ ♦ ♦ ♦ ♦ ♦

coordination constraints specifying the order in time of provided interface, required interfaces, published events and consumed events; a logical information model of components beyond simple and structured data types invariants on the instances of given information types; additional constructs defining specific kinds of components, such as business components that include business rules, processes, and events; constructs for specifying component composition and decomposition; computing environment specification.

A CDL should be a strict extension of the OMG IDL, which means that the IDL features, such as operations, attributes, exceptions, multiple inheritance and name spaces must be supported. Information about the purpose, scope and policies can be specified in a component header as textual information in the comment lines. Non-functional parameters of a component can be specified in the form of a rely/guarantee contract. A close relation between these parameters and particular interfaces of a component can be made, for example the level of performance and confidentiality defined for particular component functionality. Pre-conditions, postconditions, guarantees and other constraints on component behavior in a semantic-based manner can be expressed using the Object Constraint Language (OCL) constructs adapted to fit into the IDL syntax. Coordination constraints that exist among interfaces and events defined for one component can be specified using the extensions of standard OCL with the constructs to represent the sequence of events and operations and their ordering in time. Dedicated keywords, such as before, after, parallel to, if-then-else, etc, can be used to express coordination constraints, in a similar manner as that proposed in Conrad and Turowski (2003). The Object Definition Language (ODL), as a data definition standard proposed by the Object Data Management Group (ODMG), can be used for the purpose of defining a logical component information model that specifies information types of which operation parameters are instances (Cattell and Barry, 2000). ODL is a specification language used to define the object types that conform to the ODMG Object Model and it is based on the OMG IDL. This is a declarative (nonprocedural) language. ODMG defines the bindings of ODL to particular programming languages, such as C++, Java and Smalltalk, which implement the object language modeling standard. Invariants related to instances of the specified information types can be again specified using OCL constructs. It is necessary to extend the IDL with compositional mechanisms that specify the ways for gluing components together. The characteristic of a component, to be either primitive or composite, needs to be defined in the component IDL header. A composite component contains other components, which can be primitive or composite. Two sub-components inside a composite component interact by binding a required interface of one component with a provided interface of the other component. Therefore, a CDL, as a component-based IDL, needs to provide compositional mechanisms to capture this hierarchical organization of components. 130

Component Modeling Techniques and Notations IDL 3.0 provides a mechanism to represent configuration parameters using the component port Attributes, which represent named values exposed through the operations accessor and mutator, which are used primarily for component configuration. However, since the IDL expressions are close to programming language statements to provide easy mapping and binding, we need to define the information about component dependencies on development and execution environments, i.e. on programming languages, object models, machines, operating systems, middleware, etc. This information can be used to automate the integration of heterogeneous component instances into an executable distributed system. We summarize the mapping between the elements of component contract specification defined in chapter four and the constructs of IDL 3.0 with extensions, as given above, in Table 5.2. Table 5.2 Mapping between the component specification elements and IDL 3.0 constructs Component concepts IDL constructs Purpose, scope, policies IDL comment lines Non-functional parameters IDL comment lines Provided and required interfaces Provides and Uses keywords Events – published and consumed Emits (Publishes) and Consumes keywords Parameters of interfaces Operation parameters Constraints on operations, pre-conditions OCL constructs embedded into the IDL and post-conditions grammar Coordination of operations and events on OCL constructs embedded into the IDL interfaces grammar, temporal OCL extensions Configuration parameters IDL Attributes Information types Built-in types, Object Definition Language (ODL) constructs Information types instances lifecycle ODL constructs Constraints on information instances OCL constructs embedded into the IDL grammar Component implementation Bindings to a particular programming language Component technology details Comment lines Component granularity types IDL Component types and inheritance Component composition using interfaces IDL enriched with compositional semantics 5.2.3 Related Work Alongside the defining and standardizing of OMG IDL as a textual notation for specifying the interfaces of distributed components and objects in a programming-language-neutral way, other specifications with the same objective have been proposed. Since our aim here is neither to provide a comprehensive review of all these specifications, nor to propose yet another

131

Chapter 5 component definition language, in what follows we will just present the most important initiatives in this direction. In 1996, the Object Management Group (OMG) initiated the Business Object Domain Task Force (BODTF), which was the initial focal point for standardization of a Business Object Component Architecture (BOCA) (Digre, 1998). One of the goals of BOCA was to close the semantic gap between analysis and design on the one side and implemented and executed components on the other side. BOCA was a technology specification that explicitly defined the way to progress from designs, expressed in UML, to executing business objects. Specifying this link allows users to have a unified and consistent development lifecycle that traces from design to running code. The Component Definition Language (CDL) is a part of the BOCA proposal. CDL is an extensible declarative specification language that can be used to describe higher-level domain components expressing the domain specific semantic requirements, called contracts, in an implementation independent manner. The contractual specifications are supported by CDL. The contract isolates the domain specification from the technology implementation, defining enterprise entities on top of an evolving technical infrastructure. CDL provides mechanisms to describe component composition at multiple levels. The CDL grammar is a superset of IDL with additional constructs to support formally semantic component concepts (Siegel, 2000). CDL is simply a way to write down, in a textual form, business object specifications that use the BOCA meta-model. CDL captures the semantics expressed in business objects and components, and models attributes, operations, states, business rules, events and bi-directional relationships. The BOCA implementation is incorporated into the IBM SanFrancisco Framework (Carey, Carlson and Graser, 2000). Components in BOCA CDL are expressed in terms of externally visible interfaces and semantics, not the implementation. The syntax and semantics of BOCA CDL, as in the case of OMG IDL, are meant to be understandable to the average applications developer in terms of the application domain. Business users are expected to encounter business semantics built into components with the assistance of advanced tools. The ability of the BOCA proof-of-concept framework to automate the generation of an implementation for a selected implementation target from a technology-independent CDL specification was demonstrated in June 1998. At the same time, the CDL specification was produced from a UML diagram. However, despite these success stories and initial enthusiasm, the BOCA approach was rejected by OMG in late 1998. The initiative was torn apart by competing forces in the OMG standardization process. In 1999, BOCA was not voted in on the first pass as an OMG standard technology. Parts of the BOCA specification were resubmitted shortly in response to the multiple Request For Proposals (RFP), which replaced the original Business Object Facility RFP. Certain elements of BOCA have been spread over other OMG standardization initiatives, such as the CORBA Component Model and the UML profile for EDOC.

132

Component Modeling Techniques and Notations Parallel to these largely OMG-related initiatives, efforts in the field of software architecture have resulted in a number of Architecture Description Languages (ADLs). ADLs provide formal constructs for describing a software architecture represented as a collection of the components of a software system and their interactions. Proposed ADLs often focuses on different aspects of architectural specification, such as modeling the static structure, the dynamic behavior, or different architectural styles. An excellent overview of different ADLs and the links to dedicated web pages can be found on the Architecture Description Languages website of the Software Engineering Institute at Carnegie Mellon University (http://www.sei.cmu.edu/architecture/adl.html). Developing a single ADL providing all the features of the various ADLs would be a very complex task. Instead, an ADL called Acme has emerged as a general purpose ADL, that was originally designed to be used as a common representation of architectural concepts in the interchange of information between specifications with different ADLs (Garlan, Monroe and Wile, 2000). The benefits of ADLs are manifold. ADLs represent a formal way of representing architecture. ADLs are intended to be both human and machine-readable. They allow analysis of architecture completeness, consistency, ambiguity, and performance. However, there is not universal agreement on what ADLs should represent, particularly with regard to the behavior of architecture. Representations currently in use are relatively difficult to parse and are not supported by commercial tools. Therefore, the last few years have witnessed several attempts to map ADLs constructs to a modeling and specification language that is more widely used, has better tool support, and that is easier to learn and practice, such as UML (Medvidovic, Rosenblum, Redmiles and Robbins, 2002). The new UML 2.0 introduces rich architectural and component constructs that provide a powerful tool for describing software architecture and its mapping to software implementation using advanced UML design models (Bjorkander and Kobryn, 2003). 5.2.4 Concluding Remarks Our aim here was not to introduce in detail yet another textual notation for modeling components within system architecture, but rather to define requirements, ways and mechanisms that need to be included in the design of such a language to make it capable of specifying the component concepts defined in chapter four. This textual notation should be largely based on the new version of IDL 3.0, as a part of the CORBA Components standard (Siegel, 2000) enriched with the constructs derived from OCL 2.0. The notation should be also based on experiences and lessons learnt in the past within the BOCA research initiative, as well as from the present achievements in the field of architecture description languages, such as Acme, that are, to some extent, aside from the mainstream OMG directions.

133

Chapter 5

5.3 Machine-Readable Representation of Components With the rise of interest in the Web services framework as a platform for application-toapplication integration on the Web, there has been a strong requirement for the specification of a component that is exposed as a Web service in a machine-readable notation, so that its services can be invoked by other components across the Web. The various Web services interoperability protocols are based on eXtensible Markup Language (XML). We have focused here on the Web Services Description Language (WSDL) that represents a component definition language for Web service components (W3C-WSDL, 2004). WSDL addresses the problem of providing a machine-readable description of a service-based contract of a component. WSDL is based on XML and defines everything needed to access a service across the Web, from interface definitions to the specification of transport protocols and network addresses where the service can be found. The WSDL document of a Web service component has the following elements: ♦ definitions – the definitions element is the root element of a WSDL document. It defines the name of the Web service, declares multiple namespaces used in the reminder of the document and contains all the service elements described below. ♦ types – the types element defines all the data types used between the service provider and consumer. WSDL is not tied exclusively to a specific typing system, but it uses the W3C XML Schema specification as a default choice for reasons of maximum platform neutrality. ♦ message – the message element describes a one-way message in terms of a single message request or single message response. It defines the name of the message and contains zero or more message part elements that can refer to message parameters or message return values. The parts of a message can be compared to the parameters of a function call in a traditional programming language. ♦ portType – the portType element defines a Web service, the operations that can be performed, and the messages that are involved. It combines multiple message elements to form a complete one-way or round-trip operation. For example, a portType element can combine one request and one response message into a single request/response operation. The portType element can be compared to a function library or a class in a traditional programming language. ♦ binding – the binding element describes the concrete information of how the service will be implemented on the Web. It includes built-in extensions for defining Simple Object Access Protocol (SOAP) services. The binding element defines the message format and protocol details for each port. ♦ service – the service element describes the address for invoking the specified service. Most commonly, this includes a URL for invoking the SOAP service. In addition to these main elements, the WSDL document can also contain the following elements: 134

Component Modeling Techniques and Notations ♦ ♦

documentation – the documentation element is used to provide human-readable text and can be included inside any other WSDL element, similar to comment lines in traditional programming languages. import – the import element is used to import other WSDL documents or XML Schemas. This enables more modular WSDL documents.

An example of a simple Web service is shown below in Figure 5.15. This is a sample HelloWorld.wsdl document that was generated using the WSDL Editor of the Cape Clear Studio tool (http://www.capeclear.com). The service provides a single publicly available function, called sayhello. The function expects a single string parameter and returns a single string greeting constructed from the string input. We can make use of particular elements of the WSDL specification defined above for the purpose of specifying the component contract concepts defined in chapter four in a machine-readable format. In the definition element of the WSDL document, the name of the service and used namespaces are listed. The documentation element can be used for specifying other properties of the service, such as business purpose and scope, as well as non-functional parameters. Non-functional parameters of Web services, such as quality of service, pricing, and the level of security and reliability, are of crucial importance and need to be specified for the effective use of Web services across the Internet, especially in business-to-business collaboration. A logical information model of a component exposed as a Web service is specified in the type element of the WSDL document. The association between the information types also needs to be specified, which is the part of the XML Schema associated with the WSDL document. The WSDL document can define four types of operations inside the portType element: 1. one-way – the operation can receive a message but will not return a response; 2. request-response – the operation can receive a request and will return a response; 3. solicit-response – the operation can send a request and will wait for a response; 4. notification – the operation can send a message but will not wait for a response. The provided interfaces of a component can be specified using the standard request-response type of operations, while required interfaces can be specified using the solicit-response type of operations. Event consuming can be specified using one-way operations, while event publishing can be represented using notification operations. The configuration parameters of a service component can be specified in the message part of the WSDL document. They can be defined by its name, type and initial value. The use of these parameters in the definition of particular operations can show what functionality of the service can be configured and adapted using the parameters according to changing circumstances in the environment.

135

Chapter 5

























Figure 5.15 The WSDL document of the HelloWorld example – the file HeloWorld.wsdl

136

Component Modeling Techniques and Notations Invariants defined on information types, as well as pre-conditions and post-conditions defined on service operations, can be specified by embedding OCL constructs into a WSDL document. Similar efforts are under way to enrich the syntax representation of a service in WSDL with more semantics, such as the constructs of design-by-contract. The WSDL specification essentially permits definition of the static interface of a Web service. Operations in a WSDL portType are grouped into a single interface but they are independent and the WSDL grammar does not permit specification of any relation or required sequencing of operations within a portType. Hence the interaction model of a WSDL portType is stateless and static without any correlation of interactions at the interface defined. Additionally WSDL describes interfaces from the perspective of a Service (provider) and hence it is geared toward a client-server model of interaction. Collaborative process models typically involve both client-server and peer-to-peer type interactions with long running and stateful conversations involving two or more parties, which WSDL is not equipped to deliver. A Web services Choreography specification is required to realize collaborative business processes as Web services integrations and the description of dynamic interactions and flow of messages among Web services in the context of a process. Such a specification uses WSDL as a basis and extends the WSDL functionality to the Web services choreography space. Although there are several specifications in the industry that address collaborative process modeling two main specifications WSCI (Web Services Choreography Interface) and BPEL4WS (Business Process Execution Language for Web Services) were designed specifically for Web services based choreography. The WSCI specification was developed by a consortium formed by BEA, Intalio, SAP and Sun Microsystems to be used to specify the choreography of the messages on the interfaces of Web services (Arkin et al., 2002). WSCI is an XML-based interface description language defined as an extension to WSDL to describe the order messages that are sent and received, the rules that apply to this ordering, the boundaries of message exchange, transactional boundaries, the behavior to be performed on exception and the degree of concurrency. WSCI describes the flow of messages exchanged by a Web service in a particular process, and also describes the collective message exchange among interacting Web services, providing a global view of a complex process involving multiple Web services. One of the key benefits of WSCI is that it bridges the gap between business process management and Web services by describing how a Web service can be used as part of a larger, more complex business process. WSCI describes the observable behavior of a Web Service. This is expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions.

137

Chapter 5 WSCI addresses Web services based choreography from two primary levels. At the first level, WSCI builds on the WSDL portType capabilities to describe the flow of messages exchanged by a Web service in the context of a process. This, however, is still a one-sided description of the message exchange, purely from the point of view of the Web service's own interface (portType). The construct introduced by WSCI permits the description of the externally observable behavior of a Web service, facilitating the expression of sequential and logical dependencies of exchanges at different operations in the WSDL portType. At the second level WSCI defines the construct, which allows composition of two or more WSCI definitions, of the respective Web services, into a collaborative process involving the participants represented by the Web services. WSCI calls this the Global Model. The Business Process Execution Language for Web Services (BPEL4WS) is a specification from BEA, IBM and Microsoft (BPEL, 2003) for specifying business processes that are assumed to be supported by Web services. Like WSCI, the BPEL4WS specification's process model is also layered on top of the Web service interface model (portType) defined by the WSDL 1.1 specification. However, unlike WSCI, BPEL4WS does not define choreography aspects at the individual Web service level as a separate choreographed interface definition. Accordingly BPEL4WS also does not define a "global model" that builds on the choreographed interfaces at the individual Web service level. Instead BPEL4WS references the respective portType names and the operations in a specific portType directly via their namespace qualified names. At the core of the BPEL4WS process model is the peer-to-peer interaction between Web services interfaces defined in WSDL. All parties involved in a process are modeled as WSDL services interfaces. A BPEL4WS process definition provides and/or uses one or more WSDL portTypes. The interfaces that the process provides are used by its partners and the interfaces used by the process are provided by its partners. Unlike WSCI which defines all choreography aspects within the context of individual Web services only, and simply connects the interfaces at the global model (process) level, BPEL4WS defines the choreography aspects, e.g. flow of control, at the process level that involves two or more Web service interfaces. This process level choreography defines which parts of the process are executed in parallel, which are executed in sequence, conditional flow of control at different parts in the process, exceptions and compensations etc. This executable business process model of BPEL4WS does not distinguish between "public" or externally visible aspects of a process and its internal workings. Protocols such as business-to-business protocols, however, do not address internal workings, i.e. private aspects of the process at each end of the interacting parties, but model the interactions of the process in terms of mutually visible message exchanges and behavior of each involved party at the message interaction level. BPEL4WS refers to this type of process modeling involving public behavior only, as the "abstract" process. This is analogous to the "global models" of WSCI though in BPEL4WS this is viewed at the abstraction level of a 138

Component Modeling Techniques and Notations process that potentially encompasses more than one Web service interface, where as the WSCI global models are at the individual Web services level. Further details about Web services choreography languages are out of the scope of this thesis. We summarize the mapping between the elements of a component contract specification we introduced in chapter four and the Web services constructs that can be used to represent them in Table 5.3. Table 5.3 Mapping of the component specification elements to Web services specification constructs. Component concepts Web services constructs Purpose, scope, policies WSDL element Non-functional parameters WSDL element Service component ports and interfaces WSDL Provided and required operations WSDL operations Events – published and consumed WSDL operations Operation parameters WSDL definitions Constraints on operations (pre-conditions Design-by-contract embedded into the WSDL and post-conditions) document Coordination of operations WSDL enriched with WSCI or BPEL Configuration parameters Modified WSDL definitions Information types WSDL element Information type instances lifecycle WSDL definitions Constraints on information instances Design-by-contract embedded into WSDL Service implementation WSDL element Service executable WSDL element Service composition and choreography WSCI or BPEL4WS Component granularity types Web services are supposed to be at the level of business components It can be concluded that WSDL provides expression mechanisms for representing most of our component concepts. For the purpose of expressing coordination constraints and service collaborations, the constructs from WSCI or BPEL specifications need to be used. WSDL has to certainly be extended with XML-based OCL-like constructs to express design-by-contract constraints on Web service operations, such as preconditions, post-conditions and guarantees. Further, mechanisms and techniques are needed for expressing some context-related concepts of a Web service usage, such as its purpose, scope, polices, configuration parameters and nonfunctional parameters. New Web services specifications and standards are emerging rapidly and, at the moment of writing this, there are probably initiatives underway covering these aspects of services. One important new initiative that tries to provide the specification of all elements of the Web service semantics is certainly the Semantic Web Services of the DARPA Agent Markup Language (DAML) program (DAML, 2004).

139

Chapter 5

5.4 Summary In this chapter we presented different types of modeling and specification techniques and notations to represent the component concepts introduced in chapter four. Due to its wide acceptance, rich capabilities and a standardized specification, UML is the natural choice for any modeling activities. Therefore, we devoted the main part of this chapter to modeling components using UML. Until recently, using UML versions 1.x, a modeler needed to use the UML extension mechanisms, stereotypes, constraints and tagged values extensively, which are applied on the available diagrams to represent components and related concepts properly. Now, with the new version of UML 2.0 in its final standardization phase, improved modeling mechanisms for representing component concepts throughout the lifecycle are offered, including both logical components and physical software components. Further directions of UML improvements are related to notations and mechanisms for modeling business processes, data models for a permanent storage and user interface screens and forms. In the first part of this chapter we combined several UML 2.0 modeling capabilities, diagrams and notations, and extend them using OCL and stereotypes when it was necessary, to represent our component concepts. All the diagrams that serve to represent different aspects of a single component, including context, behavior, information and implementation, can be packaged into a component package and used as a complete specification of that component from a black-box perspective. The internal perspective of a component in terms of its decomposition into sub-components using ports and delegate connectors can also be presented. Parallel to focusing on a single component, the ways to represent component collaboration and composition using ports, connectors, sequence diagrams and communication diagrams were given. When a more agile development process is followed, and when it is crucial to produce a fast prototype and software code that maps, as close as possible, rapidly changing user requirements, the modeling activities are less important and emphasized than in traditional projects. However, coding without first designing can potentially lead to badly structured implementation and so-called ‘spaghetti’ software code. Therefore, for the purpose of lightweight design in such projects, we propose a Component-Responsibility-Coordinator (CoRC) card, as a component-based variant of a well-known Class-ResponsibilityCollaborator (CRC) card. CoRC cards can be used to provide an overall system architecture blueprint and common understanding of the problem before coding. We also explored the use of textual notation to represent our component concepts in this chapter. As the basis for this, we used the OMG Interface Definition Language (IDL) as a human-understandable textual notation and extended it to serve to our purposes. We also proposed the Web Services Description Language (WSDL) together with other Web services specification (WSCI and BPEL4WS), as a basis for a machine-readable textual notation. IDL is a general-purpose high-level implementation-independent interface description language 140

Component Modeling Techniques and Notations that is easy to create, read and understand for humans. Along with other OMG specifications, IDL forms a solid foundation for developing and deploying a wide range of distributed systems, using e.g. component middleware technology. WSDL is a lower level interface description language, which is more difficult to create and understand for humans. Web services clients can get all of the information required to find and access a service across the Internet in a single WSDL document. IDL and WSDL can be used to express standard syntactical component interfaces, and more complex interfaces using interface inheritance, modules and complex types including arrays, sequences and structures. If we need to define mappings between them, then an IDL method corresponds to a WSDL operation, IDL interface corresponds to a WSDL portType, IDL properties correspond to WSDL types, and a CORBA component defined in IDL corresponds to a WSDL service. These modeling and specification notations are used in different phases of the development lifecycle, by the different roles involved in it, i.e. business analyst, software architect, developer, or even computing resource, and for different purposes, i.e. understanding, people communication, distributed software development, or machine-to-machine communication. Therefore, it is important to provide ways of mapping between different specifications including the software code, as the most detailed representation of a software system. Mapping from UML models to software code has already been provided and widely practiced, supported by the use of various Model-Driven Architecture (MDA), CASE, or round-trip engineering tools. Moreover, mapping between UML and IDL has been proposed (OMGCORBA, 1999). In the classic Remote Procedure Call (RPC) model, used for inter-application communication in CORBA, once an interface is defined in IDL, developers can write client and server code independently, by mapping the IDL specification of component interfaces to programming language statements. OMG defines several standard mappings of IDL to programming languages, such as C++, Java and Smalltalk (OMG-CORBA, 1999). Once an interface is defined in CORBA IDL, a service client can be developed simultaneously with the implementation of the servers. The mappings from IDL to Java code, and from Java code to IDL, have been defined in the J2EE standard specification (Roman, 2002). Finally, in the case of Web services, it is very difficult to use WSDL as a starting point for developing Web services. Consequently, modern Web services tools do not expect developers to write WSDL definitions. They generate WSDL definitions from existing server-side source code, for example, Java classes, based on whatever custom language mapping is appropriate. The WSDL document represents a contract between the service provider and consumer of the service. Therefore, the contract must define clearly and precisely what the service offers. This is difficult to obtain by simply generating a service description from software code. Therefore, advanced tools and techniques are emerging to provide mechanisms for creating WSDL based on UML diagrams (Oldevik, 2004), or on user-friendly dialog forms, such as Cape Studio (http://www.capeclear.com). The UML profiles for Web services and service orchestration and corresponding tool support are undergoing rapid development, such as the UML profile for BPEL4WS proposed by IBM (Gardner, 2003). Using these mechanisms it is possible to 141

Chapter 5 define business processes using UML, to transform the UML models into BPEL4WS using the proposed UML profile and to deploy the BPEL4WS specification onto the Java environment using the IBM’s BPEL runtime engine for Java, called BPWS4J (http://www.ibm.com).

142

6

Component-Oriented Implementation

Architecture

Design

and

A process for component-oriented architecture design and implementation, as the way of working of our method, will be introduced in this chapter. The process consists of systematic procedures, guidelines and techniques used to produce software systems based on business requirements. The process will be based on the component concepts defined in chapter four of the thesis and supported by the design notation, mainly derived from UML, described in chapter five. The focus of the process is on components throughout the development lifecycle. Components of a system are identified based on business process and requirements, modeled and specified precisely during the analysis and design phases, and successively refined into software components that can be used in the implementation and deployment phases. Typical software development method consists of the following phases: business process, requirements, analysis, design, implementation, test and maintenance. This is more or less the classical waterfall process model that is still in use today, with certain additions, such as proceeding with small increments and constant iterations. The scope of our method is as follows. Our method partially supports the business process and user requirements analysis phase. We do not focus on user requirement capturing or gathering, but rather on the organization of these requirements. Our method fully supports the analysis and design phases. Our method partially supports the implementation phase in terms of the ways of mapping design and architectural elements into implementation artifacts and the ways that they can be deployed and used in run-time. Test and maintenance of a final product is also partially defined here. At the end of the chapter, we will define, to some extent, the way of controlling of the method in terms of the roles of the people involved, maintaining the intermediate results, outputs and managing the resources of the project, etc.

6.1 Method Requirements Since a method can be defined as a set of guidelines, rules, and practices used in system development projects, after using or investigating several methods it becomes obvious that some of methods have more rules, concepts, and mechanisms than others. These elements of a method can be derived from theoretical considerations, but can be also discovered through practical experiences and formalized over time to give a method. Simply adding more rules and procedures, however, does not necessarily result in a better method. Methods that are 143

Chapter 6 “lightweight”, but highly effective, are often the easiest to apply in practice, they impose relatively few burdens on the development process and are therefore more likely to be used in practical cases. Our method had to satisfy the general method requirements defined in section 2.8.1 of the thesis, namely to be simple, systematic, flexible and practical to use. The component concepts and modeling notations, proposed in the previous chapters, which constitute the way of thinking and the way of modeling of the method, are well aligned to these requirements. In proposing the main elements of the component paradigm, we offered a minimal set of necessary concepts that can be used to define and specify different aspects of components, from business context to technology concerns. The concepts are well defined in a simple and easily understood way and can be easily applied in practical cases, as will be shown later in the thesis. Component modeling that we proposed in the previous chapter is based on standard graphical, textual and XML-based notations, which makes it simple to use by people who are already familiar with these notations. We intentionally did not introduce another modeling notation to represent component concepts because this would result in difficulties regarding the adoption and effective application of such a new notation. We therefore choose to use widely used industry-standard modeling notations, i.e. UML, IDL and XML/WSDL, as a basis for our notation and propose the ways in which these notations can be extended and adapted to serve our purposes. The way of modeling of the method is flexible in the sense the modeler can choose a modeling notation that best fits his/her purposes, graphical, human-understandable textual, or machine-readable notation. Finally, the component modeling notations based on these industry standards and supported by a variety of tools can be effectively and easily applied in practical cases and projects, and successively mapped to software code in the runtime. The requirements for simplicity, systematic nature, flexibility and practicality had to be fulfilled by the way of working of the method, as will be shown in this chapter. Simplicity is achieved by not defining too many process rules and procedures when designing and developing systems that can cause the method to become complex and difficult to use, i.e. “heavyweight”. The method is systematic if it prescribes a set of steps to follow in building a final software product that satisfies given business requirements, or if defines a process framework that specifies various possible pathways to follow depending on particular project needs. A strictly prescriptive method comes into conflict with the need for method flexibility. Therefore, a proper balance between the level of prescriptiveness/descriptiveness of the method and its flexibility needs to be found. Flexibility of the method needs to be achieved in terms of its adaptation to the application in development projects of different scales and size, with different time limitations and numbers of members involved. Finally, the method needs to be practical, applicable and feasible so that it can be easily applied in practical cases. The

144

Component-Oriented Architecture Design and Implementation practicality of the method will be demonstrated using a case study presented in the chapter seven of this thesis. Beside these general method requirements, our component-oriented method needs to fulfill the requirements related to its component focus and nature, defined in sub-section 2.8.2 of the thesis. We will summarize them briefly here. The method needs to cover the whole component lifecycle, from component identification to component implementation and deployment. Each phase of the method is focused on the component concept, i.e. on various aspects of it. Components are identified to satisfy business goals and needs in a top-down fashion, and subsequently refined into implementation-level artifacts. At the same time, the existence of legacy assets, Commercial-Off-The-Shelf (COTS) components from third parties and Web services from a Web service provider, that are planned to be used in a project, need to be taken into account by the method in a bottom-up fashion. The method is technology-independent, which means that the component based-architecture and design can be mapped to any technology platform of choice, similar to principles of Model-Driven Architecture (MDA) (Frankel, 2003). Transformations between the models at different levels of abstractions and mappings of the models to software code need to be defined, and supported effectively by the advanced software tools that are currently emerging on the market. The method needs to be iterative and incremental, which means it uses constant iterations between the phases of the project and corresponding artifacts, small increments in progressing with the project and fast prototyping. The whole development process, led by the method, is iterative so that additions and changes can be incorporated into any of the stages as they are discovered. These characteristics ensure, among other benefits, that the final software product architecture matches, as close by as possible, frequently changing business needs.

6.2 Related Work The component-oriented development method proposed in this thesis was built using a combination of the strengths and mechanisms for resolving the weaknesses of object-oriented and component-based methods proposed so far and partially presented in chapter two. Some other contributions had a great influence for our work. Since the development of an IT system is a complex task, ranging from the elicitation of business requirements, through the actual software design and development phases and finally to the deployment and maintenance of executing systems, effective techniques and strategies for managing this complexity need to be applied. Each of these activities involves a different set of concerns, people roles and solutions. All of them taken together are aspects of the complete software system solution. In order to address these problems successfully, the method must be based on certain fundamental principles, such as the separation of concerns. This means that each of the different aspects or viewpoints of the problem should be represented by set of models that address its particular concerns. In order to manage complexity and ensure the completeness of the specification of components and component-oriented system architecture, we used the ISO

145

Chapter 6 standard Reference Model of Open Distributed Processing (RM-ODP) as an underlying idea (ODP, 1996; Putman, 2001) for defining our method. RM-ODP defines a framework for specifying architectures for distribution, interoperability and portability of applications based on object-oriented technology. It is widely recognized as offering the most complete and internally consistent specification framework. The RM-ODP specification of a system consists of five different specifications, corresponding to five separate, but related and consistent viewpoints – enterprise, information, computational, engineering and technology, Figure 6.1.

♦

♦

♦

146

Figure 6.1 RM-ODP Viewpoints The Enterprise Viewpoint specification of the system defines purpose, scope and policies of the system in the context of the enterprise it belongs to. The enterprise specification of the system is a model of that system and the environment with which the service interacts. The specification defines the set of business rules, constraints and policies applied to the system that automates the part of business processes of the enterprise. The Information Viewpoint specification of the system defines types, constraints, and semantics of information handled by the system and the possible ways of information processing. The information specification of the system is a model and dynamics of the information that the system holds, uses or remembers. The Computational Viewpoint specification of the system specifies the components and services inside the system and how they collaborate to produce a cohesive set of functionality provided by the system. A computational specification of a component is a model of the component interface seen from a client perspective, and the potential set of

Component-Oriented Architecture Design and Implementation

♦ ♦

other components that this component requires. The computational component model defines types of interfaces, bindings of interfaces and legal actions for components. The Engineering Viewpoint specification of the system specifies in detail how the components and services of the system are deployed on the network tiers when distribution aspects are taken into account, as well as how the distribution is organized. The Technology Viewpoint specification of the system defines particular technology aspects, requirements and constraints of the future implementation of the system.

The benefits of using the RM-ODP framework to create a system specification are manifold. Successful development of the system in the context of an enterprise requires that the functionality of the system directly reflects the business processes it supports. A model and specification of the system created using the ODP viewpoints specification provides a clear connection between the business processes and concepts, as the basis for the requirements on the system and for effective system implementation. In this way, the RM-ODP integrated specification covers all aspects of the system development through powerful separation of consistently linked concerns. Separation of concerns using the ODP viewpoints, together with their specified interrelationships and mutual consistency is the powerful way to manage complexity in a system. Therefore, a development approach that uses the RM-ODP viewpoints as a basis framework can provide traceability and consistency between the purpose and scope of the system in the context of the business, and system implementation and deployment. Another very popular initiative in the last few years, that uses models and specifications as a basis for developing complex systems is the Model-Driven Architecture, presented in subsection 2.6.1 of this thesis (OMG-MDA, 2004; Frankel, 2003). Technology and implementation standards are constantly changing and evolving, MDA focuses on models at different levels of abstractions to separate domain knowledge from the particular implementation settings. Using model transformation and code generation mechanisms and tools, MDA enables architectural models and specifications to be maintained effectively and mapped easily to the technology of choice. The main levels of concern in MDA, shown in Figure 6.2, are as follows. ♦ Computation-independent business model (CIBM) – represents the business aspects of the problem domain independently of any automated support. ♦ Platform-independent model (PIM) – represents the system being developed independently of particular implementation platform. ♦ Platform-specific model (PSM) – represents the system being developed using the mechanisms, patterns and elements of the specific implementation platform. ♦ Software code or implementation specific model (ISM) – represents the implementation of the system using a specific programming language and tools.

147

Chapter 6

Figure 6.2 Models in MDA Particular techniques can be applied to create each of the MDA models, or levels of concern. These techniques should enable capturing the essential aspects of these concerns and provide the points of consistency and integration between the concerns as a basis for performing transformations between associated models. Advanced tools, that are currently available or will be available soon in the market, can be used to enable automated model transformations and the generation of a great percentage of the software code, which can speed-up the software development process and shorten the time to market significantly (Middleware Research, 2003). MDA can seem like reinventing the wheel since it reminds us of the traditional waterfall method defining a step-by-step approach of requirements, analysis, design and implementation. Similar to this is the well-established theory of object-oriented methodologies, such as Syntropy, that defines the three different semantic levels of modeling (Cook and Daniels, 1994; Fowler and Scott, 1999). ♦ Conceptual models describe the problem domain without considering whether or what part of the model will be implemented or supported by software. ♦ Specification models define what information and behavior a software system and its parts must hold and exhibit respectively to satisfy domain goals, without specifying implementation details. ♦ Implementation models describe how the software system is implemented taking into account the mechanisms and constraints of a particular computing platform. The main characteristic of MDA that differs it from the previous initiatives are the incremental and iterative process of creating the models at different levels of abstractions while providing

148

Component-Oriented Architecture Design and Implementation mechanisms and techniques for possibly automated transformations between the models and the generation of software code based on the models. The mapping between these different ways of using the separation-of-concerns principles in system specification and development can be easily defined. For example, taking the RMODP viewpoints and a more traditional development approach into account the following correspondence between the two can be drawn (Putman, 2001). The ODP enterprise and information viewpoint specification can be used to provide basic requirements of the system and business context of the system. The ODP information, computational and engineering viewpoints taken together can be used to form the basic architecture specification. The ODP computational and engineering viewpoints can be used to form the detailed specification of the software architecture of the system, from the concept of components and composition, to that of architecture styles of interaction. Finally, the ODP engineering and technology viewpoints represent a basis for the implementation specification of the system, i.e. the mechanisms, tools and constraints in implementing the system on a particular implementation platform. Iterations among the viewpoints, together with addressing all aspects of a viewpoint in an incremental way, ensure that the system specification is precise and complete, fulfilling business needs and is ready for implementation. Some other similar initiatives and contributions regarding the methodology and architectural frameworks, viewpoint-based system specifications and development approaches based on the separation of concern have been influential for our work. These are the Zachman Framework for enterprise architecture (Zachman, 1987), The Open Group Architecture Framework (TOGAF) – Enterprise edition (TOGAF, 2003), 4+1 View Model of Architecture (Kruchten, 1995) and the UN/CEFACT Unified Modeling Methodology (UMM) (UN-TMG, 2003). A detailed presentation of these contributions is out of scope of the thesis, and the reader is directed to these references to obtain more information.

6.3 An Overview of the Method Our component-oriented method was not built from scratch without considering the existing knowledge in the field. The method is based on CBD-related experience, best practices and achievements, some of which have already been described in the thesis. As in the case of the ways of thinking and modeling of the method, presented in the previous chapters, which were defined based on existing theory and standard modeling notations and enriched with the concepts and the notation elements to satisfy the requirements defined in chapter two, it is the same for the way of working of the method, often called a process model, presented in this chapter. Thus the method is defined, using the strengths of previous approaches for complex system architecture design and development, while solving their weaknesses, shortcomings, and limitations, especially regarding ways to treat and use components and services throughout the development lifecycle with the aim to fulfill the requirements defined in chapter two. 149

Chapter 6 The focus of the method is on creating a precise architecture specification of the system based on given business requirements and the ways to implement it on various implementation platforms. The specification of the pure business domain without considering a software system as an integral part of it and the details of software implementation and coding practice, are out of the main scope of the method. In the vocabulary of MDA, the method is mainly focused on creating PIMs and PSMs, and just partially on defining CIBM, as an entry point for creating PIMs, it also focuses on software coding as a possible output of PSMs. Our method is model-driven in the sense that the main artifacts of different phases of the process are models at different levels of abstraction. The transformation rules for mapping among these models are defined up to the level of software code. A model in the method represents an artifact that represents aspects of a problem under investigation, focused on particular set of concerns and abstracted from unnecessary details. A set of related models forms a complete specification that can be implemented using implementation tools and mechanisms. We define the following architectural models as the main artifacts of the method used during the development lifecycle. ♦ Business Domain Model (BDM) is a model of a business domain without considering possible automation by software. ♦ Business Component Model (BCM) is a model of the system as collaboration of components and services that offer business value. ♦ Application Component Model (ACM) is a model of the system that shows how business components and services are realized by the collaboration of finer-grained application components. ♦ Implementation Component Model (ICM) is a model of the system that shows how business and application components and services can be realized using the components of a particular implementation platform. The main characteristic of these architecture models is that they are focused on components and collaboration among components as the main artifacts, while BDM is only focused to a limited extent on component principles. As already mentioned, we used the elements and principles of RM-ODP as an underlying framework and incorporated the component concepts defined in chapter four as integral parts of that framework. Having that in mind and regarding their scope and goals, we can state that BDM corresponds to some elements of the ODP Enterprise Viewpoint, BCM corresponds mainly to the ODP Enterprise Viewpoint and partially to the ODP Computational Viewpoint, ACM to the ODP Computational Viewpoint and partially to the ODP Enterprise Viewpoint, and ICM to the ODP Technology Viewpoint and partially to the ODP Computational Viewpoint. Distribution concerns, described by the ODP Engineering Viewpoint, as well as information semantics and dynamics, described by the ODP Information Viewpoint, are integrated throughout all four architectural models. Thus, distribution can be considered as business domain distribution, e.g. virtual enterprises, 150

Component-Oriented Architecture Design and Implementation business components distribution, e.g. legacy assets and Web services, application distribution, e.g. logical tiers of n-tier distributed architecture, and as implementation distribution, e.g. the way of distribution support by a particular component middleware. Similar to this, the concerns of the ODP Information Viewpoint are orthogonal to the models and spread over all of them. Thus, information about business concepts can be defined in BDM, information about business entities that will be maintained by the system being developed is defined in BCM, a specification information model specifying how information types and instances will be represented and used by the software system is defined in ACM, and finally, the ways of data organization and storage are considered in ICM. This allows us to incorporate the component way of thinking into each of the RM-ODP viewpoints. All aspects of the system are focused on, and organized fully around, previously defined consistent component concepts, which represents the point of consistency and integration among the components (Stojanović, Dahanyake and Sol, 2001). With regard to MDA, we can say that our Business Domain Model corresponds largely to the MDA’s Computational-Independent Business Model. The Business Component Model and Application Component Model defined can be seen as two levels of abstraction of Platform Independent Models, while the Implementation Component Model corresponds to MDA’s Platform Specific Model. It is clear that our method is compatible with MDA, and that it represents the component-oriented variant of MDA principles, where the component concept is the main artifact of modeling activities at different levels of abstraction and serves as a point of consistency across the models. Provisional relationships between the four proposed models, RM-ODP viewpoints and MDA models are shown in Figure 6.3. It can be concluded that our architectural models are mapped straightforwardly to MDA models, but they are, in many respects, orthogonal to RM-ODP viewpoints. The mapping between MDA models and RM ODP viewpoints is in a similar way defined in (Miller and Mukerji, 2003). Creating the models is not performed in a strictly sequential order, rather by using small increments and constant iterations back and forth as suggested by the best practices in software system development (Jacobson, Booch and Rumbaugh, 1999; Cockburn, 2002). In the case of component-based development, especially with regard to reusability as one of the main characteristics of CBD, there are two types of activities, development for reuse and development with reuse. The first activity, development for reuse, involves the construction of components that can be reused in the future, so reusable components are one of the results of the development process. The second activity, development with reuse, concerns the construction of the system (re)using available components. Our method is defined in a manner that covers both activities, i.e. to design and implement components that can be reused elsewhere and to take into account available components during the system design and implementation.

151

Chapter 6

Figure 6.3 Four component models related to ODP viewpoints and MDA models This topic is closely related to the notion of green-field projects, namely projects that start from scratch. Modern system development projects rarely start as ‘green field’ projects. Creating new solutions almost always involve integrating existing legacy assets, using already available components in the form of Commercial-Off-The-Shelf (COTS) products, or using Web services invoked from a service provider over the Internet. Although the market of reusable components has not to date been developed its possible full extent, there are certain component marketplaces where various COTS components can be bought, such as Component Source (http://www.componentsource.com). Similar to this, the market for Web services is growing steadily, with a number of XML-based Web services that can be invoked and used inhouse for building applications such as http//www.xmethods.com Our method is built as a combination of a top-down and bottom-up approach. While identification and definition of business components and business component architecture are performed primarily in a top-down fashion, to reflect as close as possible business goals and needs, the existence of legacy assets or the intention to use COTS components or Web services must be taken into account even during early phases of the development lifecycle, not only at the implementation and deployment level. This strategy provides a balanced approach between business requirements and strategies for their capturing into the system architecture 152

Component-Oriented Architecture Design and Implementation on one side, and the software packages and services that need to be used on the other side. A component-based approach dictated by the method provides for encapsulation of legacy packages and their seamless integration with eventual COTS components, Web services and components built in-house to give a flexible component-oriented system architecture. This architecture is thus designed to enable that some of these components, including encapsulated legacy, COTS, etc., can be replaced easily in the future with new, more advanced versions of the same or similar functionality, without the need to change the complete system construction. The main goal behind our method is managing the complexity and flexibility of software systems in a more effective way. A software system that supports a business problem is nothing more than a complex and interleaved bunch of software code. The solution for managing complexity and flexibility lies in breaking up this monolithic assemblage of code into manageable chunks of functionality that are aligned with the principles of encapsulation, information hiding, low coupling and high cohesion. Similar attempts have been proposed in the past that suggested using procedures, units, packages and finally objects and classes, where these chunks (objects or classes) represent real world entities and therefore would be understood by business and IT people. However, the software solutions have become more complex and less understandable from the business perspective, although this has become increasingly important and has raised the issue of the size and the level of abstraction of these chunks. An object is too fine grained to address effectively the problem of creating manageable chunks in complex systems. When, for the purpose of creating domain models, hundreds of classes need to be created, the software solution is too complex to be dealt with at the level of classes. Similarly, the focus of a development process needs to be comparable to the unit of reusability, and these become coarser-grained components rather than fine-grained objects. Finally, objects suggest a more static, structural picture of the problem domain and its solution that does not closely correspond to the perspective of a business analyst who considers the problem/solution as a dynamic collaboration among process and services. Therefore, our method suggests using higher-level, coarser-grained, business-driven and service-based functional units, called components, to create a software solution that supports given business processes and goals. In this way, complex enterprise-scale system can be decomposed into these architectural components according to cohesive sets of the business services they provide. These components can then be further decomposed into finer-grained components up to the level where their implementation is simple and straightforward. This component-based view on the system at different levels provides the following: ♦ the whole system can be analyzed and understood at a high level, by both business users and software architects; ♦ components abstract and hide unnecessary details and thus simplify the system; ♦ the interior details of components need to be understood only by developers of those components; 153

Chapter 6 ♦

changes that need to be made in one component a re-localized and do not significantly affect other components by forcing them to change as well, or at least these changes are not propagated throughout the system in an uncontrolled way; they can be easily traced and therefore they can be much better managed.

The method we propose here starts with the componentization strategy as early as possible, at the level of organizing business requirements, and provides successive refining and decomposing first-level business components up to the level of software components that can be implemented and deployed using component middleware. During the whole process, at each level of component architecture, the eventual usage of legacy assets, COTS components or XML-based Web services needs to be taken into account. In what follows, we will present the process of creating the four component architectural models, BDM, BCM, ACM and ICM that we propose for effective building of software systems to satisfy given business requirements. The creation of the Business Domain Model is somewhat out of scope of this thesis and we thus give it limited space. The main focus will be on creating the Business Component Model and Application Component Model, as the cornerstones of our method and as the means of balancing business processes and requirements with software implementation and deployment. The Implementation Component Model will provide the mechanisms and ways for how the specified multi-level componentbased architecture given by BCM and ACM can be mapped to the implementation platform of choice, such as Microsoft .NET framework or J2EE platform.

6.4 Business Domain Model A business domain model (BDM) represents a model of the business that is, to a large extent, or completely, independent of concerns about the use of automated systems. The model specifies the main elements of the organization’s business, such as business processes and roles. It provides a good understanding of the problem domain and a shared vocabulary across the particular business. Although this model is not concerned with possible, or already performed, automation of certain steps of business processes and particular business roles, it provides a solid foundation for modeling the as-is business situation and looking for possible improvements using e.g. IT systems in to-be business. The concerns of BDM are similar to the ones of MDA’s Computation-Independent Business Model (CIBM). Once the model is created, initial automation options can be examined. There are three possibilities, full automation, partial automation or manual execution. Most processes today have some degree of automation present. Although the goal is to increase the level of automation of business processes, so called process digitization, it is not possible, feasible or desirable to automate or digitize all the processes (Eriksson and Penker, 2000). The main elements of BDM model the static and dynamic aspects of the business domain, such as business goals that need to be met, business processes that need to be performed to

154

Component-Oriented Architecture Design and Implementation achieve the goals, business entities that can be active, i.e. performing the processes, or passive, i.e. used by the processes as resources, business events that can trigger activities and processes once they have occurred and business rules that pose the constraints and conditions on all these elements. The elements of BDM can be modeled using a graphical modeling notation, such as a notation based on extending UML (Erikkson and Penker, 2000), a notation based on Petri nets (Aalst van der, 2003), the Business Process Modeling Notation (BPMN) defined by Business Process Management Initiative (BPMI) (BPMI, 2004), the new version of UML 2.0 (OMG-UML2, 2004), as well as more common notation such as swimlane diagrams (Eriksson and Penker, 2000). The main elements of the business-modeling notation based on UML 2.0 are activity diagrams, business use cases, and business actor and entity classes. An improved version of an activity diagram in version 2.0 provides the notation to model the flow of control and data along the business process using sequencing, alternations, loops, parallel performance, etc., similar to the modeling mechanisms in BPMN and Petri nets. A business use case is a description of a goal of the business process from the perspective of the business actor. A business actor is an external entity that provides value to or derives value from a business process. Business use cases extend the concept of standard UML system use cases. A business use-case realization describes how a particular business use case is realized within the business model, in terms of collaborating business entities, either passive or active. An active business entity represents a set of responsibilities to perform some steps of business processes. A passive business entity represents something created, managed, or used by business processes. Business entities can be represented using class diagrams. Using the business model elements described above, the complete representation of the business domain can be made as the basis for a common understanding of the business inside the organizations, and for possible business process improvements and automation. The method proposed in this research does not focus particularly on creating a business domain model. It rather uses already constructed business models together with the consideration of what parts of business processes need to be automated as an entry point for building an application that supports given business processes. This knowledge of the business environment of the IT system being built is important for identifying the requirements on the system and for understanding how well the system might be accepted. The main result of creating a BDM is precise information about the business domain of an organization, and a specification of what part of that domain will be automated by the system. This specification serves as input for performing the requirements analysis phase of the system development, which will be covered in the next section devoted to the business component model. At this point, it is interesting to note that our component way of thinking presented in this thesis can also be effectively applied at the level of business modeling. The component main concepts and principles, such as the component content hidden by the exposed contract to the context, component composition and decomposition and the specification of a component 155

Chapter 6 through the context, behavior, information and realization viewpoints, can be equally applicable in creating business building blocks that consist of minimally coupled and highly cohesive business process and entities. The role and benefits of these business building blocks in business process management are the same as for components in software systems engineering, namely better management of complexity and changes among others. These building blocks allow the whole enterprise to be effectively managed using business units, and to be configured and reconfigured as changes in the environment dictate. This ability to adapt easily to new circumstances increases an organization’s agility and market survivability under the constant pressure of changes. At the same time, the structure of the business is simplified as it is organized around the standalone core business building blocks of an organization, therefore providing for better manageability in the future. Certain initiatives that use the component thinking in the business process management domain have already been proposed. Veryard in (2001) proposes plug-and-play principles of organizing and configuring the company’s business to achieve the benefits of the component paradigm in the business process domain. The Supply Chain Operations Reference-model (SCOR) has been developed and endorsed by the Supply-Chain Council (SCC) as the crossindustry standard for supply-chain management (SCOR, 2003). SCOR is a process reference model that provides a language for communicating among supply-chain partners. Among other important elements of this reference model, of interest to us is the SCOR’s definition of the main building blocks of supply-chain processes. SCOR defines five distinct management processes in a supply-chain, namely plan, source, make, deliver and return. Each process in SCOR can be decomposed into process elements, and further into tasks and activities. Using these horizontal and vertical hierarchical views, the supply-chain building blocks can be (re)configured together in various combinations to form complete supply-chain processes that cover customer interactions, product transactions and market interactions, to fit different purposes and a changing business environment. IBM has recently introduced the notion of component business modeling (CBM) in relation to its previous initiative of business on-demand (IBM, 2004). An on-demand business is defined by IBM as an enterprise whose business processes can respond with flexibility and speed to virtually any customer demand, market opportunity or external threat. Component business modeling simplifies the way an enterprise looks at its operations by considering tightly linked business activities as autonomously managed components that comprise the overall business. It makes it easier to determine where the value comes from and where it does not. Modeling a business as a network of components can lead to improvements in three critical areas: efficiency, strategic planning and flexibility. It is worth noting that components in CBM have the same essential specification properties of a component we identified in this thesis, which suggests that our component theory might be applicable in modeling and designing component-based businesses.

156

Component-Oriented Architecture Design and Implementation

6.5 Business Component Model The main goal of the BCM is to specify the behavior of the system in the context of the business for which it is implemented in terms of the collaboration of cohesive chunks of business functionality, called business components. The starting point for creating the Business Component Model is to consider the previously created Business Domain Model against the boundaries of the system being built, i.e. to consider what part of the business problem domain should be automated by the system. This is an activity performed within the standard requirements analysis process for a software system built to satisfy given business goals. 6.5.1 Business Requirements Analysis Requirements on the system are generally of the following two types: functional and nonfunctional. One of the main techniques for defining business requirements for a system is to define system use cases. This is applied in our method. Use case analysis is an effective mechanism for defining cohesive sets of features and services on the system boundary since they capture the intended behavior of the system without having to specify how that behavior is implemented (Jacobson, Christerson, Jonsson, and Overgaard, 1992). We use here the goaloriented approach to use cases as defined by Cockburn (2001), by which a use case is described as a goal-oriented sequence of business or work steps. Both the goals and the interactions in a use case scenario can be unfolded into finer- and finer-grained goals and interactions. Three types of use cases at the three named goal levels are defined: summary goals, user goals and sub-function goals. We focus here on user-goal use cases since they correspond to Elementary Business Processes (EBPs). An EBP is a task performed by one person in one place at one time, which adds measurable business value and leaves the data in a consistent state (Larman, 2001). Besides being used to specify the requirements on the system, use cases can be used for the specification of functional features offered by the system as a response to user’s activities. Change cases as potential changing requirements on the system in the future can be included to provide higher adaptability of the system solution in the future (Cockburn, 2001). The activity diagram, defined in the Business Domain Model and enriched with the boundaries of the IT system being built to show the flow of business processes and activities that the system should support, assists in identifying and defining use cases. Since use cases are normally not performed in a provisional order, i.e. they are parts of the higher-level business processes, the activity diagram helps us to determine these coordination aspects among use cases. The diagram provides information about the use case that precedes, follows or is done in parallel to the given one, as well as information on how well the use cases’ preconditions and post-conditions match. For example, the use case Find a Product precedes the use case Send an Order, which precedes the use case Pay a Bill, and the post-conditions of the

157

Chapter 6 preceded use case need to match the pre-conditions of the followed one to form a correct business process flow, Figure 6.4.

Find a Product

Send an Order

Pay a Bill

Figure 6.4 Relation between the use cases Having created the activity models, the static domain information model needs to be created. This model represents a high-level domain vocabulary of the system being developed. It specifies the information about business domain entities that should be managed and possibly stored by the system, the attributes of interest of these entities and the associations among entities that should be handled by the system. The domain information model is represented using a class diagram at the conceptual level, which means without detailed attribute types and associated operations or methods. Non-functional requirements on the system can be specified in this phase. They specify the quality characteristics that are expected from the system being built, such as usability, performance, security, reliability, availability and flexibility. These non-functional requirements can be related to particular use cases and therefore become a part of the use-case description, or they can be related to the system as a whole and be applied across several use cases. Next, business rules and policies that should be supported by the system can be specified as a part of requirements analysis. Business rules can take different forms. A business rule can refer to a sequence of events and operations the system must provide, that are expressed as steps in a use case description. A business rule can also refer to some constraints on business entities managed by the system, e.g. the bank account state cannot be below zero. Finally, business rules can refer to non-functional attributes the system must satisfy, e.g. the system must be available 24 hours a day. Clear and detailed specification of business rules ensures that the system satisfies, as closely as possible, given business needs. Beside these requirement specifications, some other elements, that are important to be defined before the system development starts, can also be a part of the requirements analysis. These are, for example, the existence of legacy systems, COTS components, or Web services planned to be used in building the system, the need for outsourcing a part of the system development to the third party, geographical separation of teams that can dictate a way the system will be developed, technology constraints in terms of infrastructure and available means and certain business context constraints, such as time limits.

158

Component-Oriented Architecture Design and Implementation All these requirements specification elements need to be taken into account when identifying and specifying business components and business component architecture as the main artifacts of the Business Component Model. 6.5.2 Identifying Business Components The key challenges that software system development faces today are changes and complexity. It is often said that the only constant thing in software development is the fact that requirements change constantly. Complexity can also arise from different sources, such as the size of the problem being solved, applying new technologies, a broader system scope, the number of people involved and distribution of teams and system parts. Therefore, we need mechanisms built into the system solution that can ensure effective management of complexity and flexibility and adoption of changes, this is often called agility. The first step towards this aim is to specify the architecture of the system in terms of its high-level business components, which can solve the problems of complexity and changes according to the characteristics of component principles already given in this thesis. In this way, a business component architecture is a conceptual view of the system solution, based on the concepts that are meaningful to the business analysts, system architects and software developers. This architecture provides a balance between business requirements and implementation infrastructures by effectively adopting changes from both sides and providing bi-directional traceability between the two. As we will see later in this chapter, the business requirements are translated into the business component architecture that can be easily implemented and deployed using the component implementation model, and in an opposite way, new technology opportunities improve the way business processes can be automated. 6.5.2.1 Existing Approaches for Identifying Components Therefore, it is essential to design the system solution in terms of collaborating components that form the component architecture and that are aligned with the principles of low coupling, high cohesion, clean interfacing and encapsulation. Components should support the pieces of functionality required from the system and be able to fit together to form a meaningful whole. The process of identifying components is a crucial and often challenging task, when creating solution architecture. The way of identifying components given by a development approach is very much related to the way components are defined and treated within the approach. Therefore, different ways for identifying components have been proposed. In the UML version 1.3 components are identified during the implementation and deployment phases as a way of packaging and deploying objects in the form of software code artifacts (Booch, Rumbaugh and Jacobson, 1999). In the Business Component Factory approach, business components are identified as important business concepts that are relatively autonomous in the problem space (Herzum and Sims, 2000). In the UML Components approach components are identified through the core business types (Cheesman and Daniels, 2001). These core types 159

Chapter 6 result in business component interfaces to manage instances of these types. In addition system interfaces are derived from use cases. There is no strict prescription for identifying components in Catalysis (D’Souza and Wills, 1999). The emphasis in Catalysis is on component collaboration in the form of the framework, and components are identified through the type analysis. The KobrA approach does not offer strict rules about how to identify components (Atkinson et al., 2002). The approach rather treats important business domain concepts as components and follows standard OO analysis and design activities. In (Jain, Chalimeda, Ivaturi and Reddy, 2001) a more algorithmic than semantic approach is proposed treating components as containers of classes. It uses a clustering algorithm on the domain model that represents significant domain classes, together with the sets of managerial and technical goals in component system design. Finally, in (Ambler and McGibbon, 2001) components are defined after creating the hierarchy of domain classes by coupling mutually related and cohesive classes together. 6.5.2.2 A Procedure for Identifying Business Components In what follows, we will present our way of identifying business components based on requirements on the system defined previously. One of the purposes of this problem decomposition into business components that represent an architecture blueprint of the solution is to provide a common basis for common understanding and communication among the different stakeholders involved in the project, with different concerns, from business to technology. Decomposing a complex problem into less complex parts represents a useful mechanism for doing this. The initial definition of business components is not fixed in time. It might be refined and adapted as system design and development progress to reflect new circumstances. However, identified business components and business component architecture represent a solid starting point for the further development process, and a common ground for both business and IT people. There is always a tendency to solve a complex problem in a top-down fashion, to break it down into a number of smaller and more manageable problems. However, during this decomposition it is necessary to consider how the solutions for these smaller problems can fit together and be combined in a meaningful whole in a bottom-up manner. Furthermore, software development projects nowadays rarely start from scratch. It is often necessary to take into account existing legacy assets, or the requirements of the project to use third-party software packages, COTS components, or even Web services. We must limit the whole based on what a given existing part is able to provide. Therefore, for identifying and specifying business components and business component architecture we use a combination of a top-down and bottom-up approach in our method, together with constant iterations back and forth. The same strategy is applied during the whole development lifecycle, i.e. when creating application and implementation components and corresponding architectures. 160

Component-Oriented Architecture Design and Implementation The starting points for identifying business components in our method are the elements of requirements analysis given above and summarized below: ♦ use cases of the system at the right level of abstraction; ♦ an activity diagram showing the flow of control and coordination among the use cases; ♦ a domain information model showing domain entities of interest for the system; ♦ a plan to use legacy systems, COTS components or Web services, as already existing software assets that need to be integrated properly into the solution; ♦ non-functional requirements as required qualities of the system; ♦ business rules as expressed constraints and conditions on the elements above. We start the process of component identification with use cases. As already mentioned, a use case should be defined at the right level of abstraction to reflect the real business goals of its actors and to represent significant and independent added-value to a at least one of its actors. The use case should represent the complete set of flows that are associated with a particular added value that the system provides for one or more of its actors. The use cases of interest for use here are at the level of summary goals and user goals, as defined in (Cockburn, 2001). Focusing on the right level of use cases, without their further decomposition into sub-function use cases allows us to avoid the functional decomposition that as often referred as a serious side-effect of detailed use-case modeling to the level of simple functions (Armour and Miller, 2001). Furthermore, the inclusion and extension of use cases can be used, but with certain limitations. An included use case can be defined if it is shared by more than one use case. An extension use case can be used to define adding optional behavior to an existing use case but it should also provide value itself. The principles of low coupling and high cohesion should be applied to defining use cases. Each use case should specify a significant chunk of functionality and show how the system provides value to an actor. A use case should be cohesive, i.e. focused towards fulfilling a single actor’s goal and have little or no coupling with other use cases, i.e. it can provide value independently. Identified use cases actually correspond to the services the system provides to support and realize actor goals expressed by these use cases. Use cases can be specified in detail according to the use case template that includes name, description, involved actors, goal in the context, scope, level, pre-conditions, post-conditions, triggers, main success scenario, extensions, subscenarios and some non-functional parameters, such as priority, frequency, performance, etc. (Cockburn, 2001). This use case specification can be extended with the information about the role of the use case in a wider context of a business processes in which the system participates. Therefore, for each use case, the use case that precedes it, follows it, performs in parallel with it, or is synchronized in any other way with it is defined and included in the use case specification. Furthermore, for each use case, its superordinate and subordinate use cases are defined to provide a hierarchy of use cases, i.e. corresponding business goals (Armour and Miller, 2001). Change cases, as potential changing requirements on the system in the future can be included to provide for adaptability of the system solution in the future. Finally, object 161

Chapter 6 types defined in the domain information model are cross-referenced with the defined use cases to specify, for each use case, the type and structure of information needed for it to perform properly. Looking from the system perspective, this means to define what types of information the services that support and realize the given use case need to use to satisfy the business goal(s) of the actor, properly expressed by the use case. Based on fully defined use cases, we define the set of business services of the system, each one responsible for supporting the realization of a single business-goal use case. Now, a business component is identified and defined as the provider of the services that support the realization of one or several cohesive business-goal use cases, Figure 6.5. For example, the use case Create an Order that refers to the domain objects Order and Customer is supported by the system service OrderCreator that uses as arguments instances of the types Order and Customer, and it is provided by the business component OrderManagement. Business-Goal Use Case

+supports

+provides

Service Operation

Business Component

1..* +cross-references

1..*

+use as parameters

1..*

Domain Object 1..*

Figure 6.5 Relation between the concepts of use cases, domain objects, service operations and business service components Based on the extensive literature survey we performed, experiences and conclusions we gathered through conducting the inductive case study of the airport business suite, and experiences from the published industry case studies, we defined a number of business and technical criteria that help us to decide what use cases are under the responsibility of which Business Component, and in what way to allocate defined use cases into distinct Business Components. ♦ Use cases that handle the same domain information objects by creating, updating or deleting them should be under the responsibility of the same business component. ♦ Use cases that are expected to change in a same way, within a same timeframe and under same circumstances, should be under the responsibility of the same business component. ♦ Use cases already supported by an existing solution (legacy, COTS or web service) used in the project should ‘belong’ to the same BC that models the given solution. ♦ Use cases that belong to physically separate parts of the system cannot ‘belong’ to the same business component, which basically represents a unit of collocated services. ♦ Use cases that belong to the same business transaction or correlated transactions, required or performed together, should be under the responsibility of the same business component.

162

Component-Oriented Architecture Design and Implementation ♦

Use cases that coherently represent a known marketable and attractive unit of business functionality and, therefore, can be successfully exposed as a Web service, should ‘belong’ to the same business component.

In identifying business components, we actually allocate cohesive responsibilities together. As already mentioned earlier, these responsibilities can be of two types: knowing something and doing something (Larman, 2001). Grouping the realization of functionally cohesive use cases inside a single component suggests allocating “doing something” responsibilities to that component. At the same time, grouping the realization of use cases that handle the same information objects in various ways actually means allocating “knowing something” responsibilities to that component. This component, then, will be responsible for the whole lifecycle of these objects, from creation to deletion, and will represent a contact point for providing that information to components that need it. Hence, some identified business components emphasize more “doing something” responsibilities; others fulfill mainly “knowing something” responsibilities, while some components will have both kinds. Use cases that belong to the same business component, therefore, should be cohesive in a sense to manipulate with the same domain objects, or to have cohesive functionality as parts of the same business transaction. We ensure that our business components provide added-value real business services, and not low-level technical operations, such as get and set methods, by limiting the scope of defined use cases that serve for component identification to the business-goal level. Moreover, by allocating use cases into business components based on functionality cohesiveness and on the information objects they handle, we provide a balance between process-based and entity-based decomposition of the system. Important factors in identifying and defining business components are some business and technical constraints, especially the presence of software assets that can be reused, such as legacy packages. This can have a significant influence on the shape and scope of candidate business components, since this technical reality should be taken into account although it might come into confrontation with some elements of the component identification procedure given above. Some non-functional requirements, such as lower development cost and ease of maintenance, can also be considered in the process of component identification. 6.5.2.3 Comparison and Discussion We will now compare our approach for identifying business components with existing component identification approaches and discuss its potential added value. The first group consists of approaches that define and use components rather late in the development process while previously following object-oriented analysis and design. Components in these methods were certainly introduced as afterthoughts on top of existing OO structure. Examples are RUP and classical OO methods as the one presented in (Ambler and McGibbon, 2001). After

163

Chapter 6 creating detailed design of hierarchy of classes, components are identified by coupling mutually related and cohesive classes together, as a basis for packaging and deploying objects of these classes together using software components. However, the heuristics behind grouping classes together based on the strength of their mutual relations is not always clear and straightforward and does not necessarily bring to well-defined and encapsulated components (Cheesman and Daniels, 2000; Atkinson et al., 2002). In (Jain, Chalimeda, Ivaturi and Reddy, 2001) an attempt is made to define clustering algorithm for coupling objects into classes based on managerial and technical issues, but again this can lead to unsatisfactory results. Furthermore, by identifying and using components at the end of the lifecycle, these approaches miss one of the main roles of components in creating a dynamic software architecture that is key to the design, development and evolution of large applications. Another group of methods identify components based mainly on underlying business domain entities, such as Customer and Order. The examples of such methods are UML Components, KobrA, Catalysis and partially Business Component Factory. However, components identified in this way are rather finer-grained and data-oriented, and their interfaces, e.g. IOrder and ICustomer consist mainly of set and get data access methods that manipulate with data related to instances of order and customer entities respectively. Using this approach for component identification results in a number of small components that are tightly linked to their context and, therefore, not well encapsulated, easily maintainable and replaceable. This way of component identification and definition actually degrades components into old-fashioned business objects. Finally, some recent CBD methods propose the ways to identify components based on activities and services these components should provide. Examples of methods and approaches that define the process-oriented view on components are the new version of Select Perspective, the UML profile for EDOC and, only to some extent, Business Component Factory. However, Select Perspective does not present a well defined way to identify process components, the identification of components as other steps in a development process is out of scope of UML for EDOC as already stated, while business process components in BCF are rather fine-grained and do not correspond to the functionality that is perceivable and measurable to the business user, which represents the targeting level of granularity of Web services. Our approach for identifying components is use case-driven and business goal-oriented making business components a bridge between business and system architecture concerns. In this way, we introduce components very early in the lifecycle as a way of organizing business requirements into cohesive units of business functionality that can be mapped to a coherent, well-structured and modular system architecture, and further into component-based implementation and deployment units. Our business components provide traceability from business services to software architecture and back, making the balance between the two and easy adaptation against the changes from both business and technology. Our business 164

Component-Oriented Architecture Design and Implementation components correspond very well to certain concepts from system development theory and practice, which are, although claimed useful, rather rarely used, such as: use case packages that group cohesive use cases to maintain system complexity (Larman, 2001), UML collaborations that are often referred as one of the most useful UML architectural concepts, but in practice also one of the least used and understood (Houston and Norris, 2001) and subsystems as very useful in architecture design but rarely used in OO development processes (Apperly et al., 2003). We can say that our concept of business components puts a new light on these valuable software development structures. Finally, as a kind of justification of our procedure for identifying service-oriented, use case-driven business components we can refer to similar approaches published quite recently in (Endrei et al., 2004), (Zimmerman, Korgdahl and Gee, 2004) and (Teale and Jarvis, 2004). 6.5.3 Specifying Business Components After identifying initial business components, the next step is their specification along the viewpoints given in chapter four, namely context, behavior, information and realization. This specification can be done in greater or less detail, this depends on the nature of the project, resource limitations and project members’ affinities. The context information of a business component is derived from the elements of requirements analysis associated to it. Regarding behavior, a business component provides services to support cohesive set of use cases allocated to it, and requires services that are required by these use cases. The specification of these use cases, including pre-conditions, post-conditions, coordination conditions and configuration parameters, are mapped straightforwardly to the specification of component behavior that includes operations and events. Regarding the information viewpoint specification, domain information type objects used by the services of a business component to support and realize corresponding use cases are considered. These objects represent information about the domain that the component should obtain to expose required behavior; they can be generally considered as parameters of component services. This does not mean that a particular business component owns the objects of associated domain information types locally. The component handles and uses particular information objects to provide its services, and it is able to find and use them, either directly from the permanent storage, or from another business component, when it is necessary. A business component defined in this way still represents a unity of data and behavior as in the case of object-oriented classes/objects, but now in a slightly different manner. In the case of a business component, first its behavior and the services that it provides and requires are defined, and then information objects that should be handled, not necessarily owned, by the component to fulfill its responsibilities are specified. Changing business and/or technical requirements and the presence of the software package to be reused can lead to necessary refinements of boundaries and scope of identified components. This component redefinition is performed through the process called component refactoring, as analogue to so-called code refactoring in a software development process (Cockburn, 165

Chapter 6 2002). Component refactoring tests the boundaries of components against component-based principles of low-coupling, high-cohesion, hidden interior and independency, and suggests a redefinition of the information and responsibilities components manage. Details about the component refactoring process applied in this method will be given later in this chapter. Initial collaboration and coordination of business components to form the business component architecture of the system being developed is represented using Component Collaboration and Sequence diagrams as component-based variants of the corresponding UML diagrams. Information about the interactions of use cases in supporting business processes the system is responsible for can be used to specify the way components supporting these use cases collaborate within the architecture. Dependencies among components can be also derived based on their information needs, for example, one component provides a contact point for the information required by other components. Components are assembled together by mapping between their corresponding provided and required interfaces. Particular distribution aspects of the business components need also to be considered in the case of, for example, architecting systems serving a virtual enterprise, or using distributed legacy assets. Business components, if possible, can be decomposed into finer-grained business components that still provide services that add value to the business, comparable to the level of user-goal use cases as defined in (Cockburn, 2001). The initial set of business components and the created business component architecture represent the main artifact of the Business Component Model, and, at the same time, an input for creating the following Application Component Model. In following our method, business components are not designed based on business entities. Instead, each business component is a holistic unit that manages operations across possibly a set of business entities. Our business components are identified and defined as use-case realizations. In this respect, a business component as defined in this research is comparable to the concept of UML collaboration defined as the realization of a use case. The concept of collaboration in UML is defined as “a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that is bigger than the sum of all its parts” (OMG-UML2, 2004). A collaboration has two aspects: a structural part that specifies the elements of the collaboration and a behavioral part that specifies the dynamics of how those elements interact. Since our business component represents a realization of one or more cohesive use cases, it is well represented by the collaboration concept. Similar to collaboration, a business component does not necessarily own its structural elements, for example information objects, but it “knows” how and where to find them when it needs them. These mechanisms are further considered in the Application Component Model.

6.6 Application Component Model The realization of Business Components identified and specified within the Business Component Model is provided in the Application Component Model. First, the realization of business components in terms of existing software assets is considered. We start by comparing 166

Component-Oriented Architecture Design and Implementation the specification of existing components, i.e. encapsulated legacy packages, COTS components or Web services, with the specification of initial business components given in BCM. We compare all elements of two specifications, namely context parameters, behavior characteristics, information parameters and realization constraints. Even if two specifications do not match exactly, it is possible to make some changes in the business architecture design to accommodate the reuse of existing software component. These changes include, for example, reallocating services among components, modifying or adding information parameters to the specification, combining two business components into one component that will be realized by the existing component or splitting a business component into several components, one or more which will be realized by the existing component. In this way, the existence of software components, that the project team plans to use in the system development, can influence significantly the business architecture of the system in a bottomup fashion. Business components that are not realized by reusing existing components, i.e. that need to be built by the project team in-house, are further decomposed into application components. Therefore, the goal of the ACM is to define how business components are realized in terms of the collaboration of application components that do not provide a business value by themselves, but in collaboration provide given business behavior of a business component. Since our business components are defined at the conceptual level where the logical layers of system architecture, i.e. presentation, logic, data, are not taken into account, the natural choice is to define separate application components within each of these tiers to fulfill the responsibilities of the business component related to that layer. This strategy is similar, albeit at a higher-level of abstraction, to the robustness analysis as defined in the Objectory method (Jacobson et al., 1992), where, based on a given use case, several types of analysis classes, namely boundary, control and entity, that collaborate to realize the use case, are defined. Since our business component represents the realization of one or more use cases, it can be correspondingly decomposed into finer-grained application components that have boundary, control and entity responsibilities correspondingly. Similar to this analysis is the well-known Model-View-Controller (MVC) design pattern that establishes a key foundation of the layering architecture model (McGovern et al., 2003). MVC is a powerful architectural design pattern that specifies a clean separation between presentation, i.e. View, business logic realization, i.e. Model, and mechanisms for preserving the separation and performing the coordination between the two, i.e. Controller. Using this separation of responsibilities according to the logical architecture layers (or tiers) we can decompose a business component into possibly several application components operating within the single layers. Hence, we can define a part of a business component responsible for interaction with the component consumer, a part that captures the logic of the component, and a part that maintains the needs of the component for information objects. The result of performing this analysis is the following possible types of application components.

167

Chapter 6 ♦

♦

♦

Consumer Interface application components provide services necessary for two-way interaction with the consumer of the given business component by transforming consumer’s request into a form that is understandable by the component logic and presenting the component response in the form understandable by the consumer. These application components make the component logic available to different types of consumers. If the consumer of the business component is a human user, then the consumer interface application component is divided into a presentation, or user interface, application component and presentation control application component, that provide a separation and interaction between the presentation and underlying business logic, similar to the role of Controller in the MVC design pattern. Data Access application components provide services for accessing data stored in a permanent storage, obtaining data from other components, or maintaining data objects in other ways. One of the roles of these application components is to protect the business component logic from peculiarities and possible changes of the underlying data storage structure. Depending on characteristics of given data storage, these application components can be enriched with a proper access method, or indexing structure, to speed up data retrieval, as well as with some mechanisms for data mining. Business Logic application components provide services that determine the main responsibilities, knowing something or doing something, of the business component. These components represent the core of the business logic specified by the given business component. Based on the kind of responsibility this application component fulfills, it can be defined as an entity application component or process application component. An entity application component represents a particular business entity defined through its main attributes and operations that access them, e.g. in the form of set and get methods. A process application component encapsulates particular computation logic, control logic or data transformation logic that is not a part of a single business entity and that operates possibly using several business entities. Since a business component represents a realization of one or several cohesive use cases, application components that realize eventual included or extended use cases of those business-level use cases, also belong to the category of process application components.

A summary of the types of application components that can be responsible for internal realization of a business component is given in the hierarchy tree presented in Figure 6.6. As a kind of justification of this approach for decomposing a business component into distinct application components we can refer the reader to a similar technique used by Compuware company in supporting model-driven development of service-oriented software systems using their tool OptimalJ (Compuware, 2004), as well as in (Barn, 2004) and, to some extent, in (Herzum and Sims, 2000).

168

Component-Oriented Architecture Design and Implementation Application Component

Consumer Interface

User Interface

Presentation Control

Business Logic

Entity Component

Process Component

Data Access

Storage Access

Other Data Access

Figure 6.6 Different types of application components Beside these types of application components derived from allocating the responsibilities of a business component to the logical architecture layers, there are other types of application component that can be defined based on important tasks to be fulfilled within a business component to complete its responsibilities properly. One of the necessary elements of each business component is the Coordination Manager application component. The main role of this component is to manage and control how application components within the business component interact to produce a higher-level business goal specified by the contract of the business component. A Coordination Manager component can be realized using the combination of the Mediator and Façade design patterns as defined in Gamma, Helm, Johnson and Vlissides (1995). In this way, the collaboration aspects and flows of controls and activities between application components inside the given business component is encapsulated and managed by this manager component. This mechanism hides the complexity of internal collaboration and coordination of the business component and, at the same time, provides better flexibility of the solutions and replaceability of particular application components. Next to it, the Event Manager application components can be defined as a constitutive part of a business component. Event Manager handles mechanisms for publishing/subscribing events important for the given BC component, and defines their coordination with provided and required services in the terms of trigger/response patterns. This component is responsible for publishing particular events when it is necessary, for listening for the events the business component subscribes for to occur and then providing activities accordingly. Finally, the Rule Manager application component organizes the business rules encapsulated by the given business component and provides references to the mechanisms for their fulfillment, such as invariants on information entities, pre- and post-conditions on services and the ways of coordination and triggering sequences of services and events. This component keeps consistent and in a single place the information about business rules the given business component should align to. At the same time, this component provides references to the mechanisms that apply these rules within the business component. This later responsibility

169

Chapter 6 provides the flexibility of the business component design against a changing business rule by tracing its realization and providing the modification of this realization if the rule changes. The process of component refactoring can be applied at this level by testing whether some application components need to be reallocated to other business components to provide better architectural design in terms of low coupled and highly cohesive business components. The technique of component refactoring proposed in this thesis will be presented in the next section. It is worth noting that in designing application components, the same bottom-up strategy about considering eventual existing software components to be reused can be applied. Using this strategy, the responsibilities of the identified application components can be rearranged to accommodate the inclusion of existing components. If the match between a designed component and existing component is not exact, some design refactoring and reallocating of services are necessary to proceed correctly with the development. The collaboration and coordination of application components that form a business component can be represented using component sequence and collaboration diagrams. The result of the Application Component Model is a complete, fully specified, component-oriented platformindependent model that should be further considered for implementation on a particular technology platform. While the Business Component Model results in a rather conceptual architecture that forms the starting point for further design, and it is likely it will be modified and refined during the design process, the full specified and detailed application architecture produced by this model provides a solid basis for further component realization using a particular component middleware platform. The following Implementation Component Model will show how the components of the Application Component Model map to the implementation elements of the platform of choice.

6.7 Component Refactoring For the purpose of creating the proper component architecture in terms of low coupling and high cohesion of its parts and non-redundant data and behavior, we propose a technique called component refactoring. We define this technique using the analogue to code refactoring that represents a coding practice in which the software code is changed to keep a design as simple as possible, while the semantics of the code is preserved. Code refactoring is widely used in software development as a mechanism for providing clear software design and for avoiding redundancy of software code (Beck, 2000; Cockburn, 2002). The purpose of component refactoring is to reallocate responsibilities among components to provide a better and cleaner component architecture design without the redundancy of data and behavior, and without extensive interaction and dependencies among components, while keeping stable the contractually defined collaborative behavior of the set of components. The componentrefactoring technique can be applied in two cases.

170

Component-Oriented Architecture Design and Implementation The first case to use component refactoring is when identifying business components and creating business component architecture within the scope of the Business Component Model. If some of the conditions related to the initial criteria for identifying components have been changed, we can consider reallocating services that support particular use cases to different business components then initially done. This is the situation when e.g. a new decision about the use of legacy packages, COTS components or Web services is made, or business requirements, i.e. system use cases have been changed. In such cases, the set of rules for identifying components as having cohesive responsibilities, data and behavior, we propose in section 6.5 above must be re-applied to reflect the new changes and requirements. As a result, we might consider reallocating particular services, i.e. use cases, to different business components to reach a clear architecture design that defines highly cohesive and low-coupled parts. By doing this, the behavior of the system as a whole remains the same, while its architectural design is refined to adopt new requirements and remain defined according to the good component principles. The second case to use component refactoring is when we design the internal realization of business components in terms of the collaboration of application components and we need to avoid data and computation redundancy. For example, when the functionality of an application component is used by several business components, a decision about the business component that encapsulates this application component needs to be made to avoid duplication of the component functionality across several business components. Other business components request the services related to the application component from its parent business component. Furthermore, in the case of entity application components or information objects that are used by several business components, a CRUD (Create, Read, Update, Delete) –like analysis needs to be performed. The analysis defines create as the strongest relation, following by update, delete and finally read. Therefore, a business component that creates information objects, or application entity component instances, of a given type is the owner of all the objects of that type and is responsible for their lifecycles, rather then the business component that just reads their attributes. If a business component needs an application component owned by another business component, especially in the case of application entity components, then that business component maintains the reference to the application component in the form of foreign key pointing to it to find and use it when necessary, in a similar manner to the mechanism of referencing between the tables of the database using a foreign key. Similar consideration should be done in the case of application process components shared by several business components. To assist us in the process of component refactoring, we propose a technique called a 9interaction matrix. For the purpose of applying this technique, a component is abstracted by its basic parts – content, contract and context, as we define in chapter four. For applying the technique, the component context is simplified and represented as the set of components from the environment a given component collaborates with. The matrix shows mutual dependencies

171

Chapter 6 between the basic parts of two components, as shown in Figure 6.6. Elements of the 9interaction matrix denote whether there are dependencies between corresponding parts of two components - the matrix element equals to 1, or not - the matrix element equals to 0. Elements can also contain a short textual description of the kind of dependency, if it exists. The 9interaction matrix provides insight into the coupling and cohesion of the components. This insight may be used to refactor the component design; for example if there are a lot of interactions between a pair of components, a solution might be to combine them into a single component. This technique for representing the nature of interactions and dependencies between components is analogous to the method of 9-intersection and the point-set theory used in the area of Geographic Information Systems (GIS). There, a 9-interesection matrix is used to represent a topological relationship between two spatial entities, each represented through its interior, boundary and exterior (Egenhofer and Franzosa, 1991).

A content A contract A context

B content M11 M21 M31

B contract M12 M22 M32

B context M13 M23 M33

Figure 6.6 The representation of 9-interaction matrix for components A and B The meanings of particular elements of the matrix if they are equal to 1 are as follows. M11 – The interiors o two components are dependent on each other. Components A and B are highly cohesive and their coupling into single component can be considered. M12 – Component B uses application components from the component A, for example business data objects or computation logic; component B must maintain the reference, foreign key, to those subcomponents of the component A. M13 – Components that collaborate with component B, i.e. are in the context of B, use application components from component A; this element if equal to 1 can also denote that B is a subcomponent of A. M21 – Component A uses application components from component B, for example business data object or computation logic; component A must maintain the reference, i.e. foreign key, to those subcomponents of the component B. M22 – Component A and B collaborates on their interfaces; that is standard component-based collaboration. M23 – Component A collaborates with the components in the context of B, which means that A and B belong to the same cohesive group of components that probably form a higher-level behavior. M31 – Components that collaborate with the component A, i.e. are in the context of A, use application components from B; this element can also denote that A is a subcomponent of B.

172

Component-Oriented Architecture Design and Implementation M32 – Component B collaborates with the components in the context of A, which means that A and B belong to the same cohesive group of components that probably form a higher-level behavior. M33 – Components A and B share the same context; if at the same time M23=M32=0 this means that A and B do not belong to the same cohesive group of collaborating components. The information about coupling and cohesion between two components can be derived based on the values of the matrix elements for two given components. If two components are highly coupled, merging them into a single component can be a solution. Coupling between two components is higher if the sum of indices of the element that is equal to 1 is lower. Components are well designed and refactoring is not necessary if some or all of the elements M22, M23, M32 and M33 are equal to 1. If there are elements that belong to the first row or column equal to 1, refactoring might be necessary to achieve good component design. Beside single matrix elements, the combination of two or more elements of the matrix can also provide valuable information. For example, if both M21 and M12 are equal to 1, this denotes two-way interactions between the components so that combining the components into a single one is suggested. If both M12 and M13 are equal to 1, then placing component A within component B can be considered. Similarly, if both M21 and M31 are equal to 1, then placing component B within component A can be considered. If both M21 and M22 are equal to 1 at the same time, which means that the contract of A interacts with both the content and contract of B, redesigning of component B need to be considered. Similarly, if both M12 and M22 are equal to 1, it would mean that the contract of component B interacts with both the content and contract of component A, and that redesigning of component A needs to be considered. Opposite to coupling, we can use the 9-interaction matrix for measuring cohesiveness between two components that belong to the same parent-component. If the cohesion between them is low, splitting the parent-component into two components can be considered. In this case, the existence of the matrix elements of the third row or column that are equal 1 suggest reallocating those two components into separate parent-components. This section shows a promising method for refactoring component design according to the component-based principles of low-coupling and high cohesion. However, further work is necessary to create a fully functional technique for component refactoring based on a 9interaction matrix.

6.8 Implementation Component Model The purpose of the Implementation Component Model is to provide a basis for the implementation of a component-based system architecture using an implementation platform of choice. The artifacts created in the Application Component Model, namely complete specification of application components and application component architecture, represent the input required to create the Implementation Component Model. In this model, the foundation 173

Chapter 6 for implementation of design elements created so far is defined according to the chosen technology platform, for example Sun’s J2EE and Enterprise Java Beans (EJB), or Microsoft COM+/.NET (see section 2.3 of the thesis). As in the case of the BCM, first we need to consider whether there are software components available for reuse to realize some of the application components of the ACM. Reusing already available software for the realization of particular components can result in the need for redesigning and refactoring of the application component architecture, as for the case of BCM. The part of the component architecture that needs to be implemented in-house is first transformed to platform specific component models using the modeling profiles for component implementation platforms such as .NET or J2EE. Based on these implementation models a software code in that platform can be generated, either manually or by using advanced tools as code generators. While BCM and ACM represent platform independent component models as defined by Model-Driven Architecture (MDA), the ICM represents a platform specific component model. For presenting the mechanisms of creating the ICM, here we use as an example Java 2 Enterprise Edition (J2EE) as our implementation platform (McGovern et al., 2003). Provisional mapping of different types of application components presented here into corresponding J2EE constructs is shown in Table 6.1. Table 6.1 Mapping logical architecture concepts to implementation constructs Application Components User interface application components Presentation control application components Application process components Application entity components Data access application components Data types

EJB constructs Java Server Pages, HTML pages Servlets Session Beans, Message-Driven Beans Entity Beans Database APIs, JDBC, Data classes Java classes

An Enterprise Java Bean, namely entity bean, session bean, or message-driven bean, is a software construct that consists of other software artifacts packaged together to form a software component. An EJB component exposes its behavior through a well-defined interface. It is constructed of Java language classes. Some of these classes implement the functionality of the component, an implementation bean, some expose the interface, a remote or local bean interface, and others provide some technical functionality to enable components to function properly, a home bean interface. All of these classes are packaged together into a java archive (jar) file.

174

Component-Oriented Architecture Design and Implementation A typical business component is aligned well to the Model-View-Controller (MVC) design pattern, where each element of the pattern is realized by particular application components (McGovern et al., 2003). Shortly, the Model element represents the business component data, the View element renders the contents of a model, and the Controller element defines component behavior. The Model is implemented using entity beans or Java classes, the View is implemented using Java Server Pages (JSPs), while the controller is implemented by session beans that embody business logic and using Java servlets for flow control between the view and the logic. In this way, Java servlets and session beans can be used to implement the component ports. By exposing interfaces these J2EE elements represent an interaction point between the component and its context. At the same time, they hide the interior of the component from the outside perspective, implementing a façade design pattern (Gamma et al., 1995; Alur, Crupi and Malks, 2001). Furthermore, these components coordinate and delegate behavior on the component port to other elements inside the subsystem. The functionality of the business component is realized using entity beans, session beans and plain java objects. These elements interact with the database(s) if necessary to upload data via corresponding data access objects (DAOs) and database application programming interfaces (APIs). An example of a component realized using the J2EE elements is shown in Figure 6.7.

Figure 6.7 A schematic presentation of a business component realized in J2EE If the component persistently stores some data in the database, the J2EE platform offers two possibilities: container-managed persistence (CMP) provided by the EJB container mechanism, or bean-managed persistence (BMP) built-in EJBs and provided by JDBC API (McGovern et al., 2003). In the case when the state of the user session needs to be saved, the possibilities are to use HTTP sessions managed by the Web container, or stateful session EJBs managed by the EJB container. Another kind of EJB, the message-driven bean, is used to support asynchronous communication between software units. A message-driven bean receives a message from another J2EE entity about some action that needs to be performed. The sender of the message is then free to continue its function, while the message-driven bean is responsible for processing the message received. In the J2EE, messaging and message-driven beans require 175

Chapter 6 the use of the Java Message Service (JMS). Message-driven beans enable further decoupling between the parts of an application by introducing asynchronous messaging. Further, a message-driven bean can be used to wrap a legacy application so that it acts as the intermediary to the legacy application. When representing the J2EE elements visually during this detailed design phase, we can use the profiling mechanism of UML to create a corresponding UML profile for J2EE platform constructs. Some attempts at defining the UML profile for Java implementation already exist, such as the Java Specification Request 26 UML Profile for EJB, defined by the Java Community Process (JSR, 2003). This profile defines a number of stereotypes and tagged values that represent J2EE elements to be used in the detailed design and early implementation phases of the system development lifecycle. Created EJB components and other J2EE artifacts are further decomposed and realized using Java classes, which represent standard object-oriented classes. A Java Server Page and a servlet are realized by corresponding Java classes. Each EJB is further realized through several Java classes and interfaces, such as an EJB implementation class, an EJB home interface class, an EJB remote interface class, an EJB local home class and EJB local interface class. An EJB primary key class is created for entity beans. Other classes for implementing particular elements of the EJB framework and applied design patterns also need to be created. In the implementation phase of the lifecycle, the defined classes are implemented either manually or using the code generation capabilities of advanced MDA tools. The following J2EE mechanisms are used for the purpose of packaging and deploying implemented elements of the application (McGovern et al., 2003). EJB components are packaged in archive files that contain the compiled class files for the EJB, required supporting Java classes and an EJB deployment descriptor. All these elements are placed inside a Java Archive File (JAR). A JAR file contains artifacts related to a single EJB or several EJBs grouped together. JSPs, servlets and HTML pages are packaged and archived by Web Archive Files (WARs). Enterprise Archive Files (EARs) contain the complete J2EE-based application. JAR and WAR files can be modeled in UML using the concept of artifact (OMG-UML2, 2004). Finally, since distribution is an essential aspect of an enterprise application, it is necessary to define how different pieces of a J2EE application are distributed across multiple computing resources and processes. The UML deployment diagram can be used for this purpose. Only the elements of the application that exist at runtime are modeled for deployment. The central modeling concept in a deployment diagram is the concept of node that represents a computational resource in the computer network (e.g. processor) (OMG-UML2, 2004). Nodes can have communication paths among them defined. Runtime component instances are mapped onto the nodes to show the runtime deployment. Different types of nodes can exist in the enterprise application deployment using e.g. J2EE. They are called servers, and there are

176

Component-Oriented Architecture Design and Implementation web servers, application servers and database servers. Related to this, there are software entities that provide low-level technical infrastructure functionality to packaged Java artifacts and the execution environment for the J2EE components. They are called containers, they run within the server, and there are EJB containers and Web containers. Java classes and elements that implement EJBs are deployed in an EJB container and placed on the application server. Classes and programming constructs that implement servlets, JSPs, HTML files, etc. are deployed in a Web container and placed on the Web server. Application artifacts responsible for maintaining the connection with the database are deployed on the database server. Elements of component-based system design and implementation using J2EE will be further illustrated in the example given in the next chapter. Further details about software implementation using the J2EE platform can be found in a number of books devoted to this topic, such as (McGovern et al., 2003).

6.9 Model Packages and Tool Support Models created by applying the method are organized into packages. A package is defined in UML 2.0 as a general-purpose mechanism for organizing model elements into groups. The artifacts of each of our four component models are placed in a corresponding package, as shown in Figure 6.8.

Figure 6.8 Model artifacts organized in the model packages in Poseidon for UML (www.gentleware.com) An automated tool can support the organization, presentation, maintenance and storage of models of the packages. The same tool can provide the model transformations between the models and code generation based on the implementation component model of the system. Advanced tools for practicing model-driven development are emerging at a fast pace. The 177

Chapter 6 examples of such tools are Compuware’s OptimalJ (http://www.compuware.com/optimalj/), Objecteering/UML (http://www.objecteering.com) and ArcStyler from Interactive Objects Software GmbH (http://www.io-software.com). All the tools give the possibility to extend the standard UML metamodel, define UML profiles, and specify custom-based model transformations and code generations, using the mechanisms called patterns, templates and cartridges. Therefore, for supporting our method in real application cases, it is not necessary to build a completely new tool. It is much more effective to use an already existing advanced tool and customize it to serve our purposes. A complete tool support for our component-oriented design and development method will be the subject of further research.

6.10 Summary In this chapter, we proposed the way of working of our component-based design and development method providing the guidelines, techniques, activities and rules that need to be followed to build a software system based on business requirements using component-based principles. CBD methods and approaches for enterprise-scale system development proposed so far tend to apply components mainly at the implementation and deployment level, by packaging cohesive objects or other software artifacts into software packages that can be deployed onto the network computational nodes. Furthermore, these approaches tend to consider business and system issues separately leaving a gap between the two. While a business domain is represented through business processes, entities and rules, system analysis and design is often performed in a traditional object-oriented way. On the one hand we have processing activity units, namely business processes, and on the other hand we have static, structural units, namely objects, that represent business entities, while business processes using these entities are spread over the set of objects, represented by the sequence of their operations and, therefore, hidden and difficult to maintain. Furthermore, the analysis and design of a complex software system can potentially result in a number of classes, which can be difficult to organize and manage, especially if the business requirements that have led to those classes are supposed to change. Finally, the question of how to identify and design Web services of a proper granularity, finer-grained than a whole application, but coarser-grained than methods of a class, arises naturally. Therefore, we need to introduce a design concept at the higher level of abstraction than a simple object-oriented class, that should provide a common ground between business and technical issues, to be used for managing solution complexity and changing requirements effectively, and which can represent coarser-grained software units in system development, such as Web services, COTS components and legacy assets. We have proposed the component concept and integrated it seamlessly into all phases of the component lifecycle, from business to deployment for serving these purposes.

178

Component-Oriented Architecture Design and Implementation The component-based design approach presented in this chapter provides a system specification, through business, information, application and technology issues, following component-based principles and practices. The method defines four models that need to be created in the course of system development, namely business domain model (BDM), business component model (BCM), application component model (ACM), and implementation component model (ICM). Maybe the most important of these models is BCM, since it represents a link between business and system issues and therefore provides business/IT alignment. A business component defined as a service-based unit that offers a clear business value, is as independent as possible from its context, has a hidden interior and exposed interfaces, and represents a concept that is equally understood by both business and technology people. Using the business component concept, business analysts can model and organize their business processes, requirements and rules given in BDM in a domain-specific, but still in an implementation-independent way. In contrast, application architects and developer use business components to retain control over how the model is turned into a complete system implementation using lower-level models ACM and ICM. The method starts by identifying the coarsest granularity units first, based on business requirements, namely business components, since they define the core of the logical structure of the system and represent how business processes and entities are mapped into the system architecture. Business components encapsulate business behavior and maintain the access to, and the management of, business-related data. They are further decomposed into finer granularity elements, application components and implementation components. The whole method can be summarized in the following: parts of business processes are automated by the services of the system being developed; these services are organized into business components that provide business value, manage business data and maintain business rules and policies; the business components are decomposed into application components using logical layering and separation of responsibilities according to the logical structure of the component; the application components are realized by implementation components that represent the elements and implementation mechanisms of a particular implementation platform; the implementation components are implemented by writing software code in that platform. Although the sequence of steps is suggested, and the method naturally moves from business to implementation, we need to emphasize again its iterative and incremental nature. The complete system design, ready for implementation, is produced through a number of iterations. Inside each of the four defined models, the possibility of using already existing software components in the form of Web services, legacy assets or COTS components, needs to be taken into consideration, which can result in successive refinements of the initial design. The four models of the method correspond to the models defined in the MDA framework, as BDM is a computational-independent business model, BCM and ACM are two levels of a platform-independent model, while ICM represent a platform-specific model that uses the implementation elements of a particular platform.

179

Chapter 6 The method presented here proposes a way for designing Web services, treating them as one possible way to realize business components organized in a service-oriented architecture. Business components, defined here as process-oriented and use case-driven structures that provide business meaningful and perceivable functionality, represent the right level of abstraction for representing pieces of a system that can be exposed as Web services. The relation between the concepts of a component, or particularly a business component, and a Web service, is well described in section 4.4 of the thesis. The fact that our business components are basically identified to support cohesive use cases and having in mind that a use case represents a system service that fulfills user’s goals and needs, make the business component concept a perfect match for representing and designing business goal-oriented Web services. At the moment of writing (the end of 2004), studies and publications about designing SOA and service-oriented analysis and design, targeting the level of abstraction above Web services technology, have just started to appear. A kind of justification of the ideas and heuristics presented here about using component-based concepts and principles and use cases in modeling and designing SOA and Web services is given by the approaches published in (Endrei et al., 2004), (Teale and Jarvis, 2004), (Barn, 2004), (Zimmerman, Korgdahl and Gee, 2004) and (Quartel, Dijkman, and van Sinderen, 2004). In using the Web services paradigm, it is important to define the optimal granularity of loosely coupled Web services that are exposed or used by the application to minimize expensive remote method calls, reduce network overhead and improve performance. Therefore, the Web services for inter-enterprise communication and integration are best modeled and designed at the level of the business components, which offer clear business and marketable value to consumers. For the purpose of intra-enterprise application integration, Web services can be designed at the level of finer-grained components, such as application components, and naturally realized using the protocols for interoperability, such as SOAP, XML, and WSDL. Our component-based method does not focus particularly on the management process or the way of controlling. We believe that our design and development method can be well combined with some of the well-known and widely used project management methods, such as PRINCE2 (available at http://www.prince2.com). PRINCE2, which stands for PRojects IN Controlled Environments, is a project management method covering the organization, management and control of IT projects. PRINCE2 helps project managers to handle people, resources, products and goals to ensure that project milestones are met at the end. The integration of our design and development method with the PRINCE2 project management method can be a subject of further research. For the purpose of this research, we defined a basic way of controlling of our method in the form of the main artifacts produced in the development process and the main human roles involved in the process. The main artifacts in applying the method are organized into four packages, each one dedicated to a particular model, BDM, BCM, ACM or ICM. The artifacts of the process are actually models of different elements and aspects of the system being developed, starting from business issues and moving toward technology ones. The models should be consistent and organized around 180

Component-Oriented Architecture Design and Implementation the same set of component concepts and principles defined in chapter four. All the models taken together and integrated represent the complete and detailed system specification, from business to technology, which is then ready for implementation. As already defined for any component-based development process, typical roles in a component-based development project are the user of components, the assembler of components and the developer of components. The component architecture defined by the method actually represents a point of negotiation between different roles in the development process, as shown in Figure 6.9. The architecture provides a clear connection to the business processes and business domain that are the basis for the requirements on the system being developed. At the same time, it provides easy and effective mapping into an appropriate implementation of the system, built in-house or through reusing third-party software assets.

Figure 6.9 The role of component architecture in a dialog between the roles. The higher-level component architecture, not overloaded with unnecessary details, can be used for the purpose of negotiation between the business user as the user of the component system and the system architect as the assembler of components. It should be decided at this level how business requirements should be mapped into the system solution in a most effective manner. It is possible to determine exactly the system parts that are responsible for satisfying particular business needs and therefore to be able to replace/improve/change those parts if

181

Chapter 6 business changes. Business users can easily recognize and articulate their needs using the business component architecture that hides low-level implementation details. The completely specified component architecture can serve as a point of negotiation between a system architect on one side, and a component developer, a provider of COTS components, or a provider of Web services, on the other side. At this level the decision about an appropriate implementation solutions for components specified within the architecture should be made. A particular way for realizing the component specification can be changed throughout the component lifecycle, while the contract between the component and its context should be kept stable.

182

7 Test and Evaluation of the Method The goal of this research was to create a component-based and service-oriented design and development method that uses components throughout the development lifecycle, from business to deployment. In this chapter, we will present test and evaluation of our method based on the usability of the method, users’ evaluations of the method and potential impact and added values the method brings when compared to with existing development methods. The usability of the method was tested by using it during the development process of building a typical location-based, geographic information application to support user requirements for geo-information related to a certain geographic area and particular user concerns, anytime and anywhere. The use of the method to design this example forms the first half of the test case study. Using the method to design the sample system is summarized in the first section of this chapter. Following a number of presentations and discussions, regarding the method and its applications, that we had with participants from the organization where the case study was performed, a survey was used to gather opinions and, in this way, to conduct the users’ evaluation of the method. The results, and the discussion of the results, of the survey are presented in section 7.2. Finally, we summarize the method requirements defined in section 2.8 and compare these requirements against traditional software development methods such as RUP to highlight the potential benefits and added value of practicing our method in the development process.

7.1 Usability of the Method Usability and applicability of the method was tested by applying the method to design and develop a sample application that includes functionalities of geographic information systems (GIS) and location-based services (LBS). The motivation for this case study came from the researcher’s case study at Geodan B.V., a company located in Amsterdam that builds GIS products for corporations and government institutions (http://www.geodan.com). The sample application, designed and developed within the case study and presented here, was created based on the properties of several real-life Geodan projects. The way of applying the component-oriented method to design this application was presented to selected members of the Geodan team, who then participated in the survey. To maintain clarity and simplicity while applying the method in practice, we did not use all the capabilities and techniques of the method presented in the thesis. However, the main elements and techniques of the method 183

Chapter 7 were well explored, illustrated and tested in the case study. It was beyond the scope of the case study to implement a full and complete GIS application. The aim of the case study to test the usability of the method in a real case, and based on applying the method, to survey the opinions of the people involved in the application of the method. For the purpose of conducting this case study, the OpenGIS specifications defined by Open Geospatial Consortium (OGC) were used. We used the OpenGIS Service Architecture specification (OGC, 2001) to identify basic architectural services and their chaining within a GIS application. Further, we used the specification about core location services to identify and precisely specify the basic services and entities that are of importance in a geospatial, locationbased application (OGC, 2004). 7.1.1 An Introduction to the Sample System The sample system for testing our method will be introduced in this sub-section. The system used in the case study is designed to provide typical GIS and LBS functionalities related to mobile services, spatial data management, routing, and digital map representation. These functionalities were derived from investigating various mobile GIS products that belong to the Goedan product line, and that provide these functionalities to some extent. The sample system was called Odyssey. Generally, the Odyssey system enables users to make remote requests and to get various information about the geographic entities-of-interest (EOI) using a browserenabled smart phone or a Personal Digital Assistant (PDA) in a secure environment. We can define two kinds of actor roles that interact with the system. The first one is a field user, or for short a user, who uses the system to satisfy her or his goals and needs. The second one is a system administrator who supports the operations of the system, maintains the system, updates information available in the system to be used by the user, and charges the user for using the system. In the case study, we were only concerned with the field user, or user, as an actor interacting with the system. The following are the functional features and constraints of the system. A user needs to be registered before being allowed to use the system. The user registers by entering personal information, such as name, title, address, email, phone number, etc., then the login and password information, and finally some personal preferences for using the system, e.g. the type of restaurants the user is interested in. Before any further usage of the system, the user needs to log in first using login and password. When the user session is finished, the user needs to log out. Based on personal preferences, the user can create and maintain a profile that helps in personalizing the context of the system usage and supports a more efficient and effective search for wanted information. The system can manage the user profile in real-time using context-aware information. This means that the system does not handle a long-term static user profile, but it adapts the profile’s definition in a dynamic way. In this manner, the profile reflects what the user wants at the time of searching or during a previous short period of time. Such a profile can be used to personalize the search results to suit the information needs of the user at a particular instance of time. 184

Test and Evaluation of the Method The system provides users with the services needed to browse, search, query, and analyze realtime information about the entities of interest in a consistent and secure manner. The type and nature of these EOIs depend on the purpose of the system, for example these could be finding restaurants, museums and hotels for touristic purposes, or buildings, streets and parks for urban planning purposes. The particular purpose of Odyssey and the type of the main geographic entities used in the system were intentionally left unspecified to preserve the simplicity and generality of the case study. The user obtains necessary information from the system by querying its database and analyzing the results presented graphically or textually. The user can use standard database SQL queries to get information about the textual properties of EOIs. Further, the user can use geographical or spatial queries about the spatial properties of EOIs and their mutual spatial relations. These spatial queries can be of varying forms and complexity, for example simple ones such as: What is on this position? And: What entities are in this region? To more complex queries such as distance queries, nearest neighbor queries, topological queries and direction queries (Stojanović, Djordjevic-Kajan and Stojanović, 2000). We did not explore separately all these types of queries. They are generalized under the notion of spatial queries for the same purpose of maintaining the generality and simplicity of the case study as given above. For the reader further interested in this topic, more information on GIS functionality and queries can be found in (Longley, Goodchild, Maguire and Rhind, 2002). Requesting the system to find a route between two points in a geographic space and to present this route to the user graphically on the geographic map shown on a mobile device screen is a special type of spatial operation. This is a standard LBS/GIS functionality provided naturally by mobile system vendors and used in various domains, e.g. in the modern car industry. Therefore, this feature is considered separately from the general spatial query operations listed above. The user can specify whether they are interested in a shortest or fastest route, or would like to see several alternative routes between two geographic points, usually the current position and the wanted position to be reached. All spatial operations including spatial querying and routing use the mechanisms of geocoding and reverse geocoding. Geocoding is the process that assigns the latitude-longitude coordinates to a street address. Once the latitude-longitude coordinates are assigned, the address can be displayed on a map or used in a spatial search. Reverse geocoding is the opposite process that translates geographic coordinates to the address of a street placed at the geographic point with these coordinates. The user can pay for used geo-services directly via the system, paying pay-per-use or by subscription. In both cases, the user’s credit card should be charged by a certain amount. The user receives regular reports about their payments regularly. At the same time, the corresponding price list for all the features provided by the system is presented to the user.

185

Chapter 7 Finally, the user can subscribe via the system to be notified when an event, spatial or temporal, occurs. The example of an event of interest for the user can be the distance from a gas station in the sense that the user can require to be informed by the system when they are less than 500 meters from a gas station. In this case, the system should perform a continuous spatial query that returns the distance of the user from all gas stations in the vicinity. When the distance of the user form the nearest gas station is less than 500 meters, the system sends a notification to the user. The event/notification mechanism can be applied to different types of events that could be of interest to users. This mechanism is among the standard features in real-time applications, such as location-based services. Besides these functional requirements on the system, it should also satisfy some nonfunctional properties. These properties must address the key concerns of the users that include: usability, reliability, easy of maintenance, extendibility and security. The Odyssey system does not have specific performance requirements defined beyond those commonly defined in LBS and Internet-based applications, such as acceptable response times for user requests. Regarding the usage environment, users access the system via the Internet connections. The system is available for mobile users that use the wireless connection and stationary users that use standard Internet connection. From the perspective of our method, and the design principles applied in it, the type and nature of the physical connection is not important, so the distinction between the two forms of access is not made further. The Odyssey system is designed to run on a reference implementation of the J2EE specification to illustrate the implementation principles described in the previous chapter. Again, the type of the network connection (wire or wireless) will not really influence the detailed design and implementation decisions made in the case study. However, our method aims at being technology and platform independent, and the main focus of it remains on technology and implementation-independent business components and business component architecture. In what follows, we will show how our method was used to design the Odyssey system, based on the requirements and features listed above, by defining and modeling the necessary analysis and design artifacts required by the method. We will present the basic elements of the method in this chapter. Further details about the application of the method in the case study can be found in (Stojanović, 2003). The design artifacts will be grouped into the following model packages: Business Component Model, Application Component Model and Implementation Component Model. Since the Odyssey system was founded, for reasons of simplicity and clarity, as a simple Web application without the ambition to cover a significant part of the business process domain, we will not build the models that belong to the Business Domain Model (BDM), furthermore, these models are not really part of the focus of our method. However, for the purpose of designing and building an enterprise-scale system that might cross enterprise boundaries, the role of BDM is inevitable and its creation must be included in the development process. In the case of designing the Odyssey system, some

186

Test and Evaluation of the Method elements of BDM that are of interest were included during the creation of Business Component Model. 7.1.2 Business Component Model Designing the Odyssey system began with the Business Component Model. Based on the problem description given above and the typical scenario of system usage, we defined the use case model shown in Figure 7.1. We have tried to keep the diagram as simple as possible without including low-level functions and use cases, and without extensive use of include and extend use cases. Although all the operations a user can perform have to include a log in operation, and at the end a log out operation, we do not consider them as necessary use cases to be included, because of the reasons of simplicity. Most of the use cases shown in the diagram are at the level of business-goal use cases, while Registration Failed and Geocoding are at the lower system-function level, but these use cases are necessary for the purpose of the system completeness, as we will see shortly.

Register

Registration Failed

Query Textual Query Geoinformation Query Spatial



User

Find Route

Geocoding Pay for Service

Subscribe for Event

Figure 7.1 The use case diagram of the Odyssey system A typical scenario for system usage and the relationships between the use cases can be represented using the activity diagram shown in Figure 7.2. The activity diagram shows the sequencing and time ordering of use cases done by the user. For example, before any operation performed using the system, the user needs to be registered, the operations for routing, subscribing and querying are not performed in parallel, and after the user finishes 187

Chapter 7 with operations and before ending the session, the user needs to pay for services used on a pay-per-use basis. Although not seen in this case study to their full extent, the relations among use cases can be varying and complex, reflecting the business processes the system participates in and automates. Start Session

[ not correct ]

Register

[ correct ]

Manage Profile

Select Operation [ routing ]

[ querying ]

[ subscribing ]

Find Route

Subscribe for Event

Query GeoInformat ion

Analy ze Results [ more operations ]

Pay for Service

End Session

NewState

Figure 7.2 Activity diagram of the system Next to these two models, we need to define the domain information model of the system. It is represented by the class diagram and shown in Figure 7.3. The domain information model contains the main information types that represent the concepts of the business domain that should be handled by the system. Each information type has the list of attributes and constraints defined on them. Important associations among the types are also shown. The types represent basic business abstractions and concepts the system needs to keep track of. Furthermore, these types are often used to define the tables of the system database while the instances of these types populate the tables. Depending on the nature of the GIS application and the kind of entities of interest, the information type Geographic Entity can be further specialized into types representing concrete geographic entities of interest for the user.

188

Test and Evaluation of the Method Geographic Area Name : string Shape : geometry

+belongs to

1..*

Geographic Location

Route

Geographic Entity

Start : GeographicLocation End : GeographicLocation Length : double

Name : string Shape : Geometry Position : Geographic Location

X-coord : integer Y-coord : integer Latitude : float Longitude : float

+has

1..*

+positioned on

+defined on

User

Query

+poses

RequestCondition : string RequestSource : string 1..* 1..*

+has

Invoice Amount : double Date : string

Login : string Password : string Name : string

+is charged 0..*

Event

+subscribes

0..*

Name : string HandlingRule : string +causes

+receives

Account Number : string State : double

Notification Message : string

Figure 7.3 Domain information model Business rules can be incorporated into the models given above in various ways, depending on their nature and scope. Some business rules refer to the way operations and events in the system are ordered in time, expressed as the relations between use cases or between the steps of a single use case. Business rules can also be specified through some constraints on business entities defined in the domain model, or as non-functional attributes of the system. Regarding non-functional, quality requirements specified for the system, they can be related to particular use cases representing particular functionality of the system, or can be applied across several use cases. In the former case, these requirements become parts of the description of corresponding use cases. In the case of the Odyssey system, examples of business rules can be that the user has to pay a previous invoice before they can use the system again, or the user cannot have a negative account balance, or the system must be operational on a 24x7 basis. Typical non-functional requirements for the Odyssey system are security when managing the user’s profile and account information, reliability in system operation and high performance for the operations of querying and routing since they often need to provide the right information in real-time. The use cases defined for the system can be specified in more detail using the corresponding use case description template that includes its name, a short description, involved actors, goal in the context, scope, level, preconditions, post-conditions, triggers, main success scenario, extensions, sub-scenarios, information types used, and eventually assigned non- functional parameters. The detailed specification of all defined use cases gives a clear picture what is 189

Chapter 7 expected from the system being built, and represents a part of the contract between the system producer and the system user. At the same time, this specification will be used in specifying business components that are responsible for supporting and realizing particular use cases. For example, the specification of the use case Find Route is given below in Table 7.1. Table 7.1 Detailed specification of the use case Find Route Name

Find Route

Initiator

User

Goal

To find a route between two points in the space.

Description

This Use Case allows a user to get the shortest or fastest route between two points of a geographic area, usually from the user’s current position to a wanted position. 1. The User selects the option to query data from the system database. 2. System provides a query form with all the necessary fields. 3. The User composes the query by filling the empty fields according to the query he/she wants to pose. 4. System checks the correctness of the composed query. 5. System processes the query. 6. System shows the results in an appropriate form. 7. The User makes analysis of the result and acts accordingly.

Main success scenario

Alternative scenario

5. Query is not correct a. System reports about the errors in the composed query. b. The user corrects the query c. Resume 4

Preconditions

The wanted routed must be specified with exactly two points.

Post-conditions

The route is presented on the displayed map clearly.

Information types

Types that define geographic entities that have point and line geometric forms.

Included cases

use

Geocoding

Extended cases

use

None

Non-functional requirements

Response time must be minimal. Expected frequency of performing this use case is 100 times per day.

Possibilities were identified in the Odyssey project for using third-party software packages or legacy systems to fulfill some of the functions provided by the system. Examples of functionality that could be reused in the project and not built by our team were the component providing services for credit card payments, often provided as a Web service, by the corresponding company being a service provider; the component providing routing 190

Test and Evaluation of the Method information, which is often available as a COTS component provided by companies specialized in this type of applications; or the component for geocoding which is available from the Geodan company as a legacy component to be used in their GIS applications. The existence of these component realizations, and the plan of the project team to use some of them instead of building new components, can influence significantly the process of identifying and specifying main components of the system. The use of third party software almost always includes a need to redesign the system, since a reused component rarely fits 100% into a given specification, but at the same time reusing saves some time that otherwise would be spent on building a new component. A balanced approach and careful consideration are necessary in such a situation. Following the approach for identifying components based on the use case analysis presented in sub-section 6.5.2, we define the first-cut business services and components of the system. Initially, these business components are organized around business-goal level use cases of the system that represent architecturally significant functionality of the system. The services of the initial business components are responsible for supporting the realization of these use cases. For the Odyssey system, these architecturally significant use cases are Register, Query Geoinformation, Find Route, Pay for Service and, to some extent, Subscribe for Event. At this moment, there is no need to specify so-called change cases that document areas where the system may potentially change in the future, and that can be the main input for specifying configuration parameters of the business components. A complex, Internet-enabled system can potentially have a number of use cases defined at the business-goal level. These use cases need first to be clustered into units of cohesive functionality as described in sub-section 6.5.2 through the rules for allocating use cases together, or separating them into different clusters. In the case of the Odyssey system, the situation is rather simple; for each of the main use cases of the system, a business component that realizes this use case is identified. Initial business components of Odyssey are: ♦ RegistrationManager – to maintain personal data of the user, to control login and password information of the user, to enable creating and modifying the user profile, and to ensure security; ♦ QueryManager – to support querying of information about the geographic entities of interest based on various criteria; ♦ RouteFinder – to manage activities related to determining the shortest or fastest route between two points in the given geographical space; ♦ PaymentManager – to support the user payments for the services used; ♦ Event/NotificationManager – to support event subscription and user notification mechanisms. As a digression, it is worth noting here what would be the result of component identification process if an entity-driven approach were applied. In this case we would end up with a number of fine-grained components based on underlying domain entities and tightly coupled to each 191

Chapter 7 other. That would be especially critical in entity-intensive domains such as GIS, where potentially a great number of geographical entities can be defined, for example in the case of the Odyssey problem domain those would be User, Invoice, Query, but also Street, River, City Area, etc. In this way, the whole idea of components would be degraded into a database schema presented in a kind of entity-relationship diagram. Defining components based on fine-grained technical or business functions, such as logging or geocoding, would also result in too fine-grained, although activity-based, units that can not add value for building a wellstructured, adaptable architecture that maintain the complexity of the system solution through the separation of concerns. Business components defined above can be further specialized into more concrete components. For example, the QueryManager component can be specialized into SpatialQueryManager and TextualQueryManager components. Similar to this, the PaymentManager component can be further specialized into the PaymentPer-UsManager component and the PaymentManager ‘through Subscription’ component depending on the types of payment. In contrast, the component Geocoder can be defined as lower-level nonbusiness component that actually provides important mechanisms included in the functionality of the business components QueryManager and RouteFinder. The business services, defined for each business component, are cross-referenced with the given information model to decide what information types are needed by a particular component to provide its services. This can be derived from the specification of use cases that a particular business component supports with its services. The UML representation of two components of the system – QueryManager and RegistrationManager, together with the information types they handle, is shown in Figures 7.4 and 7.5 respectively.

IQueryMgt Comp oseQuery() Process Query() HandleErrors () Pres entR es ults()

Query Manager

+uses

+defines

1..*

Query Re questCo ndition : str ing Re questSource : string

Geographic Entity

+defined on

1.. *

Nam e : string Shape : Geom etry Position : Geographic Location

+belongs to

+has

Geographic Location X-coord : int eger Y-coord : integer Latitude : float Longitude : float

Figure 7.4 Specification of the QueryManager component.

192

Geographic Area Nam e : s tring Shape : geom etry

Test and Evaluation of the Method

IRegMgt ManageLogin() HandleProfile() LockSys tem () ManageMenu()

Registrat ion Manager

1..*

User Login : s tring Pas s word : s tring Nam e : s tring

Account +has

Num ber : s tring State : double

Figure 7.5 Specification of the RegistrationManager component The business components are fully specified along the four viewpoints defined in chapter four, namely context, behavior, information and realization. Models and specifications created during requirements analysis are used for this purpose. Constraints in the form of preconditions and post-conditions are defined for each service of a component. An example of the constraints in the case of the ProcessQuery service of the component QueryManager is shown in Figure 7.6. Coordination relations among the component’s provided and required services are derived from the use case model, namely from the relations among use cases that are realized by the component services. According to this, the QueryManager component can be activated only after the activation of the RegistrationManager component used to register the user through his login and password, while the PaymentManager component is activated after the user uses the system by querying information through utilizing the services of the QueryManager component. At the level of a single business component, it is obvious that the ProcessQuery service can be used only after first invoking the ComposeQuery service of the QueryManager component. context Process Query ; preconditions: Query.Syntax = SQL

IQueryMgt

post-conditions: Query is memoriz ed

ComposeQuery() ProcessQuery() HandleErrors() PresentRe sults()

Figure 7.6 Contract-based constraints on a component service Constraints in the form of invariants and the dynamics of instances of component information types are defined in the form of state transition diagram or using OCL constructs within a UML note. For example, the invariant conditions for all instances of the information type Route can be that the specified route must have the source and the destination specified, they 193

Chapter 7 must not be equal, and they have to represent point-like structures or be approximated as points. The state transition diagram that shows the dynamics of an instance of the type Route is shown in Figure 7.7.

DefineRoute

Route Defined CalculateRoute

PresentRoute

Route Calculated

Route Presented

DeleteRoute

Route Deleted

Final 2

MemoryRoute

Route Memorized

Final 1

Figure 7.7. A state transition diagram of an instance of the type Route The initial business component architecture of the Odyssey system representing its main business components and dependencies between them is presented in Figure 7.8.

Event Manager IEventMgt

QueryManager IQueryMgt

RegistrationManager IRegMgt

Route Finder IR outeMgt

Payment Manager IPayMgt

Figure 7.8 Initial business component-oriented system architecture

194

Test and Evaluation of the Method As shown, all the components are dependent on the component Registration Manager, since this component handles the login and password information of the user, and manages the user profile which influences the performance of the services of other components that are customized according to the profile, including routing, event notification, querying and payment. Further, the component EventManager is dependent on the components QueryManager and RouteFinder, since performing continuous queries and refreshing the route information form the core of the event notification mechanism. 7.1.3 Application Component Model Having created the main artifacts of the Business Component Model, we started to decompose the business components into finer-grained application components, which collaborate to provide business services. While business components provide some business value for the user and a complete business activity, e.g. find a route to the hotel, the application components that constitute these business components provides finer-grained services that do not represent an added value from the user perspective. However, these application components taken together realize the business functionality of the business component to which they belong. Note, some coarser-grained business components are further decomposed into finer-grained business components before being decomposed into application components. To check whether this is the case with a particular business component, we examined whether it supported several loosely coupled business-goal use cases, and if so, we decomposed the business component into finer-grained business components along the boundaries between these use cases. We use logical layering into consumer interface, logic and data handling layers for the purpose of decomposing business components into application components. Using this strategy, we can decompose the RouteFinder component into the following components: ♦ RouteComposer: this is responsible for defining the start and ending point of the route and for criteria used to determine the wanted route, e.g. the shortest or fastest route. This component belongs to the consumer interface layer. ♦ RouteProcessor: this is responsible for calculating the route based on the given points and specified criteria. It uses the Geocoding component to transfer addresses into coordinates and vice versa. This component belongs to the logic layer. ♦ DataHandler: this is responsible for obtaining the data necessary for calculating the route from the data store or from components carrying this data in the runtime. In this way, the peculiarities of a particular data sources are hidden from consumers of data in the business logic layer. The DataHandler component contains the implementation of indexing structures to speed up data retrieval from potentially large geographic data sources. It belongs to the data-handling layer. ♦ ResultPresenter: this is responsible for presenting the resulting route, and possible alternatives, to the user in an appropriate way. This component belongs to the consumer interface layer. 195

Chapter 7 ♦

ErrorHandler: this is responsible for handling errors made in defining, calculating, or presenting a route and it belongs to the logic layer.

The collaboration between application components providing higher-level business services of the Route Finder component is shown in Figure 7.9.

: User

: Route Composer

: Request

: Route Processor

: Error Handler

: Data Handler

: Result Presenter

ComposeRoute Make Request

Process Request Check Request Report Errors Show Error Report

Change Reuqest Peform Reuqest Send Results Results Presented

Figure 7.9 Sequence diagram showing the collaboration of application components.

Some other application components can participate in the realization of the business component RouteFinder. For example, these are the components responsible for representing the geographic entities that are of interest for calculating the route between two points, such as streets, roads, bridges, etc. The DataHandler component is responsible for obtaining the data kept in these entity components, when it is necessary. Furthermore, the application components that implement some fine-level calculations and transformations can be part of the RouteFinder realization, such as the component that implements an algorithm for calculating the path between two nodes of the network structure that contains nodes and edges with weight factors. One of the well-known examples of such an algorithm is Dijkstra’s algorithm (Longley, Goodchild, Maguire and Rhind, 2002). We can also decompose business components by grouping their services into cohesive sets and make these service sets the responsibilities of particular application components. Thus, in the case of the RegistrationManager component we can define the following application components that belong to it: Login&PasswordManager, RegistrationFailureHandler, 196

Test and Evaluation of the Method ProfileHandler, and MenuRepresentationManager. It is worth noting that the RegistrationFailureHandler component is responsible for realizing the use case that extends the use case Register to handle the reaction of the system to potential registration failure, see Figure 7.1. Precisely defined application components and their collaboration and dependencies are used to represent the detailed specification of the platform-independent architecture of the system prepared for implementation. Some application components can be already sourced as thirdparty software packages. For example, in our case the Geocoding application component has been provided by a third-party GIS software vendor. 7.1.4 Implementation Component Model Taking system distribution and multi-tier system architecture into account, the defined application components can be transferred to corresponding distributed components. Some applications are related to the user interface (UI) tier, some to the business logic tier, and some to the data storage tier. For example, RouteComposer and ResultPresenter are attached to the UI tier, while RouteProcessor is attached to the business logic tier, communicating with the DataHandler that resides in the data storage tier, as shown in Figure 7.10. If we consider the implementation of the Odyssey system using the J2EE platform then the components RouteComposer and ResultPresenter can be realized using Java Server Pages, the RouteProcessor component can be realized using one or several session beans. Different Geographic Entity component, corresponding to different types of geographic entities of interest, can be realized as entity beans. The ErrorHandler component can be realized using the exception handling mechanisms of the platform. The DataHandler component can be realized using SQL scripts and database connectivity APIs.

Request

Geographic Entity



Route Composer Route Processor

Data Handler

UI Forms Result Presenter Error Handler

Figure 7.10 Application components distributed over the tiers.

7.2 Users’ Evaluation of the Method The users’ experiences with, and evaluations of, the method were collected using a survey. The survey covered the employees of Geodan who participated in the Odyssey case study and who were presented the example how the method was applied to the sample system above. 197

Chapter 7 The aim of the survey was to obtain an independent evaluation of the component-oriented design and development method from people who were potential future users of the method, but not involved in its creation. We included in the survey persons with different backgrounds and different roles and concerns in the development process, from information systems business analysts to software architects and developers to help us to obtain illustrative and valid results. All the survey participants had rich experience in the fields of GIS and software systems development, and extensive knowledge of the latest developments in software engineering and computer science, such as component-based development, Web services, and system analysis and design using UML. The Odyssey system combined features drawn from several of Geodan’s working software systems all of which provide mobile and location-based services. Thus, the participants were familiar with the system description and existing implementation of certain features. They were looking for a more efficient and effective way of building such systems in the future using component-based system analysis and design. 7.2.1 Case Study At the beginning of the case study we held discussions with the participants to determine and assess their current development process practice. We were mainly interested in which development process model they used, i.e. none, waterfall, spiral, extreme programming, rapid application development, or something else, and which particular methods they followed, i.e. structured analysis and design, object-oriented analysis and design, Booch, Objectory, or something else. Finally, we were interested in whether the methods and processes involved CBD principles and activities and, if yes, in which way. Before conducting the case study, project teams at Geodan had used the Iterative Application Development Process that belongs to the RAD family of process models. The process includes creating a proposal for the general requirements of the system being built, which involves domain experts, technical architects and software developers. Every six weeks a prototype of the system is built and then confronted with the list of requirements. In a process of reiteration the development team continues to make choices regarding the features that need to be built. They also discuss time and money issues and allocate tasks. No particular design and development method or approach was followed by the Geodan experts during the process. Usually, the requirements were directly transferred to software code without creating the business or application architecture of the system. This approach can only give satisfactory results only when building simpler and smaller systems, where the role of software architecture and design, and a disciplined approach when developing software, is not critical. If there was a need for analysis and design activities within a project, these were largely performed in a classical object-oriented manner. The state of practice of component-based development, and the level of adopting CBD principles in Geodan development projects were mainly focused on GUI components that were used to facilitate the implementing of client interfaces and on software components deployed as code packages. If performed, system analysis and design were not conducted in a component-based manner. This assessment of 198

Test and Evaluation of the Method existing development practice at Geodan helped us to design an appropriate survey, which had to represent a bridge between the as-is situation in the organization and the to-be capabilities for complex system development offered by our method. We presented the basic elements of the method to the participants during a group session. The basic set of consistent and technology independent component concepts and the way of modeling of these concepts using the UML versions 1.x and 2.0 were presented to the participants. Regarding the way of working of the method, we presented the basic steps, guidelines and techniques defined in the method to the participants. These are designed to be used to transform the business requirements of the system to the working software implementation. The Odyssey system was used as an example to illustrate the application of the method. The participants were able to ask questions and to improve their understanding of the method during these presentations and accompanying discussions. 7.2.2 Survey Settings We decided to use the technique of structured interviews. In its simplest form, a structured interview involves one person asking another person a list of carefully predetermined questions about a selected topic. The person asking the questions, interviewer or researcher, is allowed to explain the things that the interviewee, or respondent, does not understand or finds confusing. All interviewees are treated equally since all of them are asked the same questions. This replication of the same interview with all the interviewees enables comparing and aggregating data, while the interviewees are able to elicit comments. The interviewer, or researcher, can then generalize the findings of the survey to the population from which the interview sample came. Standardization of questions in the interview provides the reliability and supports generalization of the results and conclusions. The survey, performed in the form of structured interviews, enabled us to examine how well the participants understood our component-oriented design and development method and its application in the real case study. The survey provided us with a reliable source of quantitative data derived from the statistical analysis. We were aware that the quality and usefulness of the information gathered was highly dependent upon the quality of the questions asked. We, therefore, spent a substantial amount of time pre-planning of the interviews. Furthermore, we took into consideration the possibility that our presence might influence the way interviewees answered various questions, thereby biasing the responses, and we tried to minimize that effect. The interview questions were formulated as propositions in an attempt to force the interviewees to make their opinions explicit. The interviewees could answer a question based on a five-point scale ranging from (1) strongly disagree, (2) disagree, (3) neutral, 4 (agree) to (5) strongly agree. We used a statistical test to gain support for the directions of the outcomes. We had six participants in the survey. In the survey tables, m denotes the mean, i.e. the average of the given grades, sd denotes the standard deviation, and np represents the number 199

Chapter 7 of positive responses, i.e. responses 4 or 5. Both the mean and the standard deviation were rounded to one decimal place. The range of possible statistical tests is limited, as we had to deal with the following limitations. No direct comparison with other situations was possible. Comparison could only be based on the experiences of interviewees. Although the participants had not practiced any component-based development method before the case study, most of them possessed a reasonably good knowledge of, and experience with, component-based principles and practice. The interviewees were not chosen randomly from a larger population; they were directly involved in the case study. Consequently, the results cannot be considered to be independent. The number of persons actively involved was limited. We included in the survey all the relevant persons from Geodan B.V. who might be potential users of the method, such as information systems business analysts, IT architects and senior software developers. 7.2.3 Survey Questionnaires We divided the survey into three questionnaires; each one reflected a particular aspect of the method that we wanted to evaluate. The first part of the survey was related to the case study in general and the general characteristics of the method such as simplicity, flexibility, practicality and systematic nature. The second part of the survey examined topics related to the main characteristics of the component concept as proposed in the research and in the way of component modeling and specification. The survey covered only modeling components using UML, as other modeling notations, such as IDL-based textual notation and XML-based notation, were not explicitly included in the case study. The final part of the survey covered the topics related to the way of working of the method, i.e. the set of design steps, principles, guidelines and techniques used to go from requirements to implementation using defined component concepts. The survey questionnaires are given in more detail in Appendix B. The set of topics and answers related to the case study and our component-oriented method in general is shown in Table 7.2. Due to company’s market orientation, the natural project settings in Geodan are commonly related to delivering software on time under the pressure of strict deadlines and frequently changing customer requirements. Therefore, a disciplined development process, that follows a structured method, has been rarely followed. That made our mission in Geodan twofold. Our first aim was to demonstrate to members of the company the benefits and roles of a development method and a disciplined process when building software systems. We aimed at convincing Geodan experts that a good architectural design, using modeling methods, is as important as software coding. Our second aim was to show how a component-based development method offers a number of advantages and benefits over a traditional development method. The participants generally agreed on the benefits of using component thinking throughout the development lifecycle as the way of organizing business requirements into cohesive units of functionality, creating a component system architecture based on these units, and mapping them into implementation artifacts in an easy and 200

Test and Evaluation of the Method straightforward manner. In this way, the bi-directional traceability between given business goals, and the software artifacts that support and realize them, is achieved. Table 7.2 Answers regarding the component-oriented method in general

Participation in this case study was valuable for my organization. The method showed the importance of following a development process in building a system. The method showed the importance of modelbased and architecture-driven development for communication and understanding among project members. The method showed the benefits of using the component concept throughout the whole development process. The method was shown to be simple. The method was shown to be practical. The method was shown to be flexible. The method was shown to be systematic.

1 0

2 0

3 1

4 3

5 2

np 5

m 4.2

sd 0.7

0

0

0

3

3

6

4.5

0.5

0

0

2

3

1

4

3.8

0.7

0

0

1

2

3

5

4.3

0.8

0 0 0 0

0 0 1 0

1 1 2 0

3 2 2 4

2 3 1 2

5 5 3 6

4.2 4.3 3.5 4.3

0.7 0.8 1.0 0.5

The survey participants were also asked about the general properties of the applied method, i.e. to what extent the method was simple, practical, flexible and systematic. The method was evaluated to be fairly simple, since it is aimed at defining a minimal set of coherent component concepts, principles and design guidelines necessary for modeling, designing and building software systems in a component-oriented manner. The method was evaluated as systematic, since it was shown in the case study that the method provided a stepwise process to guide the design of four component architectural models. Details were added systematically according to the objectives of the models, with seamless transformation from the artifacts of one model to those of another clearly demonstrated. Parallel to its prescriptive nature, the method allows space for including variants, extensions and changes according to the needs of the particular project and the people working on the project and using the method. In this way, the method behaves more as a methodology framework that can be used to define what steps are useful to perform and why, without strict directions about how they should be performed. Applying the method effectively in the practical case study demonstrated that it could be applied in practice in an easy and effective manner and that it is compatible with current achievements in software development practice, such as Web services, the J2EE platform, and the UML standard. The flexibility of the method was difficult to demonstrate, since we applied the method in just one case study. A method can be flexible in two ways, flexible in terms of scalability if the problem scales and flexible in terms of applying in different project 201

Chapter 7 contexts. The set of topics and answers related to the component concepts and modeling notation used in the case study is shown in Table 7.3. The component concepts and aspects defined by the method given in this questionnaire were mostly clear and intuitive for the participants. When it was necessary, further explanations were given. Table 7.3 Answers regarding the component concepts proposed and used by the method

The component concept as a key technologyindependent abstraction of the system architecture was clearly defined. The composition and black-box characteristics of components were understandable. The representation of component in terms of its content, contract and context was suitable for representing our domain components. The definition of the component contract beyond the simple set of operation signatures was well established. The component specification defined from different viewpoints, i.e. context, behavior, information and realization, was complete and understandable. Different granularity levels of components and their role in the development process were clearly defined. Different facets of a component, namely specification, implementation and deployment, and their roles in a development process were appropriate. The component modeling notation based on UML was understandable. The presented component concept is suitable for representing services in a service-oriented architecture.

1 0

2 0

3 1

4 2

5 3

np 5

m 4.3

sd 0.8

0

0

0

3

3

6

4.5

0.5

0

0

1

3

2

5

4.2

0.7

0

1

1

2

2

4

3.8

1.2

0

0

2

2

2

4

4.0

0.9

0

0

1

4

1

5

4.0

0.6

0

0

0

2

4

6

4.7

0.5

0

0

2

3

1

4

3.8

0.7

0

0

1

4

1

5

4.0

0.6

The set of component concepts proposed in the method were generally clear and well understood by the participants. They gave mainly positive responses to the propositions about the component as a key abstraction of the system architecture, both logical and physical, with black-box capabilities and represented through its context, contract, and content. The definition of the component contract as containing more than just operation signatures, as 202

Test and Evaluation of the Method usual in programming language constructs and IDLs, was mainly positively valued. However, for participants with a software development background, this was not recognized as an essential property of the component, and was denoted mainly as unnecessary. This was a clear consequence of their treatment of components as implementation packages that only provide operations through interfaces; this is mainly of interest for software developers in later phases of the development lifecycle. For similar reasons, two participants with a software development orientation had neutral opinions about the complete component specification done from the four defined viewpoints, which represents sufficient information for a component consumer to use it without knowing its internal realization. Those participants treated and used components mainly as software packages inside their programming environments, so that the standard IDL-based component interface specifications seemed to be sufficient for them. The definition of different granularity levels of components, coupled with different facets of a component in its lifecycle, specification, implementation and deployment, were generally well accepted and comprehended. While not all the participants were convinced of the necessity for defining enterprise and business components, one neutral opinion and four ones “agree” only, again from the current trend of using components simply as implementation artifacts, all the participants were quite positive about the aspects of the component lifecycle, from specification to deployment, that strongly correspond to the lifecycle of the software system as a whole. There were some doubts (neutral opinions) about the component modeling notation based on UML. The reason was that the proposed notation is based on the new UML version 2.0, which is still in the process of final acceptance and therefore not yet widely used in software design and is little supported by popular modeling tools. Therefore, the participants were not familiar with all the elements of the UML 2.0 standard specification. Similarly, due to the novelty of the concept of services and service-oriented architecture (SOA), not all the participants were positive about the semantic power of our component concepts to represent the main building blocks of SOA. We strongly believe that the participants would have answered this question in a more positive manner, if they had possessed an improved knowledge of the basic SOA concepts and principles. The set of topics and answers related to the modeling and design steps, guidelines and techniques used in mapping the requirements into the software implementation during the case study is shown in Table 7.4. The elements of the design process defined by the method given in this questionnaire were mostly clear and intuitive for the participants. When it was necessary, further explanations were given. The participants valued positively the structure of the method given by designing the four basic models – Business Domain Model (BDM), Business Component Model (BCM), Application Component Model (ACM), and Implementation Component Model (ICM), since they correspond to the natural levels of abstraction in system development, this time oriented towards components.

203

Chapter 7 Table 7.4 Answers regarding the way of working of the method

The separation of concerns used in the method based on four architectural models was logical. The models included in the Business Component Model were complete. Identifying business components based on combining top-down and bottom-up strategy was suitable for our domain. The role of business components in organizing requirements and translating them into the architecture was appropriate. The role of business component architecture as a point of alignment between business and IT was useful. Decomposition of business components into application components based on logical layers was appropriate. The mapping of application components into implementation artifacts of the J2EE platform was appropriate. Modeling components using UML throughout the development process provided better communication and understanding among stakeholders. The concept of business component that supports cohesive use cases/services was suitable for modeling Web services in our domain.

1 0

2 0

3 0

4 4

5 2

np 6

m 4.3

sd 0.5

0

0

2

2

2

4

4.0

0.9

0

0

1

4

1

4

4.0

0.6

0

0

1

3

2

5

4.2

0.7

0

0

2

3

1

4

3.8

0.7

0

0

1

2

3

5

4.3

0.8

0

0

0

2

4

6

4.7

0.5

0

1

1

3

1

4

3.7

0.9

0

0

3

2

1

3

3.7

0.8

Two opinions were neutral when judging whether the set of models included in BCM is complete. These respondents had normally used the models and mechanisms to elicit requirements different, to a certain extent, from the models included in BCM. The questions related to the concept of the business component, as the main architectural abstraction proposed by our method, were answered in a positive manner. This included the way of identifying business components based on the combination of top-down and bottom-up approaches and the role of business components in organizing and allocating requirements, in defining logical system architecture and in providing the bridge between business and IT concerns. The strategies used for decomposing business components into application components based on the logical system layers and for decomposing and realizing application components using implementation components of a particular component platform were 204

Test and Evaluation of the Method valued positively. This was expected given the more technical than business orientation of most of the participants. Finally, not all of the participants were positive about the usefulness and appropriateness of using UML to represent components throughout the development process. The main reason for this was that most of the participants had not had experience with projects consisting of analysis and design activities using UML. Similarly, the participants did not answer significantly positive the question about the capabilities of our business component concept for modeling Web services within a service-oriented design process, mainly due to a lack of knowledge and experience with the new development paradigms of Web services and service-oriented architecture. 7.2.4 Survey Summary We obtained indications of a positive evaluation of our component-oriented design and development method from the persons involved in the case study. The arguments provided by the participants when choosing answers on the given propositions were in favor of our method. At the end of the case study, the participants were pretty much convinced that their organization would adopt the proposed method, or a variant of the method based on similar component-based principles and techniques, in the near future. The participants were completely aware of the benefits of using a component-based and service-oriented way of thinking, modeling and working throughout the development lifecycle, from business requirements to implementation, to gain such benefits as effective management of complexity and changes, business/IT alignment and traceability, reusability and replaceability, and efficient legacy integration.

7.3 Added Value of the Method In this section, we will attempt to show the added value of our component-oriented design and development method and compare it to existing OO and CBD methods found in the literature. 7.3.1 Methods comparison As stated in Fielding (2000), most artifacts of creative thinking and design, such as design methods and architectural models created using these methods, are notoriously hard to evaluate and compare in an objective manner. One can suggest that an appropriate and objective evaluation and comparison of the methods might be to test a sample of several methods by applying them to several complex real-life projects conducted by the same team of people within a relatively short period of time, and then measure the various qualitative and quantitative parameters related to each method. However, this kind of test in existing circumstances is highly unrealistic. One, it is difficult, if not impossible, to find a team of people within a commercial organization willing to spend their time in doing such test, and who would finance it. Two, a high percent of today’s software systems development organizations, due to strict deadlines, the pressure of short time-to-market and a primary focus 205

Chapter 7 on the system that works no matter how, simply do not follow a disciplined development process defined by a method. Such development projects commonly use a code-and-fix strategy. Three, if an organization practices a disciplined method when developing software systems and not just code-and-fix strategy, a structured development method or an objectoriented development method is commonly used. Methods that include component-based and service-oriented principles and techniques are rarely adopted in practice and still represent potential future investments for software development organizations. We, therefore, decided to define a set of requirements for a component-based and serviceoriented method (see section 2.8), based on an extensive literature survey, the performed inductive case study and discussions with experts in the field. A sample of six existing OO and CBD methods was evaluated and compared against the set of requirements, with help of expert panels and master student tests (see section 2.8). The methods that were evaluated to see “how well” they met the defined requirements were Rational Unified Process (RUP) (Krutchen, 2003), Catalysis (D’Souza and Wills, 1999), Select Perspective (Apperly et al., 2003; Allen and Frost, 1998), KobrA (Atkinson et al., 2002), UML Components (Cheesman and Daniels, 2000) and Business Component Factory (Herzum and Sims, 2000). The method proposed in this thesis was built upon these requirements, i.e. it was designed explicitly to meet them. This allowed us to compare the method proposed in this thesis with other CBD methods in an indirect way. The CBD method requirements are classified into those that belong to the way of thinking of the method, then the way of modeling of the method and finally the way of working of the method. Since the focus of our method is not on the management process in system development, i.e. managing and planning people, resources, deliveries and artifacts, we did not address in detail these aspects of the method. This constitutes the way of controlling of the method and will be a part of further research to improve the method. The defined CBD method requirements are summarized below. Way of thinking ♦ to define the component as a focus of a development process; ♦

to provide clear, consistent and technology-independent definitions of the component concepts; ♦ to provide enriched and enhanced definition of a component interface that is beyond the simple list of operation signatures, and above the pure technology level; ♦ to define service-based components, rich in behavior and functionality, rather than data-driven components that only consist of data attributes and set and get operations on this data; ♦ ♦

206

to define different types, scope and granularity of components that fit into different phases and aspects of the system development lifecycle; to define different perspectives on components, such as conceptual, logical, implementation, and deployment, in order to make the component concept traceable from business concepts to deployment;

Test and Evaluation of the Method Way of modeling ♦ To create a graphical component modeling notation, using e.g. UML with extensions, that is expressive enough to provide communication and understanding among different actors in the development project. ♦ ♦

To create a textual component modeling notation that can be understood by human actors and mapped easily and straightforwardly to programming language constructs, using IDL or template-based forms.

To create a machine-readable component modeling notation that can be used for communication between automated systems, i.e. XML-based notation that extends e.g. WSDL. ♦ To provide modeling of various aspects of components in a clear and consistent way. ♦ To provide modeling of collaboration, coordination and (de)composition of components in a clear and appropriate way. ♦

To provide the rigorous component specification that enables the consumer to use the component without knowing how it is realized internally.

Way of working ♦ To cover the full component lifecycle from identification to realization. ♦

To make use of component concepts in all the phases of a development process, from business to implementation. ♦ To provide business-driven identification of components, where components are identified as providers of services that satisfy business goals. ♦ To provide the integration of different viewpoints on the component architecture, namely business, information, application and implementation, into the coherent system architecture specification using components. ♦ To provide implementation-independent component-oriented design that can be mapped into the technology of choice. ♦

To provide an iterative and incremental component-based development process with regular iterations, small increments and frequent prototyping. ♦ To provide flexibility and adaptability of the component-based development process. Way of controlling ♦ To support the management and measurement of the progress of component-based project activities, and plan deliveries of artifacts. ♦ To determine human roles in the component-based project, guide team activities, and allocate resources to team parts. As already stated above, our method was created holding these requirements explicitly in mind. Therefore, the method is intended to meet the above requirements to a high extent, 207

Chapter 7 which has been illustrated above. Some requirements we found more important to fulfill and these were more emphasized in the research than the others, which have been left for future work on improvements of the method. The case study participants and the survey presented earlier in this chapter were used to evaluate “how well” our method met some of the requirements listed above. Although there is no 1-to-1 mapping between the survey questions and the requirements, we can conclude that there was a positive evaluation of the method with regard to the method requirements. In the next section, we will present the main impact factors of our method in relation to current software development methodology theory and practice. 7.3.2 Impact of the Method The research presented in this thesis was conducted in the complex and challenging context of rapidly emerging new developments in the field, and changing concerns in the scientific and industry communities. Thus, at the beginning of the research work (spring 2000), components were treated and used mainly as binary or software code artifacts that could be deployed on computational resource nodes. There were few, if any development methods that included a way of component-based modeling and design above the level of technology. Later, development methods and approaches that claimed to support component-based concepts and principles were proposed, usually derived from existing object-oriented development methods. The most widely used and well documented of these methods were included in the method evaluation given in (Dahanayake, Sol, Stojanović, 2003) and in sections 2.8 and 2.9 of the thesis. An improved view on component concepts has been defined in the new versions and variants of the standard object-oriented modeling language UML, such as the UML profile for EDOC (OMG-UML4EDOC, 2004) and the new major version of UML 2.0 (OMG-UML2, 2004). In the past, we defined the notation for modeling components using the UML versions 1.x, by stereotyping the notions of class, subsystem, collaboration, etc. to represent our component concepts. Now, using UML 2.0, we are well equipped with modeling notation to represent all the necessary concepts we define in our method and the need for using notation extensions has been considerably reduced. In the meantime, some new developments in the field have been proposed and considerable interest has been shown in them by the scientific and industry communities. Examples of such developments are Web services and model-driven architecture. All of them have had a significant impact on the way we created and established our component-oriented design and development method. With the appearance of Web services and the huge hype around them, most people have begun to consider components to be “yesterday’s news”, while other have been trying to “jump” directly from object-orientation to developing Web services. However, the research presented in this thesis shows the importance of, and necessity for, components as the layer of abstraction between business services and implementation-dependent objects and classes.

208

Test and Evaluation of the Method In what follows, we will try to highlight the main impact factors and contributions of our method on existing component-based and service-oriented methodology theory and practice. The clear focus of our method is on components. All the phases of the method are organized around the same set of component concepts, although these concepts are applied at different levels of abstraction and with different purposes in mind. We define components as the key architectural abstractions of the system being developed, ranging from coarse-grained business service components to finer-grained implementation components. So far, the key system abstractions have been defined at the level of entity classes that represent main business entities in the domain, such as in RUP (Krutchen, 2003, Schach, 2004, Wallnau, Hissam and Seacord, 2001). One of the most significant elements of our method is the concept of the business component. We define business components as fully encapsulated and self-describing components that expose business services that support part of the business processes automated by the system. In this way, the main building block of the system architecture and the main unit of reuse is generally not a class but a slice of behavior affecting several classes and encapsulated in a component. Most popular development methods, such as RUP have the principles of object-oriented analysis and design as their foundation, and, therefore, are not easily aligned to componentbased and service-oriented architecture design. They use the notion of a component based on the UML definition of a component, which does not correspond to our definition of a component. This may change with the final adoption of UML 2.0, but to date (end of 2004) components and services are still more closely associated with implementation and deployment, e.g. in the form of source code files. Furthermore, components in e.g. RUP are not typically modeled during the analysis and design phases of the development process. During the architectural design phase in RUP, an information system is decomposed into modules that basically represent the classes of the domain, so that most of the steps taken to create the architecture correspond to class extraction in the analysis workflow. We, therefore, introduced the concept of a component as the level of abstraction between business domain processes and application classes/objects. As one of the architects of UML, and a well-known name in the software engineering field, Grady Booch states, “the entire history of software engineering is that of the rise in levels of abstraction” (Booch, 2002). Our component approach does not exclude the OO viewpoint widely adopted by methods such as RUP, but rather implements another layer of abstraction above the OO viewpoint. Thus, our service-based business components, which focus on automating and supporting business processes or their parts in the domain, help to close the abstraction gap between business process management and OO software development. Our concept of a business component provides business analysts with a non-technical view of software system architecture. Starting the development process with the concept of coarse-grained components instead of fine-grained classes, i.e. by introducing the component thinking early in the development process, can give a number of benefits that include: 209

Chapter 7 ♦ ♦ ♦ ♦

effective maintainability of problem/solution complexity and context changes; effective business/IT alignment and traceability; reusability of third-party solutions and legacy integration early in the process; managing project teams, activities, resources and deliveries more efficiently, especially in the case of distributed teams and the need for parallel development.

One of the main strengths of our method lies in its foundation in the form of a consistent set of technology-independent component concepts that can be uniformly applied in various context and domains, from enterprise components in organization engineering and business modeling, to business components that integrates business and system architecture concerns, and to application and implementation components related to the details of system development. A variety of component definitions have been proposed so far to address different aspects of componentization in software systems development and reflecting the various participants’ concerns in the development process. It is obvious that there is no “one-size” definition that “fits all”. However, in this research we propose a set of component concepts that can be used equally well at different levels of abstraction in business applications development, from component business modeling as described in (IBM, 2004) to low-level application component development. Using the clear and technology-independent definitions of component concepts (given in chapter four) we support common understanding and effective communication among stakeholders with different backgrounds and concerns and across the component-based development project. In a component-based design, as suggested by other development methods, components are often defined to represent closely business entities in the domain, such as Customer, Order, and Account, and to encapsulate the fine-grained functionality for CRUD operations on the entities’ attributes (Endrei et al., 2004, Barn, 2004). In our method, business components are not designed based on business entities. Instead, each business component encapsulates behavior that includes a set of related business entities to provide value-added business services for its consumer. Further, our business components necessarily have active responsibilities, i.e. they provide some behavior and are not only a contact point or managers of some information. Having this in mind, we can claim that our component concepts can be used effectively for the modeling and design of applications that involve Web services. Web services used in business-to-business communication and integration can be specified and designed using the concept of business component, while, for intra-enterprise integration services, application component notion can be used. Hence, our component concepts and principles can be used to help bridge the gap between business process modeling and current object-oriented design practice. Our method provides clear traceability and alignment of business processes, in which the system participates, business components that provide services to automate and support these processes, and application components and objects that actually implement the business components using a technology platform of choice.

210

Test and Evaluation of the Method Modeling Web services using components is equally important for both the service provider and the service consumer. From the consumer point of view, the solution must be well architected in a component-based manner to enable easy and straightforward realization of a design component using an invoked Web services. This bottom-up aspect in defining the business component architecture was described in section 6.5 that deals with creating the business component model. At the same time, the service consumer must ensure that the service realization is done according to component-based principles to ensure the componentbased benefits of maintainability, replaceability, scalability and adaptability. Moreover, a service realization that is not well componentized may impact in a negative way on the service consumer, due to possible internal dependencies in the realization. The service provider can decide to reconfigure the internal components that realize the service for the purpose of e.g. obtaining better performances, without affecting the service consumer, since the service interface remains the same. As has been stated consistently in the thesis, our method is well aligned with model-driven architecture (MDA) principles and practice. However, the key abstractions in our platformindependent and platform-specific models are components of different types instead of finegrained classes and objects. This component-based MDA provides an easy and straightforward transformation between the models using composition and decomposition relations between the components at different levels of granularity and abstraction. The point of consistency and integration between the models is the uniform concept of the component. Furthermore, the component-based MDA strategy defined in our method can be used to help us achieve some of the original aims of OMG when proposing MDA that are not fulfilled yet. One of them is the possibility to execute and test models. As given in the OMG presentations on the basics of MDA (http://www.omg.org/mda/presentations.htm), one of the aims of MDA is to have platform-independent models that are testable and executable. The potential to execute the model as a kind of prototype can be used to validate that the model works as expected and that it meets the requirements of the users (Miller and Mukerji, 2003). The ability to test a PIM provides the developers with an assurance that their models are coherent and gives business users a means of interacting with the model and testing it themselves during its development. This will offer real benefits where the requirements are complex or uncertain, because making necessary corrections at the level of models instead of software code is easier and cheaper. Creating component-based PIMs can help us to have easily designed, testable and executable models. When the contractual interfaces of platform-independent components, business or application, are specified to some extent, the next step is to create a “dummy” implementation of all the elements in the interfaces. This dummy implementation should realize the basic functionality of the components in terms of their collaboration in the request/response manner. In this way, a complete picture of the system being developed is available early in the lifecycle, in sufficient detail for business users to test whether their requirements are fulfilled 211

Chapter 7 in a proper way. As the development of the components progresses gradually and incrementally, more mature implementations of each component will become available and these will replace prior implementations. Each new iteration cycle will add more functionality to particular components and refine the interfaces among them, unless the complete system is has been built. The impact factors of our component-based and service-oriented method discussed in this section show that the method fits very well in the complex context of emerging new developments in the field, such as Web services, service-oriented architecture and modeldriven development, providing a remarkable added value for practitioners in the field.

7.4 Summary In this section, we presented the way we tested our component-based and service-oriented design and development method to demonstrate that using our method is simple, clear and practical and that it provides significant added value for practitioners working in complex system development. We tested the method in terms of its usability in a practical case study, evaluating its practicality using a users’ survey, and highlighting potential impacts and added values the method gives when compared with existing development methods. The usability of the method was tested by using it during the development process to build a typical location-based, geographic information application to support user requirements for geo-information related to a certain geographic area and particular user concerns, anytime and anywhere. The use of the method to design this example system represented the first half of the test case study. After a number of presentations and discussions about the application of the method with the participants from the organization where the case study was performed, we used a survey to gather users’ opinions and conduct the evaluation of the method based on that. We gained indications of a positive evaluation of our method by performing an analysis of the users’ answers to the survey questions and propositions. Our method contributed to a better understanding among the case study participants of the benefits of using componentbased concepts and principles in software development projects. The participants were convinced about the great potential of the method, and they expected the method might be used within their organization in the future. Finally, we summarized the method requirements defined in section 2.8 of this thesis upon which our method was created, and compared these requirements with traditional software development methods such as RUP to highlight the potential benefits and added value of practicing our method in the development process. The potential of our method to fit well into the complex development environment of emerging new developments in the field, such as Web services, service-oriented architecture and model-driven development showed that there is a lot of opportunities for the use of the method that make it a promising solution for complex system development in the future.

212

8 Epilogue Our research started with the observation that the current developments in IT related to CBD and Web services provide organizations with an effective paradigm to build complex software systems within short time-to-market that closely reflect given business requirements. However, the advanced technology is not sufficient on its own to ensure the success of IT development projects. A development strategy is required, that maps business goals and needs to the information system’s building blocks that provide desired functionality to support business. The objective of this research was to design a method for component-based and service-oriented software systems engineering that supports the concepts of component and service during the whole development lifecycle, providing effective business-IT alignment and ensuring maximum benefits of the component way of thinking in complex system development. A summary of the main conclusions and contributions of this work and a number of issues for further research are presented in this chapter. The chapter is structured as follows: the main findings and contributions of the work are described in section 8.1, and some directions for further research are outlined in section 8.2.

8.1 Research Findings Our research has been placed in the context of rapid developments and new achievements in the IT field that aim at automating an ever-growing part of an organization’s business processes and that are supposed to ensure business agility and fast system development within budget and time limits. Therefore, our findings and observations necessarily had to evolve to follow these new, emerging IT developments. 8.1.1 Research Context When this research was begun in spring 2000, it was well established that building software systems using components could bring a number of benefits in terms of developing systems faster and with a higher quality while efficiently maintaining the complexity and adaptability of the systems. The main engine behind these initiatives was an emerging set of technologies that enabled the construction of software using components, called component middleware, such as Microsoft’s COM, Java Beans and CORBA. Components were defined mainly as binary or source code software packages and used in the implementation and deployment phases of the development lifecycle (Booch, Rumbaugh and Jacobson, 1999). In the

213

Chapter 8 meantime, the further evolution of component thinking has given rise to Web services, providing communication of components over the Internet using interoperability protocols and standards, such as XML, SOAP, WSDL and UDDI. New development methods and approaches, more focused on component concepts beyond pure technology and traditional object-orientation, have been proposed, as shown in section 2.4 of this thesis. However, current achievements in this respect are much behind the technological achievements. The question of how to make use of object-oriented methods and techniques when practicing CBD has largely been replaced by whether, and in what ways, CBD methods can be used to develop applications that include Web services. Recently, a great deal of interest has been attracted by the new initiative of the Object Management Group (OMG) called Model-Driven Architecture (MDA) (OMG-MDA, 2004). The MDA framework makes the models at different levels of abstraction the main artifacts of the development process that preserve project investments against changing technology infrastructure. MDA promises to raise the level of abstraction in software development by creating high-level platform-independent business models that are transformed into the platform-specific detailed design models and further into the software code of the technology infrastructure of choice. These model transformations and code generation can be automated using the advanced MDA tools that have started to emerge on the market, providing for the synchronization of models and code in an iterative and incremental fashion. Parallel to raising the interest in MDA, a new version of Unified Modeling Language (UML), version 2.0, has begun to emerge, providing, among other important elements, much better support for architectural modeling and design using components than its predecessors (OMG-UML2, 2004). In this highly dynamic context of emerging IT developments we have proposed a method for component-based and service-oriented software engineering. In the beginning, the method was aimed at using the component paradigm not only at the level of pure technology and software packaging, but also in other phases of the development process, such as analysis and design. The ways and mechanisms for identifying components based on business models, for defining components using a modeling and specification notation and for refining design components successively into the software assets have been the focus of the method. In the meantime, due to increasing interest in, and importance of, Web services, it became obvious that the method should be extended to enable engineering of systems that include Web services, either as providers of services, or as their consumers. Initially, the method was based on the UML 1.x modeling notation (Booch, Rumbaugh and Jacobson, 1999). However, since UML 1.x does not provide sufficient support for modeling the necessary component concepts beyond implementation and deployment diagrams, we proposed a number of extensions in the form of stereotypes and tagged values defined for existing modeling concepts, such as classes, subsystems, collaborations, and interfaces. Then, with the appearance of the new UML 2.0 version, and during the process of its final adoption, we have adopted UML 2.0 and used it as a modeling notation in our method. An extensive support provided in UML 2.0 for component 214

Epilogue concepts at the level of software analysis and design reduced our need to introduce language extensions for representing component concepts. Emerging Web services protocols and standards, such as Web Services Description Language (WSDL) (W3C-WSDL, 2004) and Web Services Choreography Interface (WSCI) (WSCI, 2002), provided us with the basis for defining XML-based specification mechanisms for describing components exposed as Web services that collaborate with other Web services towards a common goal. Finally, in response to the growing interest in the OMG initiative of MDA, we have adopted certain MDA concepts and principles in our method, e.g. defining models at different levels of abstraction and possible transformations between these models towards the software implementation. The development strategy proposed by the method was based on the following complementary requirements. ♦ Faster development of complex IT systems - a system must be built as fast as possible, to save time and money, maintaining effectively its complexity and without quality being affected. ♦ Adaptability and agility – a system must be built in a way that enables it to be changed, adapted or extended quickly, easily and with a minimum of risk. ♦ Business-driven approach – a system must be built in a way that enables it to reflect business requirements and goals promptly and accurately. The basis for fulfilling these requirements lies in the fact that the method is focused on components and services throughout the development lifecycle, from concepts to implementation. In this way, the method is an attempt to gain maximum benefit from this new componentization paradigm in maintaining complexity and changes among others. Further, the method tries to provide consistency across the project and effective business-IT alignment, since all project members, from business analysts to software developers, speak the same “component language” although at different levels of abstraction. Besides fulfilling the requirements given above, the method was designed to be simple, systematic, flexible and practical. Actually, the characteristics of simplicity, conceptual clarity, consistence and systematic nature are essential for the method to be practical, i.e. to be used successfully in real-life projects and to bring the expected benefits to the organization applying it. The main aspects of the method are divided into its way of thinking, way of modeling, way of working and way of controlling. The method defines a number of concepts related to components in the context of system development, including the main component elements, contract-based interfaces and specification, component facets throughout the development lifecycle, and various levels of component granularity. The component concepts are represented throughout the development process using a widely accepted modeling notation based on UML 2.0 with light extensions where necessary. Finally, the method provides pragmatic guidelines, techniques and milestones that use the defined concepts and the notation 215

Chapter 8 to facilitate a stepwise development process in a component-based and service-oriented manner. The method prescribes which activities should be carried out within each step of the development process and provides guidelines to develop appropriate models accordingly. We believe that our method is general, flexible and scalable enough to be used in the component-based architectural design and development of wide range of IT systems, from small-scale desktop applications to complex, Internet-based, enterprises-scale IT systems. In the following section we will highlight the main contributions of our work in terms of the impact of the method on the field of component-based and service-oriented systems engineering and related development paradigms. 8.1.2 Main Contributions The main result of this research is a method for component-based and service-oriented software systems engineering that supports the component and service paradigm in all phases of the system development process, from business requirements to implementation assets. The main elements of the method are: i) underlying component concepts; ii) modeling techniques and notations; iii) a strategy, techniques and tasks that guide the process. These elements constitute the way of thinking, the way of modeling and the way of working of the method respectively. 8.1.2.1 Research Question One Our first research question was concerned with defining the conceptual foundation of the method in the form of its way of thinking. The research question was formulated as follows: How can a technology-independent and coherent set of component concepts be defined to address different aspects of components throughout the development process? We answered this research question in chapter four of the thesis. So far, a number of definitions of a component and related concepts have been proposed, addressing different views on componentization in system development. For a long time, components have been defined mainly as packages of software code, e.g. COM components, DLL files and user interface controls, that can be deployed independently on computing network nodes, or, since recently, as business classes and objects that correspond to existing business entities, e.g. Customer and Order, during system analysis and design. We proposed a coherent set of general, technology-independent component concepts as a conceptual foundation of our method. These concepts can be applied equally well in various contexts, from business domain components that enable modularization and plug-and-play of main functionality within a business domain, to business components that unite business and system architectural concerns, and to application and implementation components related to details of software development.

216

Epilogue The main elements of any component were defined as a component context, i.e. the environment of a component, a component contract, i.e. component responsibilities and functionality exposed as a contract to its context, and a component content, i.e. internal realization of the contract, not visible from the context. These are the main properties of a component as an encapsulated, black-box unit with hidden interior and exposed interfaces. The notions of composition and decomposition were defined as the main principles behind the concept of component. Every component can be composed together with other components to form a higher-level component, and, at the same time every component can be decomposed into lower-level components that realize internally certain parts of its responsibilities. For the purpose of a detailed and precise representation of the contract that a component exposes, we extended the standard notion of component interface beyond a simple list of operation signatures to include all the necessary information for a component consumer to use it without knowing its interior. We defined the full specification of a component contract from four viewpoints: context, behavior, information and realization, each of them related to a particular set of concerns in defining components. The component properties that we emphasized in specifying components show clearly that our components are behavior-driven and service-based units of cohesive functionality. A component, as we defined it, still unifies data and behavior as in the case of classes/objects in object-orientation (OO) but in a different manner. While an object represents a real-world entity, the data about that entity and the methods operating on that data, a component is first determined by the functionality and services it offers, and, then, data handled by these services is defined as a part of a component specification. The component way of thinking we proposed does not exclude the OO viewpoint as widely adopted by the IT community, but rather implements another layer of abstraction above it that is closer to how business considers its business processes automated by software applications. We placed the concept of component in the context of the whole development process, by defining different component facets and properties a component can have during the process. These facets can be considered as phases in the lifecycle of component, from creation to deployment, namely component conceptualization, component specification, component implementation and component deployment. First, a component is founded conceptually in a computing-independent manner based on needs for particular responsibilities and behavior to be fulfilled. After deciding that this business functionality needs to be automated, the component is clearly and precisely specified using modeling and specification techniques in an implementation- and platform-independent way. The component specification can be implemented in a number of ways using various implementation languages and tools, or it can be built by encapsulating legacy assets or by using COTS components. Finally, the component implementation can be deployed on a single or several computing resources connected by the network depending on particular technology and business requirements.

217

Chapter 8 When placing components in the context of the whole development lifecycle, from business to implementation, it is essential to understand and define particular levels of component granularity. The granularity of a component and its services refers commonly to the level of abstraction at which a component is defined and, to a less extent, to its size. We defined different types of components having different granularity, all of them sharing the common and cohesive set of component concepts defined, but each of them having particular properties that correspond to their roles in a development process. The principle of recursive composition was applied among the component types in a way that a component at one granularity level can participate in a composition with components of the same level to form a component at a higher level, and, at the same time, can be decomposed into components that belong to a lower granularity level. We defined the following types of components regarding their granularity, i.e. the level of abstraction they are defined at: enterprise components, business components, application components and program components. The focus of our method is on business components. Business components encapsulate significant and cohesive set of business services defined at a granularity that fulfils business goals and applies business rules. Each service operation that a component offers should be understandable to the members of the business domain community, and not just to the IT staff. In contrast to the standard objectoriented development strategy and to most of component-based development methods, our business components, as the key abstractions of the system architecture, are not created to match closely underlying business entities, such as Customer, Order, Account, and, in this way, encapsulate related fine-grained behavior. Business components within our method are defined as holistic units that manage operations across a set of business entities and provide services that add value to business, i.e. that are meaningful and recognizable in the context of the business domain. Business components are rather conceptual units that reflect business requirements, concepts, goals and rules. When considering a realization of a business component in a software system, it can be decomposed into a number of application components that fulfill the parts of business component responsibilities, such as handling bidirectional communication with the component consumer, management of access to necessary data from permanent data storage or from other components, coordination of activities of application components inside the business component, management of business rules allocated to the business component, management of event subscription and notification, logic of the business components representing allocated entities, control logic, calculations, data transformations, etc. Application components can be often easily and straightforwardly mapped to the implementation constructs of a component implementation middleware such as J2EE or .NET. Business components as defined here are well suited to represent services organized in a framework of service-oriented architecture and realized normally using Web services protocols and standards. Using business component concepts in modeling and designing Web services ensures that we do not end up building a non-coherent and difficult-to-manage set of technically feasible but logically useless services. Business components represent a layer of 218

Epilogue abstraction between business and technology concerns, in a way that an organization requires services to support its business processes, the services are organized and provided by business components of the system, which are realized internally using application components and implemented later using implementation components. 8.1.2.2 Research Question Two Our second research question was concerned with determining the modeling techniques and notations for representing the defined component concepts, which forms the way of modeling of the method. The research question was formulated as follows: What modeling techniques and notations can be used to represent and specify the component concepts in a clear and understandable way for all stakeholders involved in the development project? We answered this research question in chapter five. Since the main role of creating models is to provide better communication and understanding across the project among all the stakeholders involved, utilizing a widely-used and wellunderstood modeling notation is of great importance. Therefore, we did not want to invent yet another modeling notation, which would be potentially used just in our method. Instead, we decided to use UML as the standard object-oriented modeling language and adapt it, when necessary, to our purposes. Our method was originally based on UML 1.3, which does not provide sufficient support for modeling components beyond the implementation and deployment level. To overcome this, we used the extension mechanisms of UML, such as stereotypes and tagged values, defined on existing modeling constructs: classes, subsystems, collaborations, interfaces, etc., to represent our component concepts. The new major revision of UML, version 2.0, has recently become proposed, but not yet finalized. It provides much better support for modeling software architecture, both logical and physical components, activities and state transitions. Therefore, we based our modeling notation on this new standard. The need for introducing extensions to the UML 2.0 notation is much lower than when using UML 1.3. Although a graphical modeling language, such as UML, is used increasingly in software development projects, there are still many projects and development teams that are more focused to producing software code as the main result, without spending too much time on modeling and design. For the purpose of such projects we proposed an alternative graphical modeling in the form of Component Responsibility Collaborator (CoRC) cards that enable high-level, lightweight modeling of basic components of the system and their collaborations to provide a clear and precise representation of the logical system architecture prior to starting with software implementation. It is often necessary to provide a modeling notation that is textual, more precise and closer to the way modeled constructs are implemented, but to be still independent of the implementation language. To cover this we proposed to use the new version of the popular Interface Definition Language, version 3.0, an ISO standard defined by the Object 219

Chapter 8 Management Group (OMG) for the CORBA Component Model (Siegel, 2000). To represent our component concepts precisely, we extended the IDL with the constructs given in the Object Constraint Language (OCL) and the Object Definition Language (ODL). The OCL elements enabled us to define the behavior of a component in a more precise and detailed way using pre-conditions, post-conditions, invariants and coordination conditions among provided and required interfaces, and published and consumed events. Particular constructs from ODL provided us with the notation to represent complex information types handled by the component and state transitions of instances of those types that occur in run-time caused by the component’s provided and used operations. Finally, to specify components exposed as Web services, we proposed a way to enrich the existing XML-based specification language, namely the Web Services Description Language (WSDL), to represent syntax information about a Web service in the form of its operation signatures, and more semantical information about the Web service behavior using preconditions, post-conditions, invariants and coordination conditions. It is obvious that current versions of IDL and WSDL lack the specifications of these elements, which is a consequence of a restricted, mainly syntactical and technology-oriented view on components and services. Other Web service specification languages, such as WSCI and BPEL4WS, need to be used to specify service composition and choreography. This is outside the scope of this research and is suggested as a subject for future research. 8.1.2.3 Research Question Three Our third research question was concerned with the way of working of the method in terms of a number of milestones and the pragmatic guidelines that facilitate the stepwise design and development of a number of related models and specifications. The research question was formulated as follows: How can the procedures, techniques, steps and rules of a method be defined to guide the development process, from business requirements to software implementation, using the defined component concepts and modeling techniques and notations? We answered this research question in chapter six. We designed a stepwise approach for engineering component-based and service-oriented system that was based strongly on the previously defined component concepts and UMLbased component modeling notation. The main steps in following the method during the development process are related to the creation of the four architectural models, namely the Business Domain Model (BDM), the Business Component Model (BCM), the Application Component Model (ACM) and the Implementation Component Model (ICM). Each model is focused on identifying and specifying components and their collaboration within the architecture at the corresponding level of abstraction. In creating the models, we used, to some extent, the Reference Model of Open Distributed Processing (RM-ODP) and its viewpoints as an underlying idea. Furthermore, our four models map well to the type of the models defined in the MDA framework, so that BDM represents a computational-independent business model, 220

Epilogue BCM and ACM are two levels of a platform-independent model, while ICM represents a platform-specific model that uses the implementation elements of a particular platform. Although we proposed the set of steps to be taken to build a system based on requirements, and although the method naturally moves from business to implementation, the iterative and incremental nature of the method needs to be emphasized. A complete system design, that is ready for implementation, is produced through a number of iterations and small increments. Using this strategy, we ensure that the complete picture of the system being developed is available early in the lifecycle, and further throughout, to provide the main functionalities to be tested and evaluated against the set of business requirements. Each new iteration cycle adds more functionality to particular components and refines the interfaces among them, unless the complete system has been built. We designed the method to fit into a development-for-reuse process, i.e. construction of components that can be reused in the future, and a development-with-reuse process, i.e. construction of the system by (re)using already available components. In relation to this, our method combines a top-down and a bottom-up approach to system development. While identification and definition of business components are performed primarily in a top-down fashion, to reflect as closely as possible business goals and needs, the existence of legacy assets or the intention to use COTS components or Web services must be taken into account even during the early phases of the development lifecycle, and not just at the implementation and deployment level. This strategy provides a balanced approach between capturing business requirements and strategies into the system architecture and the software packages and services that need to be used on the other side. The possibility for using already existing software components in the form of Web services, legacy assets or COTS components is taken into consideration inside each of the four component models we defined, which can result in successive refinements of the initial design. Identifying the set of components that provide services to support business processes and goals is not a trivial task (Endrei et al., 2004; Kaye, 2003). A pragmatic strategy is needed to uncover the business-aligned services, their dependencies and the business components that support them. We proposed an approach for identifying large-grained business components based on the set of business and technical criteria derived from top-down and bottom-up issues. Business components are identified based on business requirements, in the form of business goals, processes, entities and rules that need to be supported by the system. At the same time, this initial component design is confronted with the available software assets that are planned to be utilized in the project, e.g. legacy applications, COTS components or Web services, and with certain technical constraints and requirements such as a distribution of the system, using particular technology infrastructure, and the need to conduct “development for reuse” in terms of building more general, ease- to-reuse components.

221

Chapter 8 After defining the business components, we provided a way to decompose each business component into a number of application components that fulfill the parts of business component responsibilities in a standard 3-tier framework of interface tier, logic tier and data tier. Besides application components placed in each of these tiers, a business component can also encapsulate the application components responsible for coordination among components within the business component, for event management in terms of publishing and consuming events related to the business component, and for handling business rules and the ways they are supported within the business component. We proposed a clear and straightforward mapping of the defined types of application components and the implementation constructs of the J2EE platform, providing a platform-specific model of the component architecture that can be easily mapped to the software code of that platform. The same “platform-independent to platform-specific” mapping can be easily defined for other implementation platforms, such as Microsoft .NET. This is left for future research. Finally, we proposed a strategy called component refactoring for the purpose of creating the proper component architecture in terms of low coupling and high cohesion of its parts and non-redundant data and behavior. We define this strategy using the analogue to code refactoring that represents a coding practice in which the software code is changed to keep a design as simple as possible, while the semantics of the code are preserved. To assist us in component refactoring, we proposed a technique called a 9-interaction matrix, where each component is abstracted using its basic parts, namely its content, contract and context. The component refactoring can be applied at the levels of the Business Component Model and Application Component Model. 8.1.3 Reflection on the Research Approach The research approach we used consisted of a research philosophy, a research strategy, and research instruments, described in section 1.3 of the thesis. Our research philosophy followed a pluralistic view on science that combines interpretivism and positivism, the strengths and perspectives of both philosophies and related research instruments were used in various aspects of the research. The steps in the inductive-hypothetical model cycle, which we chose as our research strategy, provided a firm guidance for our research. The inductive-hypothetical model cycle enabled us to focus on the research questions, it directed us to investigate theoretical and practical issues, and it helped us to distinguish between descriptive and prescriptive aspects. The research strategy corresponded nicely with the objective of the research approach that focused on theory building with a practical value, in a general, applicable and understandable way. The inductive-hypothetical research strategy fitted well in the context of this research which was characterized by the fact that the fields of ComponentBased Development, Web services and Model-Driven Architecture have only recently emerged and are still evolving, so that a well-grounded and solid theory is not yet available. Therefore, it was necessary to identify inductively and to explore further the requirements for

222

Epilogue our component-based design and development method in reality, to combine these requirements with the available theory in the field and to develop our theory accordingly. We applied various research instruments within the three main phases of the inductive research study. We started with a review of existing literature, also called as meta-analysis, to get the initial starting points for our research. Parallel to this, subjective/argumentative conceptual research was performed that made a valuable contribution to the building of our theory and the creation of new ideas and insights. Drawing on the literature research and argumentative conceptual research, we decided to gain a deeper understanding of the problem domain and better identify shortcomings of the previously proposed solutions using an inductive case study of building an airport business suite. The case study had the characteristics of action research, since, besides observing, we participated actively in the project and got involved in theory application, prototype implementation and testing. After the theory was built, in addition to the test case study, a literature comparison was done to find more support for our findings. Parallel to that, surveys were carried out among experts in the field on a quantitative and qualitative basis. These surveys were used to gather written and verbal data from the potential users to help us to evaluate the level of their satisfaction with the component-based and service-oriented design and development method proposed in this research.

8.2 Further Research The fields of component-based development, Web services, service-oriented architecture, model-driven architecture and standard modeling languages are inherently complex and developing continuously. Therefore, the work presented here can be continued in a number of ways to stay abreast of current developments. First, the method can be applied to many other case studies and industrial applications and improved accordingly. This would provide a means to disseminate our work and to collect valuable feedback that can be used to fine-tune the method. The scope of the method as presented in this work can be further extended to cover computational-independent business process modeling in a component-based manner, and to include particular guidelines for software coding, deployment, test and maintenance. For the later purpose, some parts of already existing methods that include those activities in more detail, such as the Rational Unified Process (RUP), can be integrated into our method and possibly refined to make the integration seamless. For a method to be applied effectively in practice, it is important for it to be supported by a tool. During the last years, a number of tools have been created to support analysis, design and implementation of software systems based on UML, MDA and related modeling principles and notations. Since our method uses UML 2.0 as a modeling notation, any tool that supports this notation can support our method to a sufficient extent. Therefore, it was not necessary to invent a new tool. Instead, we can focus on using existing tools, such as Gentleware’s Posedion (www.gentleware.com), Objecteering/UML (www.objecteering.com) and Enterprise 223

Chapter 8 Architect from Sparx Systems (http://www.sparxsystems.com.au), and define extensions to available modeling elements where necessary. Some of these tools, such as Objecteering/UML, provide mechanisms that enable a user to create complete UML profiles to fit their particular purposes. Further exploration to find the most appropriate tool to use to support our method, and possible customization and extension of that tool to fulfill the detailed method requirements, are an important area for further research. The research objective can be stated as follows. ♦ To design and develop a tool for supporting the method based on an already existing tool that best fits the method’s requirements and customize it further using the extensibility and profiling mechanisms of the tool. Our method currently provides concepts, principles, techniques and guidelines related to the development process, while the support for the management process in terms of managing people, resources, roles, and tasks is still limited. Therefore, one of the directions for further research would be to define the way of controlling of the method, i.e. to provide a management process support in greater detail. Again, the idea would be to adopt certain elements of already available methods, such as RUP and PRINCE2, responsible for supporting the management process, and adapt them to fit into the component-based and service-oriented nature of our method. The research objective related to this topic can be defined as follows: ♦ To design a management process that together with the proposed method constitutes a complete methodology framework for guiding development and management process when building complex software systems. The scope and objectives of our method are, to a certain extent, similar and well-aligned to the main Model-Driven Architecture (MDA) concepts and principles. Further efforts are needed to make our method capable of fully supporting MDA. This can be achieved by defining precisely the transformations between the models that we define when applying our method, namely Business Domain Model, Business Component Model, Application Component Model and Implementation Component Model. The component concepts defined by the method should represent the point of consistency among the models and provide a basis for defining model transformations based on composition/decomposition of components at different levels of abstraction. For example, a business process is supported by one or many business components, each of them realized by one or many application components, and each of them implemented by one or many program components, that are further coded using a component middleware, such as .NET, CORBA or J2EE. According to the MDA initiative, model transformations and code generation should preferably be supported by a tool. Currently, there are several tools available on the market that claim to support MDA, such as ArcStyler from Interactive Objects (http://www.io-software.com) and Compuware’s OptimalJ (http://www.compuware.com). Further efforts might be focused on using one of the above

224

Epilogue tools as a basis, and then customizing the available model transformation mechanisms, such as cartridges in ArcStyler and patterns in OptimalJ, to support the peculiarities of our component models and efficient transformations among them resulting in code generation. The research objective related to this topic can be formulated as follows. ♦ To integrate fully our method into the Model-Driven Architecture framework in a way to provide automated model transformations and code generation based on the designed component concepts and architectural models. For a development method to be practical and usable in the context of agile business, some limitations of the MDA approach must be taken into account. This is especially related to the assumption that business requirements are fixed and well-defined before the design starts, which is rarely the case in current software development practices (Ambler, 2002). Therefore, an effective CBD method needs to incorporate certain agile development concepts, principles and practice, making an effective combination between the two to achieve the goals of an adaptable process and solution, and high-quality and on-time development products that closely reflect evolving business goals and needs (Stojanović, Dahanayake, and Sol, 2003a). Furthermore, component concepts can potentially provide a balance between model-driven and agile strategies of development and help to overcome certain limitations of agile development processes, see (Stojanović, Dahanayake and Sol, 2004b). The research objective related to this topic can be defined as follows. ♦ To equip the method with elements, techniques and strategies from both model-driven and agile development to make it flexible and adaptable to a variety of projects, from more agile, code-focused projects to more disciplined and traditional, model-driven projects. Although our method supports the modeling, design and implementation of components that are exposed as Web services, further efforts are necessary to provide methodology support for the complex computing framework of the Service-Oriented Architecture (SOA) that unites the business model with the applications that provide the desired functionality. SOA incorporates modular reusable business services that have clearly defined and standardized interfaces, thereby maximizing reuse and enabling business agility, i.e. the ability to respond quickly and efficiently to change and to leverage change for competitive advantage (Kaye, 2003). With regard to support for SOA modeling and design, it is important to provide mechanisms for specifying the orchestration of business services that form a high-level business process, at the level of abstraction above XML-based specification languages, such as BPEL4WS (BPEL, 2004). To do this, the method needs to be extended with necessary concepts to represent business services, processes and their orchestration, a modeling notation to model these concepts, e.g. UML 2.0 Activity Diagram or Business Process Modeling Notation (BPMN) (www.bpmi.org) and transformation rules in the spirit of MDA to map a high-level business

225

Chapter 8 service model into the models of business components that provide those services and further to the application and implementation component models. The research objective related to this topic can be defined as follows. ♦ To extend the method with the necessary concepts, notation, guidelines and techniques to represent business processes, their orchestration and automation using Web services and Web service orchestration engines, and the mappings of these business models into the defined system models in an MDA fashion. From this point of view, we expect that further development and initiatives in the field of information systems development will be concentrated on combining and integrating of SOA and MDA efforts in terms of creating high-level service-based business models, defining transformations to the lower-level component-based system models and realizing them using component middleware technology and Web services standards and protocols. We truly believe that our method is well equipped to address successfully the challenges to come and to keep pace with the new developments.

226

References Aalst, van der W.M.P. (2003). Challenges in Business Process Management: Verification of business processes using Petri nets. Bulletin of the EATCS 80, pp. 174-198. Agile Alliance (2001). Manifesto for Agile Software Development. Available at http://www.agilealliance.org Allen, P. (2000). Realizing eBusiness with Components. Addison-Wesley. Allen, P. and Frost, S. (1998). Component-Based Development for Enterprise Systems: Applying the Select Perspective. Cambridge University Press. Alur, D., Crupi, J., and Malks, D. (2001). Core J2EE Patterns: Best Practices and Design Strategies. Upper Saddle River, New Jersey: Prentice Hall. Ambler, S. (2002). Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. John Wiley & Sons, Inc., New York. Ambler, S. and McGibbon, B. (2001). The Object Primer – 2nd edition. Cambridge University Press. Andersen Consulting (1998) (now Accenture). Understanding Components. White paper Eagle project. [online]. Available at http://www.accenture.com ANSI (2000). ANSI/IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Product No.: SH94869-TBR: [online]. Available at http://shop.ieee.org/store/. Apperly, H. et al. (2003). Service- and Component-Based Development: Using the Select Perspective and UML. Addison-Wesley. Arkin et al. (2002) Web Services Choreography Interface, version 1.0, [online]. Available at http://wwws.sun.com/software/xml/developers/wsci/ Armour, F. and Miller, G.(2001). Advanced Use Case Modeling. Addison-Wesley. Atkinson, C., et al. (2002). Component-Based Product Line Engineering with UML. AddisonWesley. Barn, B. (2004). From Components to Web Services. Tutorial at the 6th International Conference on Enterprise Information Systems (ICEIS) 2004. Porto, Portugal. Batory, D., and Geraci, B. J. (1996). Validating Component Composition in Software System Generators. Proceedings of the Fourth International Conference on Software Reuse, IEEE Computer Society Press, April. 227

References Beck, K. (2000). Extreme Programming Explained – Embrace Change. Reading, MA: Addison-Wesley Longman. Berry, D., (2003). Web Services and Service-Oriented Architectures: The Savvy Manager’s Guide. Morgan Kaufmann. Bjorkander, M. and Kobryn, C. (2003). Architecting Systems with UML 2.0. IEEE Software, July/August, pp. 57-61. Boertien, N., Steen, M. and Jonkers, H. (2004), Evaluation of component-based development methods. in J. Krogstie, T. Halpin and K. Siau (eds.), Information Modeling Methods and Methodologies IDEA Group Publishing. Hershey, PA, USA. Booch, G. (1986), Object-oriented development, IEEE Transactions on Software Engineering 12(2). pp. 211-221. Booch, G. (1987). Software Components with Ada. Benjamin-Cummings. Booch, G. (2002). The Limits of Software. http://www.sdforum.org

[online]. Presentation available at

Booch, G., Rumbaugh, J. and Jacobson, I. (1999). The unified modeling language user guide. Addisson-Wesley. Bosch, J. (1999). Component Evolution in Product-Line Architecture. Proc. Int. Workshop on Component-Based Software Engineering, Los Angeles, CA. BPEL (2003). Business Process Execution Language for Web Services: Version 1.1 [online]. Available at http://www-106.ibm.com/developerworks/library/ws-bpel BPMI (2003). Business Process Modeling Notation, version 1.0. The Business Process Management Initiative. [online]. Available at http://www.bpmi.org Brooks, F. (1975). The Mythical Man-Month: Essays on Software Engineering, AddisonWesley Pub Co; 1st edition. Brown, A.W. (2000). Large-Scale Component-Based Development. Prentice-Hall PTR. Brown, A.W. and Wallnau, K.C. (1998). The Current State of Component-Based Software Engineering. IEEE Software. September/October 1998. Butler Group (2003). Application Development Strategies. Butler Group Report. November 2003. Carey, J. and Carlson, B. (2001). Business Components. In Heineman, T. and Councill, W. (Eds.) Component-Based Software Engineering: Putting the Pieces Together. AddisonWesley. pp. 285-305. Carey, J., Carlson, B. and Graser, T. (2000). SanFrancisco design patterns: blueprints for business software. Addison-Wesley. Cattell, R.G.G. and Barry, D. (Eds.) (2000). The Object Data Standard: ODMG 3.0. San Francisco: Morgan Kaufmann. Checkland, P. (1981). System Thinking, System Practice. Wiley, Chichester. 228

References Cheesman, J. and Daniels, J. (2000) UML Components: A Simple Process for Specifying Component-Based Software. Boston, MA: Addison-Wesley. Clarke, R. (2000). Appropriate Research Methods for Electronic Commerce, Xamax Consultancy Pty Ltd, Canberra, Australia. [online]. Available at http:///www.anu.edu.au/Roger.Clarke/EC/ResMeth.html Clements, P. D., and Northrop, L. M. (1996). Software Architecture: An Executive Overview, Technical Report CMU/SEI-96-TR-003. Software Engineering Institute, Carnegie Mellon University. Clements, P.C. (Ed.) (2000). Constructing Superior Software. MacMillan Technical Publishing. Indianapolis. CMS (2003) Centers for Medicare and Medicaid Services. CMS Architecture. Documents available at http://www.cms.hhs.gov/it/ Cockburn, A. (2001) Writing Effective Use Cases. Addison-Wesley, Boston MA. Cockburn, A. (2002) Agile Software Development. Addison-Wesley, Boston MA. Coleman, D., Arnold, P., Bodoff, S, Dollin, C., Gilchrist, H., Hayes, F. and Jeremaes, P. (1993). Object-Oriented Development: The Fusion Method. Prentice Hall. Computer Associates (2003). http://www.ca.com/products/

Advantage

tools.

Information

available

at

Compuware (2004). Service-Oriented Architecture and OptimalJ. White paper. Compuware Corporation [online]. Available at http://www.compuware.com/products/optimalj/ Conrad, S. and Turowski, K. (2003). Specification of Business Components Using Temporal OCL. In L. Favre (ed.) UML and the Unified Process. IDEA Group Publishing, Hershey PA, pp. 48-65. Cook S. & Daniels J. (1994). Designing Object Systems: Object-Oriented Modelling with Syntropy. Englewood Cliffs, N.J.: Prentice Hall. Crnkovic, I. and Larsson, M. (2000). A Case Study: Demands on Component-Based Development. Proceedings of the 22nd International Conference on Software Engineering, Limerick, Ireland, ACM Press. Crnkovic, I. and Larsson, M. (Eds.) (2002). Building Reliable Component-Based Software Systems. Artech House, Inc. CSC (1995). Catalyst Methodology (Internal Document) Computer Sciences Corporation. D’Souza D.F. and Willis A.C. (1999). Objects, Components, and Frameworks with UML: the Catalysis Approach. Addison-Wesley. Dahanayake, A., Sol, H. and Stojanović, Z. (2003). Methodology Evaluation Framework for Component-Based System Development. Journal of Database Management (JDM) Vol. 14, No.1 January-March 2003.

229

References Dahl, O.-J., Myhrhaug, B. and Nygaard K. (1968). SIMULA 67 Common Base Language. Norwegian Computing Center. DAML (2004). OWL-S: Semantic Markup for Web Services. Version 1.1 [online] Available at http://www.daml.org/services/ Digre, T. (1998). Business Object Component Architecture. IEEE Software 15(5), September/October, pp. 60-69. DSDM (2003, September 1) Dynamic Systems Development Modeling Consortium, [online]. Information available at http://www.dsdm.org Eeles, P. and Sims, O. (1998). Building Business Objects. John Wiley & Sons, Inc. Egenhofer, M. and Franzosa R. (1991). Point-set topological spatial relations. International Journal of Geographical Information Systems 5(2). pp. 161-174. Endrei, M., Ang, J., Arsanjani, A., Chua, S. Comte, P., Krogdahl, P., Luo, M. and Newling, T. (2004) Patterns: Service-oriented Architecture and Web Services. IBM Redbook. [online] Available at http://www.redbooks.ibm.com/redbooks/ Eriksson, H.-E. and Penker, M. (2000). Business Modeling with UML: business patterns at work. Wiley. 1st edition. Extreme Modeling (2003, September http://www.extrememodeling.org

10).

[online].

Information

available

at

FAA (2003) Integrated Noise Model, Version 6.1, Noise Division, AEE-100, [online]. Available at http://www.aee.faa.gov/noise/inm/INM6.1.htm Fayad M.E., Schmidt D.C. and Johnson R.E. (1999). Building Application Frameworks. Wiley Computer Publishing, John Wiley & Sons, Inc. Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. PhD Thesis. University of California Irvine. Fingar, P., Kumar, H. and Sharma, T., (2000). Enterprise E-Commerce. Meghan Kiffer Pr. Fischer, G. (1994). Domain-Oriented Design Environment. In Johnson, L., and Finkelstein, A. (Eds.) Automated Software Engineering. Kluwer Academic Publishers, Vol. 1, No. 2, June 1994. Fowler, M. and Scott, K. (1999). UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Professional. Frankel, D. (2003). Model driven architecture: applying MDA to enterprise computing. Indianapolis: John Wiley & Sons. Galliers, R.D. (Ed.) (1992). Information Systems Research: issues, methods and practical guidelines. Alfred Waller, Fawley, England. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley.

230

References Gardner, T. (2003). UML Modelling of Automated Business Processes with a Mapping to BPEL4WS. European Conference on Object-Oriented Programming ECOOP. Darmstadt, Germany. Garlan, D., and Perry, D. E. (1995). Introduction to the Special Issue on Software Architecture. IEEE Transactions on Software Engineering, 21 (4): 269–74, April 1995. Garlan, D., Monroe, R. T., and Wile, D. (2000). Acme: Architectural Description of Component-Based Systems. In Leavens, G.T. and Sitaraman, M. (Eds.) Foundations of Component-Based Systems. Cambridge University Press, pp. 47-68. Gartner Group (1998). Componentware: Categorization and Cataloging. Applications Development and Management Strategies Research Note, by K. Loureiro and M. Blechar, available at http://www.gartnergroup.com. Graham, I., Henderson-Sellers, B. & Younessi, H. (1997). OPEN Process Specification. Addison-Wesley. Gudgin, M., (2001). Essential IDL: Interface Design for COM, Reading, MA: AddisonWesley. Guest, S. (2003). Microsoft .NET and J2EE Interoperability Toolkit. Microsoft Press Ham, D.-H., Kim, J.-S., Cho, J.-H. and Ha, S.-J. (2004). MaRMI-III: A Methodology for Component-Based Development. ETRI Journal. Vol. 26, No. 2. pp. 167-180. Heineman, G.T. and Councill, W.T. (Eds.) (2001). Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley: Upper Saddle River, NHJ. Henderson-Sellers, B., Szyperski, C., Taivalsaari, A. and Wills, A. (1999). Are Components Objects? OOPSLA’99 - Panel Discussion. Herzum, P. and Sims, O. (2000) Business Component Factory: a Comprehensive Overview of Business Component Development for the Enterprise. John Wiley & Sons. Highsmith, J.A. III (2000). Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York, NY: Dorset House Publishing. Hirscheim (1992). Information Systems Epistemology: An Historical Perspective. In Galliers (1992), pp. 28-60. Hong, S., van den Goor, G. and Brinkkemper, S. (1993). A Formal Approach to the Comparison of Object Oriented Analysis and Design Methodologies. Hawaii International Conference on System Sciences (HICSS) 1993, Vol. IV, pp. 689-698. Houston, K. and Norris, D. (2001). Software Components and the UML. In Heineman, T. and Councill, W. Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley. pp. 243-262. IATA (1995), Airport Development Reference Manual - 8th Edition, Montreal-Geneva. IBM (2004). Component Business Modeling (CBM). IBM Business Consulting Services. Information available at http://www.ibm.com/bcs/ 231

References IBM Web Services (2003, http://www.ibm/com/webservices

September

10).

[online].

Available

at

Jackson, M. (1990). Some complexities in computer-based systems and their implications for system development. Proceedings of the International Conference on Computer Systems and Software Engineering. pp. 344-351. Jacobsen, H.-A. and Kramer, B.J. (2000). Modeling Interface Definition Language Extensions. TOOLS Pacific 2000, Sydney, pp. 242 – 252. Jacobson, I., Booch, G. and Rumbaugh, J. (1999). The Unified Software Development Process. Reading MA: Addison-Wesley. Jacobson, I., Christerson, M., Jonsson, P. and Overgaard, G. (1992). Object-Oriented Software Engineering – a Use Case-Driven Approach. Reading, MA: Addison-Wesley. Jain, H., Chalimeda, N., Ivaturi N. and Reddy, B. (2001). Business Component Identification – A Formal Approach. Proceedings of the fifth IEEE International Enterprise Distributed Object Computing Conference, Seattle, Washington USA, pp. 183-187. Jayaratna, N. (1994). Understanding and Evaluating Methodologies. McGraw-Hill Book Company. JSR (2003). Java Specification Request 26 UML Profile for EJB. Java Community Process. [online]. Available at http://www.jcp.org Kaye, D., (2003). Loosely Coupled: The Missing Pieces of Web Services. RDS Press. Kitchenham, B.A., Linkman, S.G. and Law, D.T. (1994). Critical Review of Quantitative Assesment. Software Engineering Journal. March 1994. pp. 43-53. Kleppe, A., Warmer, J. and Bast, W. (2003). MDA Explained: The Model Driven Architecture--Practice and Promise. Addison-Wesley. Kozaczynski, W. (1999). Composite Nature of Component. Proceedings of International Workshop on Component-Based Software Engineering. Los Angeles, CA, USA, May 1718. Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software. Vol. 12, No.6. November 1995. pp. 42-50. Kruchten, P. (2003). The Rational Unified Process: An Introduction. Third edition. AddisonWesley. Larman, C. (2001). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Second Edition. Prentice Hall. Levi, K. and Arsanjani, A. (2002). A Goal-driven Approach to Enterprise Component Identification and Specification. Communications of the ACM. Vol. 45, No.10, October 2002. Lewandowski, S. M. (1998). Frameworks for component-based client/server computing. ACM Computing Surveys, 30 (1), pp. 3-27. 232

References Longley, P.A., Goodchild, M.F., Maguire, D.J., and Rhind, D.W. (2002). Geographic information Systems and Science. John Wiley & Sons. Marks, E. and Werrell, M. (2003). Executive’s Guide to Web Services. John Wiley & Sons. McGovern, J. et al. (2003). Java 2 Enterprise Edition 1.4 Bible. John Wiley & Sons. McIlroy, M.D. (1968). Mass produced software components. Report NATO Conference on Software Engineering. (October 1968). Medvidovic, N., Rosenblum, D.S., Redmiles, D.F. and Robbins, J.E. (2002) Modeling Software Architectures in the Unified Modeling Language. ACM Transactions on Software Engineering and Methodology, Vol. 11, No 1, January, pp. 2-56. Meel, J.W. van (1994). The Dynamics of Business Engineering: Reflections on two case studies within the Amsterdam municipal police force. Doctoral dissertation. Delft University of Technology, The Netherlands. Meyer, B. (1994). Reusable Software: The Base Object-Oriented Component Libraries Prentice-Hall International. Meyer, B. (1997). Object-Oriented Software Construction. Upper Saddle River, NJ: Prentice Hall. Microsoft (1996): DCOM Technical Overview. Microsoft Corporation White Paper, November 1998. Microsoft (1998). An Introduction to Microsoft Transaction Server. Microsoft Corporation White Paper, January 1998. Microsoft .NET, (2004), .NET Framework. Microsoft corporation, [online]. Available at http://www.microsoft.com/net Middleware Research (2003). Model-Driven J2EE Development: Comparing Two Approaches and Tools. Research Report. [online]. Available at http://wwwmiddlewareresearch.com Miller, J. and Mukerji, J. (Eds.) (2003). MDA Guide Version 1.0.1. [online]. Available at http://www.omg.org/docs/omg/03-06-01.pdf Newcomer, E. (2002). Understanding Web services: XML, WSDL, SOAP and UDDI. Addison-Wesley. Nierstrasz O., Dami L. (1995). Component-Oriented Software Technology. In Nierstrasz, O. and Tsichritzis, D. (Eds.) Object-Oriented Software Composition. Prentice Hall, pp. 3-28. ODP (1996), International Standard Organization (ISO), Reference model of Open Distributed Processing: Overview, Foundation, Architecture and Architecture semantics, ISO/IEC JTC1/SC07, 10746-1 to 4, ITU-T Recommendations X.901 to 904. OGC (2001). Open Geospatial Consortium. The OpenGIS Service Architecture, version 4.3. Document 02-112 (same as ISO 19119) [online]. Available at http://www.opengis.org OGC (2004). OpenGIS Location Services (OpenLS). Core Services – part 1. Document 03006r3. Available at http://www.opengis.org 233

References Oldevik, J. (2004). UMT - UML Model Transformation Tool. Available at http://umtqvt.sourceforge.net OMG-CORBA (1999) Object Management Group: CORBA Components, [online]. Available at http://www.omg.org/corba/, filename orbos/99-02-05 OMG-MDA (2004). Model Driven Architecture, OMG (Object Management Group), Information available at http://www.omg.org/mda/ OMG-UML 1.3 (1999) Unified Modeling Language version 1.3, [online]. Available at http://www.omg.org/docs/formal/00-03-01.pdf OMG-UML2 (2004). Unified Modeling Language version 2.0, [online]. Available at http://www.uml.org OMG-UML4EDOC (2004). UML Profile for Enterprise Distributed Object Computing (EDOC), version 1.0, [online]. Available at http://www.uml.org/ Orfali, R., Harkey, D. and Edwards, J. (1996) The Essential Distributed Objects Survival Guide. John Wiley & Sons. Orlikowski, W.J. and Baroudi, J.J. (1991). Studying Information Technology in Organizations: Research Approaches and Assumptions. Information Systems Research 2, 1 (March 1991), pp. 1-28. Palmer, S.R. and Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. Parnas, D.L. (1972). On the criteria to be used in decomposing systems into modules. Communication of the ACM. 15 (12). pp. 1053-1058. Perry, D. E. (1989). The Inscape Environment. Proceedings of the 11th International Conference on Software Engineering, IEEE Computer Society Press, May 1989. Prieto-Diaz, R. and Neighbors, J. M. (1986). Module Interconnection Languages. Journal of Systems and Software, 6:307–334, 1986. Putman, J. (2001). Architecting with RM-ODP. Prentice Hall PTR Quartel, D., Dijkman, R. and van Sinderen, M. (2004). Methodological Support for Serviceoriented Design with ISDL. Proceedings of the Second International Conference on Service Oriented Computing. ACM, November 2004, pp. 1-10. RAND (2001). Flight Scheduling Model. Handbook, version 1.0, RA Europe, February 2001. Raymond, K., (1995). Reference Model of Open Distributed Processing: Introduction. Proceedings of the 3rd IFIP TC6/WG6.1 international Conference on Open Distributed Processing, Brisbane, Australia, pp 3-14. Roman, E. (2002). Mastering Enterprise Java Beans, second edition, John Wiley & Sons. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorenson, W. (1991). Object-Oriented Modeling and Design. Prentice Hall.

234

References Schach, S.R. (2004). An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process. The McGraw-Hill Companies. Schwaber, K. & Beedle, M. (2001). Agile Software Development with Scrum. Prentice Hall, New Jersey. SCOR (2003). Supply-Chain Operations Reference Model, version 6.0. Supply-Chain Council. [online]. Available at http://www.supplychain.org/SCORCD3/SCOR_6.0_OverviewBooklet.pdf Selic, B., Gullekson, G. and Ward, P.T. (1994) Real time object oriented modeling and design, John Wiley & Sons, New York. Sessions, R. (1998a). COM and DCOM. John Wiley Press. Sessions, R. (1998b). Component-Oriented Middleware. Component Strategies, October 1998. Sessions, R. (2000) COM+ and the Battle for the Middle Tier. John Wiley & Sons. Sessions, R. (2001). Java 2 Enterprise Edition (J2EE) versus the .NET Platform: Two Visions for eBusiness. Object Watch Inc., [online]. Available at http://www.objectwatch.com/FinalJ2EEandDotNet.doc Shaw, M. and Garlan, D. (1996). Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall. Siegel, J. (2000). CORBA 3: Fundamentals and Programming. OMG Press, John Wiley & Sons. Simon, H.A. (1973). The structure of ill-structured problems, Artificial Intelligence, 4, pp. 181-202. Sol, H.G. (1982). Simulation in Information Systems Development. Doctoral Dissertation. University of Groningen, The Netherlands. Sol, H.G. (1990). Information Systems Development: A Problem Solving Approach. In: Proceedings of the International Symposium on System Development Methodologies. Atlanta, Georgia. USA. Sommerville, I. (2000) Software Engineering. Sixth edition. Addison-Wesley. Sprott, D. and Wilkes, L. (1999). Component-Based Development: Using the Componentised Software. The Forum for Component-Based Development and Integration. May 1999. available at http://www.cbdiforum.com Stamatopoulos, M, Zagrofos, K. and Odoni, A., (2000) A Decision Support System for Airport Strategic Planning, Ph.D. dissertation, Department of Management Science and Marketing, Athens University of Economics and Business, Athens, Greece. Stojanović, Z. (2003). A Component-Based Development Approach. Technical Report. Geodan BV and Delft University of Technology, May 2003.

235

References Stojanović, Z. and Dahanayake, A. (2003). A Service-Based Approach to Components for Effective Business/IT Alignment. In Joan Peckham (Ed.) Practicing Software Engineering in the 21st Century, Idea Group Publishing, Hershey PA, USA, pp. 1-28. Stojanović, Z., Dahanayake, A. and Sol, H.G. (2001). Integration of Component-Based Concepts and RM-ODP Viewpoints. In the Proceedings of the 1st Workshop on Open Distributed Processing WOODPECKER 2001, Setubal, Portugal, July 6-7. Stojanović, Z., Dahanayake, A. and Sol, H.G. (2004a). An Evaluation Framework for Component-Based and Service-Oriented System Development Methodologies. In Keng Siau (Ed.) Advanced Topics in Database Research, Vol 3, Idea Group Publishing, Hershey PA, pp. 45-69. Stojanović, Z., Dahanayake, A. and Sol, H.G. (2004b). Agile Development Methods and Component-Orientation: Review and Analysis. In Keng Siau (Ed.). Advanced Topics in Database Research, Volume 3. Idea Group Inc., pp. 1-22. Stojanović, Z., Dahanayake, A. Sol, H.G. (2003a). Component-Oriented Agile Software Development. 4th International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP 2003), May 26-30. Lecture Notes in Computer Science, Springer-Verlag - Heidelberg, Volume 2675, 2003, pp. 315-318. Stojanović, Z., Dahanayake, A., Sol, H.G. (2003b). Modeling Services and Components in a Service-Oriented Architecture. In the Forum of 1st International Conference on ServiceOriented Computing, Technical report DIT-03-056, Aiello, M., Bussler, C., D'Andrea, V. and Yang J. (Eds.), pp. 1-16, December 15-18, University of Trento, Italy. Stojanović, Z., Djordjevic-Kajan, S. and Stojanović, D. (2000). Visual query and analysis tool of the object-relational GIS framework. Proceedings of the ninth International Conference on Information and Knowledge Management. McLean, Virginia, United States. pp. 328 – 335. Swedish, W.J., (1981). Upgraded FAA Airfield Capacity Model, Supplemental user’s Guide, Vol. I, Federal Aviation Administration, FAA-EM-81-1, February 1981. Szyperski C. (1998). Component Software: Beyond Object-Oriented Programming. ACM Press, Addison-Wesley. Teale, P. and Jarvis, R. (2004). Business Patterns for Software Engineering Use. Microsoft Architect Journal, July 2004. [online] Available at http://msdn.microsoft.com/architecture/journal/ TINA-C (1996), Service Architecture 4.0, Telecommunications Information Networking Architecture Consortium [online]. Available at: http://www.tinac.com TOGAF (2003) The Open Group Architecture Framework (TOGAF) – Enterprise edition, Version 8.1, [online]. Available at http://www.opengroup.org/architecture/togaf/ Tolvanen, J.-P. (1998). Incremental Method Engineering with Modeling Tools: Theoretical Principles and Empirical Evidence. PhD Thesis. University of Jyvaskyla, Finland. 236

References Turk, D., France, R. & Rumpe, B. (2002). Limitations of Agile Software Processes, Third International Conference on eXtreme Programming and Agile Processes in Software Engineering, Sardinia, Italy, pp. 43-46. Udell, J. (1994). Cover Story: Componentware. Byte Magazine. May 1994. UN-TMG (2003). The UN/CEFACT Unified Modelling Methodology (UMM) User guide. [online]. Available at http://www.unece.org Veryard (2001). Component-Based Business Plug and Play. Springer-Verlag. Visser, H.G., Chin, R., Wijnen, R.A.A., Walker, W.E., Keur, J., Kohse, U., Veldhuis, J. and de Haan, A.R.C., (2003) The Airport Business Suite: a Decision Support System for Airport Strategic Exploration. AIAA’s 3rd Annual Aviation Technology, Integration and Operations (ATIO) Technical Forum, Denver, Colorado, November 2003. Vogel, D.R. and Wetherbe J. (1984). MIS Research: A Profile of Leading Journals and Universities. Data Base, 16, 1, pp. 3-14. W3C (2004) World-Wide-Web Consortium: XML, SOAP, WSDL. [online]. Available at: http://www.w3c.org/ W3C-WS Glossary (2004), World-Wide-Web Consortium. Web Services Architecture Group Web Services Glossary [online]. Available at http://www.w3.org/TR/2004/NOTE-wsgloss-20040211/ W3C-WSDL (2004) World Wide Web Consortium, Web Services Description Langauge, version 1.2, [online]. Available at http://wwww/w3c.org/wsdl/ Walker, W.E., Lang, N.A., Keur, J., Visser, H.G., Wijnen, R.A.A., Kohse, U., Veldhuis, J., and de Haan, A.R.C., (2003) An Organizational Decision Support System for Airport Strategic Planning, 7th International Conference of the International Society for Decision Support Systems (ISDSS'03), Poland, July 13-16. Wallnau, K.C., Hissam, S.A. and Seacord, R.C. (2001). Half-day tutorial in methods of component-based software engineering: essential concepts and classroom experience. Proceedings of the 8th European software engineering conference and 9th ACM SIGSOFT international symposium on Foundations of software engineering. pp. 314-315. Walsham, G. (1993). Interpreting Information Systems in Organizations, Wiley, Chichester. Warmer, J. and Kleppe, A. (2004) The Object Constraint Language (second edition): Getting Your Models Ready for MDA. Addison-Wesley Professional. Welke, R.J. (1994). The Shifting Software Development Paradigm. Data Base, Vol. 25, No.4 (November, 1994), pp.9-16. Whitehead, K. (2002). Component-Based Development: Principles and Planning for Business Systems. Addison-Wesley. Wiederhold, G., Wegner, P. and Ceri, S. (1992). Toward Megaprogramming. Communications of the ACM, Vol 35, No 11, November 1992.

237

References Williams, J.D. (2000). Raising components. Application Development Trends, 7 (9), 27-32. Williams, S. and Kindel, C. (1994). The Component Object Model: A Technical Overview. Microsoft Corporation White Paper, October 1994. Wirfs-Brock, R., Wilkerson, B. and Wiener, L. (1990). Designing Object-Oriented Software. Prentice Hall. WSCI (2002). Web Service Choreography Interface. Version 1.0 [online]. Available at http://www.w3.org/TR/wsci/ Yin, R. (1994). Case Study Research: Design and Methods’ Sage. 2nd edition. Newbury Park, California, USA. Zachman, J.A. (1987). A Framework for Information Systems Architecture, IBM Systems Journal, 26 (3), pp. 276-292. Zahavi, R. (2000). Enterprise Application Integration with CORBA: Component and Web-Based Solutions. OMG Press, John Wiley & Sons, Inc. Zeichick, A (2004) UML Adoption Making Strong Progress. Software Development (SD) Times [online]. Available at http://sdtimes.com/news/108/story14.htm Zimmerman, O., Korgdahl, P. and Gee, C. (2004). Elements of Service-oriented Analysis and Design. IBM developerworks. June 4. [online] Available at http://www106.ibm.com/developerworks/webservices/

238

Appendix A UML 2.0 Modeling Notation This appendix presents the UML notation that is used to graphically represent componentrelated concepts that are of interest for our method. The diagrams are created using Enterprise Architect tool from Sparx Systems, as one of a few tools that currently (end of 2004) supports UML 2.0. Detailed information about the semantics and concrete notation for representing these and other elements of the UML specification can be found in UML 2.0 specification document (OMG-UML2, 2004). The document also presents examples that illustrate how the graphic elements can be assembled into diagrams.

Modeling concept

UML notation

on ClassName

Class

on «interface»

d Trial Versio InterfaceName

Interface InterfaceName

Component

Component implements Interface

d Trial Versio

ComponentName

«component» ComponentName

sion «component» ComponentName

sion Component has provided Port (typed by Interface)

«component» Version ComponentName

Component uses Interface

V

i

«component» Version ComponentName

Component has required Port (typed by Interface)

V

i «component»

ComponentName

239

Appendix A UML 2.0 Modeling Notation Modeling concept Component has complex Port (typed by provided and required Interfaces)

UML notation

«component» ComponentName

g

Realization «realize»

Dependency Use «use»

Assembly connector

g

Port PortName

Collaboration

Connector

Package

Artifact

CollaborationName

g PackageName

«artifact» ArtifactName

Node

NodeName

Node with deployed Artifact

NodeName «artifact» ArtifactName

240

Appendix B Survey Questionnaire The goal of this survey is to conduct the evaluation of the presented method for componentbased and service-oriented software systems engineering. The results of the survey will be used exclusively as a part of the research of Zoran Stojanović at Delft University of Technology. The survey will be held as a semi-structured interview. Beside presented questions and possible answers to choose from, you might be asked to explain the answers you have given. In this way, the researcher is able to get a better impression of the motivation for answering the question in the particular way. The survey will be conducted anonymously. Most of the questions are stated as propositions that can be answered on a scale, ranging from strongly disagree to strongly agree. The set of propositions related to the case study and the component-oriented method in general is given below. 1.

Participation in this case study was valuable for my organization. Strongly disagree

2.

Agree

Strongly agree

Disagree

Neutral

Agree

Strongly agree

The method showed the importance of model-based and architecture-driven development for communication and understanding among project members. Strongly disagree

4.

Neutral

The method showed the importance of following a development process in building a system. Strongly disagree

3.

Disagree

Disagree

Neutral

Agree

Strongly agree

The method showed the benefits of using the component concept throughout the whole development process. Strongly disagree

Disagree

Neutral

Agree

Strongly agree

241

Appendix B 5.

The method was shown to be simple. Strongly disagree

6.

Agree

Strongly agree

Disagree

Neutral

Agree

Strongly agree

The method was shown to be flexible. Strongly disagree

8.

Neutral

The method was shown to be practical. Strongly disagree

7.

Disagree

Disagree

Neutral

Agree

Strongly agree

The method was shown to be systematic. Strongly disagree

Disagree

Neutral

Agree

Strongly agree

The set of propositions related to the component concepts and modeling notation used in the case study is presented below. 1.

The component concept as a key technology-independent abstraction of the system architecture was clearly defined. Strongly disagree

2.

Neutral

Agree

Strongly agree

The composition and black-box characteristics of components were clear and understandable. Strongly disagree

242

Disagree

Disagree

Neutral

Agree

Strongly agree

Survey Questionnaire 3.

The representation of component in terms of its content, contract and context was clear and suitable for representing our domain components. Strongly disagree

4.

Disagree

Neutral

Agree

Strongly agree

Disagree

Neutral

Agree

Strongly agree

Disagree

Neutral

Agree

Strongly agree

Different facets of a component, namely specification, implementation and deployment, and their role in the development process were clear. Strongly disagree

8.

Strongly agree

Different granularity levels of components and their role in the development process were clear and illustrative. Strongly disagree

7.

Agree

The component specification defined from different viewpoints, i.e. context, behavior, information and realization, was complete and understandable. Strongly disagree

6.

Neutral

The definition of the component contract beyond the simple set of operation signatures was clear and well established. Strongly disagree

5.

Disagree

Disagree

Neutral

Agree

Strongly agree

The component modeling notation based on UML was clear and understandable. Strongly disagree

Disagree

Neutral

Agree

Strongly agree

243

Appendix B 9.

The presented component concept is suitable for representing services in a serviceoriented architecture. Strongly disagree

Disagree

Neutral

Agree

Strongly agree

The set of propositions related to the modeling and design steps, guidelines and techniques used in mapping the requirements into the software implementation during the case study is given below. 1.

The separation of concerns used in the method based on four architectural models was clear and logical. Strongly disagree

2.

Disagree

Neutral

Agree

Strongly agree

Disagree

Neutral

Agree

Strongly agree

Disagree

Neutral

Agree

Strongly agree

The role of business component architecture as a point of alignment between business and IT was clear and useful. Strongly disagree

244

Strongly agree

The role of business components in organizing requirements and translating them into the architecture was clear and appropriate. Strongly disagree

5.

Agree

Identifying business components based on combining top-down and bottom-up strategy was clear and suitable for our domain. Strongly disagree

4.

Neutral

The models included in the Business Component Model were clear and complete. Strongly disagree

3.

Disagree

Disagree

Neutral

Agree

Strongly agree

Survey Questionnaire

6.

Decomposition of business components into application components based on logical layers was clear and appropriate. Strongly disagree

7.

Agree

Strongly agree

Disagree

Neutral

Agree

Strongly agree

Modeling components using UML throughout the development process was clear and helped to provide better communication and understanding among stakeholders. Strongly disagree

9.

Neutral

The mapping of application components into implementation artifacts of the J2EE platform was clear and appropriate. Strongly disagree

8.

Disagree

Disagree

Neutral

Agree

Strongly agree

The concept of business components that support cohesive use cases/services was suitable for modeling Web services in our domain. Strongly disagree

Disagree

Neutral

Agree

Strongly agree

245

Appendix C List of Abbreviations ABS ACM ACM AD ADC ADL API ASE BCF BCM BDM BMP BOCA BPEL4WS BPM BPMI BPMN CBD CBM CCA CCM CDL CIDL CIM CMP COM CoRC COTS CRC CRUD CWM DAML DAO DCOM DES DLL DSDM ECM EDOC EJB ERD FAA FDD FDM GIS GUI HTML

Airport Business Suite Airside Capacity Model Application Component Model Agile Development Airport Development Center Architecture Description Language Application Programming Interface Airport Strategic Exploration Business Component Factory Business Component Model Business Domain Model Bean-Managed Persistence Business Object Component Architecture Business Process Execution Language for Web Services Business Process Modeling Business Process Management Initiative Business Process Modeling Notation Component-Based Development Component Business Modeling Component Collaboration Architecture CORBA Component Model Component Definition Language Component Implementation Definition Language Computation Independent Model Container-Managed Persistence Component Object Model Component-Responsibility-Coordinator Commercial-Off-The-Shelf Class-Responsibility-Collaborator Create, Read, Update, Delete Common Warehouse Metamodel DARPA Agent Markup Language Data Access Objects Distributed Component Object Model Decision Enhancement Services Dynamically Linked Library Dynamic Systems Development Method Environmental Capacity Model Enterprise Distributed Object Computing Enterprise Java Beans Entity-Relationship Diagrams Federal Aviation Administration Feature-Driven Development Frequency Demand Model Geographic Information System Graphical User Interface Hypertext Markup Language

247

Appendix C List of Abbreviations ICM IDL ISM ISO IT J2EE JDBC JMS JSP LCM MDA MDD MIDL MOF MSIL MTS MVC NIMSAD OCL ODL ODMG ODP OGC OMG OMT OO PDA PIM PSM QoS RAD RMI RM-ODP RUP SCOR SOA SOAP TINA TOGAF UDDI UDM UML UMM URI W3C WS WSCI WSDL XMI XML XP

248

Implementation Component Model Interface Definition Language Implementation Specific Model International Standard Organization Information Technology Java 2 Enterprise Edition Java Database Connectivity Java Message Service Java Server Page Landside Capacity Model Model-Driven Architecture Model-Driven Development Microsoft Interface Definition Language Meta Object Facility Microsoft Intermediate Language Microsoft Transaction Service Model-View-Controller Normative Information Model-based Systems Analysis and Design Object Constraint Language Object Definition Language Object Data Management Group Open Distributed Processing Open Geospatial Consortium Object Management Group Object Modeling Technique Object-Oriented Personal Digital Assistant Platform Independent Model Platform Specific Model Quality-of-Service Rapid Application Development Remote Method Invocation Reference Model for Open Distributed Processing Rational Unified Process Supply Chain Operations Reference Service-Oriented Architecture Simple Object Access Protocol Telecommunication Information Networking Architecture The Open Group Architecture Framework Universal Description Discovery and Integration Unrestricted Demand Model Unified Modeling Language Unified Modeling Methodology Uniform Resource Identifier World Wide Web Consortium Web Service Web Service Choreography Interface Web Services Description Language XML Metadata Interchange eXtensible Markup Language eXtreme Programming

Summary A Method for Component-Based and Service-Oriented Software Systems Engineering By Zoran Stojanović

Information technology (IT) and systems have become the backbone of modern enterprises providing a wealth of new opportunities for conducting business. The ability of an enterprise to manage the complexity of its information systems and rapidly adapt to business changes has been widely recognized as a crucial factor for business success. There is a growing consensus in the business/IT community that the way to create these complex and adaptive IT systems is to use components and services – discrete units of business functionality that collaborate over contract-based interfaces using standard protocols and platforms. During the last few years, a variety of component-based development (CBD) and Web services (WS) technology and standards have been proposed for building complex enterprise-scale systems and providing effective inter-enterprise application integration. While the technology and implementation standards for CBD and WS have already been established in practice, further efforts are necessary to design methods and techniques for engineering these complex systems. The first proposed CBD methods inherited difficulties in recognizing the fundamental nature of components as design structures and treated components as software code packages. The CBD methods of a new generation have recently started to define components as the representation and implementation of autonomous business units. However, business components are often identified based on underlying business objects and, therefore, they are too fine-grained and data-oriented to be used effectively in the design and development of complex, Web-based and service-oriented applications. To gain the full benefit of CBD and WS, the improvements in technology must be followed with a more formal and well-defined component-based and service-oriented design and development strategy. Therefore, the objective of this research was “to design a method for component-based and service-oriented software systems engineering that supports components and services during the whole system development lifecycle, from business requirements to implementation.” The research questions formulated to reach this objective were concerned with: ♦ the way of thinking of the method - a set of consistent, technology-independent component and service concepts; ♦ the way of modeling of the method- modeling techniques and notations to express these component and service concepts in an appropriate manner;

249

Summary ♦

the way of working of the method - a set of guidelines, rules and techniques to put the concepts and models into effect through a development process.

We applied an inductive-hypothetical research strategy that is suitable for supporting theory building in emerging research fields for which little theory is available. The strategy consists of the phases: initiation, abstraction, theory formulation, implementation and evaluation. We started our research with an extensive literature survey of the CBD and WS state-of-theart. We explored a number of methods and approaches for the design and development of CBD systems and identified their benefits, but also their shortcomings and drawbacks in supporting components and services during the development process. Based on the survey findings, we defined the set of requirements for a fully component-based and service-oriented design and development method, and evaluated existing methods against these requirements. An inductive case study about the design and development of an airport business suite, that supports airport strategy exploration, was conducted and is described in this thesis. The case study showed the wealth of CBD potentials and advantages in building complex systems within a short time-to-market, but also the shortcomings of the CBD approach used. The conclusions derived from the case study have supported our literature survey findings and justified the set of requirements defined in the thesis for a fully CBD and service-oriented design method. The next step of the inductive-hypothetical research cycle was to build our theory based on the findings and conclusions from the literature survey and the inductive case study. First, a set of consistent and technology-independent component concepts was defined as the way of thinking of the method. Instead of a single component definition, we introduced a set of essential component properties and their mutual relationships. Components were defined through the basic concepts, specification contract concepts, features, aspects, types, forms and granularity levels in the context of a development lifecycle. In defining the way of modeling of the method, instead of inventing new modeling techniques and notations, we explored how our component concepts could be expressed using the existing ones, such Unified Modeling Language (UML) for graphical modeling, Interface Definition Language (IDL) for human-understandable textual modeling and languages and standards based on eXtensible Markup Language (XML), for machine-readable modeling. We defined the mappings between the introduced component concepts and corresponding elements of these standard modeling notations, and proposed modifications and extensions, where necessary. The method further provides pragmatic guidelines, techniques and milestones that use the defined concepts and notations to facilitate a stepwise development process in a componentbased and service-oriented manner. The method prescribes which activities should be carried out within each step of the development process and provides guidelines to develop appropriate models at business, information, application and technology levels, following 250

Summary component-based principles and practices. The main artifacts created in following the method are four models that need to be created in the course of system development, namely business domain model (BDM), business component model (BCM), application component model (ACM), and implementation component model (ICM). Business components as the focus of the method are defined as process-oriented and use case-driven structures that provide business meaningful and perceivable functionality and, therefore, represent the right level of abstraction for representing pieces of a system that can be exposed as Web services. Our method provides clear traceability and alignment of business processes, in which the system participates, business components that provide services to automate and support these processes, application components realize the interior of these business components and program components actually implement the application and business components using a technology platform of choice. The usability of the method was tested by using it in the development process for building a location-based, geographic information application. Following a number of presentations and discussions with participants from the organization regarding the method and its applications, a survey was used to gather opinions and to conduct a users’ evaluation of the method. The participants were convinced of the great potential of the method, and they expected the method could be used within their organization in the future. We concluded our research by pointing to a number of possible directions for further research. First, the method can be applied to many other case studies and industrial applications and improved accordingly. The scope of the method can be extended to cover computationalindependent business process modeling in a component-oriented manner. The next research direction is to design and develop a tool to support the method based on customizing and extending an already existing tool that best fits our method’s requirements. Following this, another research objective would be to define a management process that, together with the proposed method, constitutes a complete methodology framework for guiding complex software systems development. Another possible research objective would be to integrate our method fully into the Model-Driven Architecture (MDA) framework in such a way as to provide automated model transformations and code generation based on the designed component concepts and architectural models. Due to the ever-changing business and technology environment, it is necessary to equip the method with elements, techniques and strategies from model-driven and agile development that will make it flexible and adaptable for a variety of projects, both traditional and agile. A final research objective would be to extend the method with the necessary concepts, notation, guidelines, rules and techniques to represent business processes, their orchestration and automation using Web services and service orchestration engines.

251

Samenvatting Een methode voor component-gebaseerde en service-georiënteerde software systeem engineering Door Zoran Stojanović

Informatietechnologie (IT) en systemen zijn de ruggengraat van de moderne ondernemingen en bieden vele mogelijkheden voor het uitvoeren van bedrijvigheid. Het managen en het snel kunnen aanpassen van informatiesystemen aan veranderende omstandigheden wordt in het algemeen beschouwd als een cruciale factor voor het succes van de onderneming. In de bedrijfskunde en informatica is men het er over eens dat de manier om complexe en adaptieve IT systemen te creëren door het gebruik van componenten en services, afzonderlijke eenheden van bedrijfsfunctionaliteit welke samenwerken met behulp van op contracten gebaseerde interfaces via gestandaardiseerde protocollen en platformen. Gedurende de afgelopen jaren is een breed scala aan op component-gebaseerde, (Component-Based Development - CBD) en Web services (WS) technologie en standaarden ontwikkeld voor het ontwerpen van deze complexe informatiesystemen en voor het integreren van systemen binnen ondernemingen. Op dit moment zijn de technologie en implementatie standaarden voor CBD en WS aanwezig voor gebruik in de praktijk, echter nader onderzoek is nodig naar ontwerpmethoden en technieken voor het ontwerpen en ontwikkelen van dit soort complexe systemen. Traditionele CBD methoden hebben problemen met het fundamentele karakter van componenten als ontwerpstructuren. Deze methoden gaan namelijk op een soortgelijke wijze met componenten om als met het schrijven van programma code. Meer recente CBD methoden beschouwen componenten als de representatie en implementatie van zelfstandige bedrijfsfunctionaliteit. Deze zogenaamde bedrijfscomponenten zijn veelal ongeschikt voor het ontwerpen van complexe, webgebaseerde en service georiënteerde applicaties, omdat de bedrijfscomponenten afgeleid worden van bedrijfsobjecten welke vaker te klein en georiënteerd op data zijn. Om te profiteren van de voordelen van CBD en WS, is een formeel en goed gedefinieerde component-gebaseerde en service-georiënteerde ontwerp- en ontwikkelingsstrategie nodig. Het doel van dit onderzoek is “het ontwikkelen van een component-gebaseerde en servicegeoriënteerde software systeemontwerpmethode die componenten en services gedurende het gehele ontwikkelingscyclus, van bedrijfseisen tot implementatie ondersteunt”. De onderzoeksvragen om dit geformuleerde doel te bereiken zijn gebaseerd op de volgende elementen: ♦ De denkwijze van de methode - het consistent en technologie onafhankelijk gebruik van de component-gebaseerde en service-georiënteerde concepten;

253

Samenvatting ♦ ♦

De modelleerwijze van de methode - het gebruik van modelleertechnieken en beschrijvingswijzen om de component en service concepten op een geschikte wijze uit te drukken; De werkwijze van de methode – ontwerprichtlijnen, regels en technieken welke gericht zijn op het ondersteunen van het gebruik van de concepten en modellen tijdens het ontwikkelingsproces.

Voor het uitvoeren van dit onderzoek is gebruik gemaakt van de inductief-hypothetische onderzoeksstrategie. Deze is met name geschikt voor het ontwikkelen van theorieën in gebieden waar geen of nauwelijks theorie beschikbaar is. De inductief-hypothetische strategie maakt gebruik van de volgende fasen: initiatie, abstractie, theorie ontwikkeling, implementatie en evaluatie. De eerste stap in dit onderzoek was een uitgebreid literatuuronderzoek naar CBD en WS. Een aantal methoden en benaderingen zijn onderzocht voor het ontwerpen en ontwikkelen van CBD systemen. Vervolgens zijn de voor- en nadelen van deze methoden geïdentificeerd. Een pakket van eisen voor een volledige CBD en WS ontwerp- en ontwikkelingsmethode is afgeleid op basis van dit literatuuronderzoek. In de laatste stap zijn de beschikbare huidige methoden geëvalueerd op basis van dit pakket van eisen. Vervolgens is in dit onderzoek een inductieve casus beschreven. In deze casus ging het om het ondersteunen van een luchthavenbedrijf strategie onderzoek waarbij een luchthavenbedrijf applicatie werd ontworpen en ontwikkeld. Deze casus geeft inzicht in de vele mogelijkheden en kansen van CBD benaderingen voor het bouwen van complexe systemen met een korte ontwikkeltijd, maar gaf ook inzicht in de beperkingen van CBD benaderingen. De conclusies uit deze casus zijn conform de conclusies van het literatuuronderzoek en bevestigt het afgeleide pakket van eisen. De volgende stap van de inductief-hypothetische cyclus is gebaseerd op het formuleren van een theorie op basis van het literatuuronderzoek en door abstractie van de casus resultaten. Als eerste zijn consistente en technologie onafhankelijke component gerelateerde concepten opgesteld als basis voor de denkwijze van de methode. In plaats van het definiëren van wat een enkele component is, is gekozen voor het identificeren van essentiële componenteigenschappen en hun wederzijdse relaties. In plaats van een nieuwe modelleertechniek en beschrijvingswijze te ontwikkelen, hebben wij juist onderzocht hoe de componentconcepten uitgedrukt kunnen worden met behulp van bestaande modelleerparadigma’s en standaarden zoals Unified Modeling Language (UML) voor het grafisch modelleren, de Interface Definition Language (IDL) om in de voor de mens begrijpelijk wijze tekstueel te modelleren en de talen en standaarden gebaseerde op de eXtensible Markup Language (XML) welke gericht zijn op het geautomatiseerd verwerken van data. Het ontwikkelde componentconcept en de bijbehorende elementen werden vertaald naar

254

Samenvatting de elementen van deze standaard modelleertechnieken. Waar noodzakelijk werden wijzigingen en/of uitbreidingen ontwikkeld. De ontwikkelde methode in dit onderzoek bestaat ook uit ontwerprichtlijnen, regels en technieken om de hiervoor beschreven concepten en modellen te gebruiken. De methode schrijft voor welke activiteiten uitgevoerd moeten worden tijdens welke stap van het ontwikkelingsproces en bevat richtlijnen om geschikte modellen te ontwikkelen op bedrijf, informatie, applicatie en technologie niveau. De methode schrijft voor dat vier verschillende modellen ontwikkeld dienen te worden tijdens het ontwerp proces, te weten het BedrijfsDomein Model (BDM), Bedrijfs-Component Model (BCM), Applicatie-Component Model (ACM) en het Implementatie-Component Model (ICM). De focus van de ontwerpmethode is op bedrijfscomponenten die proces en gebruiker georiënteerd zijn. Het idee is dat bedrijfscomponenten het juiste abstractie niveau hebben om deze als WS te kunnen weergeven. De handelingen in de ontwerpmethode zijn navolgbaar en de methode is afgestemd op de bedrijfsprocessen welke het systeem moet ondersteunen. Bedrijfscomponenten leveren services om bedrijfsprocessen te automatiseren en te ondersteunen. Bedrijfscomponenten worden gerealiseerd door de interne applicatiecomponenten. Programmacomponenten implementeren de applicatiecomponenten en de bedrijfscomponenten in een gekozen omgeving. De methode is getoetst op bruikbaarheid door deze toe te passen in het ontwikkelingsproces van een locatie-gebaseerd geografisch informatie systeem. Presentaties en discussies met de deelnemers van de organisaties zijn gehouden om de methode en het gebruik ervan te evalueren. Een interview is gebruikt om de gebruikersopinies te achterhalen over de methode. Hieruit bleek dat de deelnemers overtuigd waren van het potentieel van de methode en de deelnemers verwachten dat de methode in de toekomst gebruikt kan worden binnen hun organisatie voor systeem ontwikkeling. Een aantal aanbevelingen voor vervolgonderzoek is opgesteld. Als eerste kan de methode toegepast worden in vele andere casussen en op grond daarvan verbeterd worden. De afbakening van de methode kan uitgebreid worden om platformonafhankelijk bedrijfsprocesmodellen te ondersteunen op grond van een component gebaseerde wijze. De volgende aanbeveling is om een softwareapplicatie te ontwikkelen voor het ondersteunen van de ontwerpmethode gebaseerd op het aanpassen en uitbreiden van een bestaand softwarepakket. Een andere aanbeveling voor vervolgonderzoek is om het procesmanagement aspect van de ontwerpmethode uit te werken. Samen met de ontwerpmethode kan deze dan gebruikt worden om complexe informatiesystemen te ontwikkelen. Een andere aanbeveling is om de ontwerpmethode te integreren binnen het Model-Driven Architectuur (MDA) raamwerk. Dit dient op een dusdanig wijze te gebeuren zodat het componentconcept en de modellen automatisch omgezet kunnen worden in code. Vanwege de continue ontwikkelingen in de bedrijfsomgeving en technologie kan het vervolgonderzoek zich richten op het uitbreiden van de ontwerpmethode met elementen, technieken en strategieën die

255

Samenvatting gebaseerd zijn op de model-driven ontwikkelmethoden en op ‘agile’ ontwikkelmethoden. Op deze manier wordt de methode flexibel en adaptief voor een breder toepassingsgebied. Als laatste kan toekomstig onderzoek zich richten op het uitbreiden van de concepten, modelleerwijze, beschrijvingswijze, ontwerprichtlijnen, regels en technieken om bedrijfsprocessen en de orkestratie van de bedrijfsprocessen met behulp van Web services weer te geven.

256

Biography Zoran Stojanović was born on March 1st 1969 in Niš, Yugoslavia. After graduating from the mathematical-programming gymnasium “Bora Stanković” in 1987, he studied Computer Science at the Faculty of Electronic Engineering at University of Niš, Yugoslavia. After the graduation in 1993, he became a researcher and teaching assistant at the same Faculty. During the period of next six years he was involved in conducting research in the fields of databases, software engineering, computer graphics (CG) and geographic information systems (GIS). Parallel to this, he was a member of the CG & GIS Lab involved in building commercial GIS systems for public and private enterprises. He obtained a Master of Philosophy degree in Computer Science and GIS in 1998 from the University of Niš with the thesis project related to the design and development of a spatial query and analysis tool for using in GISs. In 1999/2000 he spent four months as a visiting researcher at the Institute for Informatics at Free University of Berlin working in the fields of spatial reasoning and open GIS. In 2000 he moved to the Netherlands to become a researcher at Delft University of Technology, first two years at the Faculty of Information Technology and Systems and, then, at the Faculty of Technology, Policy and Management. His research was focused on component-based development, Web services, business and system modeling and model-driven architecture. He was a member of the multidisciplinary research project BETADE (Building Blocks for Effective Telematics Application Development and Evaluation). He participated in the project of development an airport business suite as a decision enhancement tool for handling airport business. He was involved in giving practical courses related to using a GIS tool in business applications. During his research carrier so far, he has been an editor of one book and an author of more than 30 papers published in journals and books, and presented at international conferences and workshops. Currently, Zoran works as a senior software engineer at Tjip BV in Delft.

257