A Method for Component-Based and Service

A Method for Component-Based and Service
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
in industry
based methods consortium
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
Stereotype of Stereotype of
Not specific
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 <<component>>. 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
Potential support for
Web services
Not really defined
Claim the support, in
reality only the basic one
Well-equipped to
support model
transformations
Has some potential,
happened before MDA
hype
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
New version has a built-in
support for services
Does not consider Web
services, happened before
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 <Contract,
Content, Context>.
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
Invariant
+exposes
Behavior
+coordination of
+affects
0..*
Service
Provided
1..*
+adapted by
+constrained by
0..*
Required
+id enti fied by
+constrained 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 <<component>> 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
Port1
Port2
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 <<component>>.
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 <<realize>>, while requiring an
interface is modeled with a dashed line with an open arrowhead at the end and with the
stereotype <<use>>. 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 sub114
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
Scope: Internet-based
Conditions: Customer must be registered
al Version EA 4.10 Unregistered Trial Version
ICustomerInfo
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
<name, type, initial value> 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 <<manifest>> 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,
<<document>>, <<executable>>, <<file>>, <<library>>, <<table>>, 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 <<entity>>, <<process>>, <<service>>, and <<subsystem>>. 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. <<business entity>> stereotype, or, if organized as a component,
using <<entity application component>> 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
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
name="HelloWorld"
targetNamespace="http://www.your-company.com/HelloWorld.wsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.your-company.com/HelloWorld.wsdl"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsd1="http://www.your-company.com/HelloWorld.xsd1">
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
</wsdl:documentation>
<wsdl:types>
<xsd:schema
targetNamespace="http://www.your-company.com/HelloWorld.xsd1"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsd1="http://www.your-company.com/HelloWorld.xsd1"> </xsd:schema>
</wsdl:types>
<wsdl:message name="NewMessageResponse">
<wsdl:part name="reply" type="xsd:string"/>
</wsdl:message>
<wsdl:message name="NewMessageRequest">
<wsdl:part name="name" type="xsd:string"/>
<wsdl:part name="arg1" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name="HelloWorldPortType">
<wsdl:operation name="sayhello">
<wsdl:input message="tns:NewMessageRequest"/>
<wsdl:output message="tns:NewMessageResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="HelloWorldBinding" type="tns:HelloWorldPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="sayhello">
<soap:operation soapAction="capeconnect:HelloWorld:HelloWorldPortType#sayhello"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output><soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="HelloWorld">
<wsdl:port binding="tns:HelloWorldBinding" name="HelloWorldPort">
<soap:address location="http://localhost:8000/ccx/HelloWorld"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
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 <interface> 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 <model> construct, which allows composition of two or more
WSCI <interface> 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 <documentation> element
Non-functional parameters
WSDL <documentation> element
Service component ports and interfaces
WSDL <portType>
Provided and required operations
WSDL <portType> operations
Events – published and consumed
WSDL <portType> operations
Operation parameters
WSDL <message> 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 <message> definitions
Information types
WSDL <type> element
Information type instances lifecycle
WSDL <message> definitions
Constraints on information instances
Design-by-contract embedded into WSDL
Service implementation
WSDL <binding> element
Service executable
WSDL <service> 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.
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
146
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.
<<precede>>
Find a Product
<<precede>>
Send an Order
Pay a Bill
Figure 6.4 Relation <<precede>> 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.
<<extend>>
Register
Registration Failed
Query Textual
Query Geoinformation
Query Spatial
<<include>>
<<include>>
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
Query
+poses
RequestCondition : string
RequestSource : string
1..*
1..*
+has
Invoice
Amount : double
Date : string
User
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.
<<Interface>>
IQueryMgt
Comp oseQuery()
Process Query()
HandleErrors ()
Pres entR es ults()
<<Component>>
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
<<Int erface>>
IRegMgt
ManageLogin()
HandleProfile()
LockSys tem ()
ManageMenu()
<<Component>>
Registrat ion Manager
<<us e>>
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
<<Interface>>
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.
<<Component>>
Event Manager
IEventMgt
<<Com ponent>>
QueryManager
IQueryMgt
<<Component>>
RegistrationManager
IRegMgt
<<Com ponent>>
Route Finder
IR outeMgt
<<Component>>
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.
<<ApplicationServer>>
Request
Geographic
Entity
<<WAP Server>>
<<PDA Browser>>
<<Database Server>>
Route Composer
Route Processor
UI Forms
Data Handler
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;
♦
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;
206
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
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement