The Development of Component-based Information Systems

Sergio de Cesare, Mark Geoffrey Lycett, Robert Macredie

• Publisher: Routledge
• Year: 2015
• eBook ISBN: 9781317457459
• Edition: 1
• Topic: Business
• Subtopic: Business Ethics
• Index: Business

This work provides a comprehensive overview of research and practical issues relating to component-based development information systems (CBIS). Spanning the organizational, developmental, and technical aspects of the subject, the original research included here provides fresh insights into successful CBIS technology and application. Part I covers component-based development methodologies and system architectures. Part II analyzes different aspects of managing component-based development. Part III investigates component-based development versus commercial off-the-shelf products (COTS), including the selection and trading of COTS products.

CHAPTER 1

DEVELOPMENT OF COMPONENT-BASED INFORMATION SYSTEMS

AN INTRODUCTION

SERGIO DE CESARE, MARK LYCETT, AND ROBERT D. MACREDIE

Abstract: Information systems (IS) development is a complex endeavor. Notwithstanding significant advances achieved in a number of areas, including methodologies, techniques, architectures, and project management, the rate of unsuccessful or failed projects continues to be high. Development paradigms have evolved in an attempt to reduce the effort and cost of IS change necessitated by continuous demands of systems maintenance and integration. This has led IS developers to rethink systems design in terms of independent but collaborating components, each charged with specific responsibilities. Component-based development promises considerable benefits such as reuse, increased interoperability, and less costly software evolution. Such benefits are not easily achievable and require simultaneous work along multiple dimensions: organizational, methodological, and technological.

This chapter serves two purposes. First, it provides an overview of the concepts, issues, and dimensions underlying component-based information systems development. Second, it serves as an introduction to the remaining chapters, providing the reader with the necessary foundation to critically appreciate the research work presented throughout the volume. A discussion of research methods on the development of component-based information systems is also presented, with particular emphasis on design research.

Keywords: Software Component, Component-Based Development, Component Development, Component Assembly, Organizational Implications, Design Research

INTRODUCTION

Information systems (IS) development is at the core of the IS field (Fitzgerald et al. 2002). Approaches to IS development have evolved significantly in an attempt to overcome the difficult problems of delivering IS projects on time, within budget, and with the desired level of quality. Notwithstanding the advances achieved in a number of areas (e.g., methodologies, techniques, architectures, and the organization and management of projects), systems development as a whole is still characterized by a high rate of unsuccessful or failed projects that are costing industry billions of dollars a year. Ewusi-Mensah (2003) estimates that one-third of software development projects fail or are abandoned due to cost overruns, delays, and reduced functionality. Furthermore, for every dollar spent on development, five to ten dollars are spent on integration with existing systems. For every $100,000 in an organization’s systems development budget, some $50,000 will be spent on modifying existing systems to deal with business change (Gibbs 1994; Raviart 2001; Standish 2003).

These figures are symptomatic of the current situation in systems development and indicate that the most costly and problematic areas are maintenance and integration. In essence, this situation equates to dealing with change in IS. This conclusion is unsurprising, as business organizations are complex systems that constantly need to adapt and change in response to internal and external factors in order to be competitive. Business organizations do not evolve in a stepwise fashion but are best thought of as “emergent” entities whose features are products of continuous social negotiation and consensus building (Truex et al. 1999). Ideally, therefore, IS should be developed in a way that facilitates continuous modifications in face of changing requirements.

IS development approaches, methodologies, and techniques have attempted to tackle the problems of increasing costs and poor quality by focusing on maintenance and integration of IS. Traditionally, applications were developed in a stovepipe fashion. Stovepipe systems were developed to be intrinsically stand-alone and closed to any form of communication, coordination, or collaboration with other systems (e.g., software, business, and physical systems). Such systems were also characterized by nonmodular architectures, making it difficult to localize and set the boundaries of maintenance interventions.

With the growing rate of change of modern organizations and the increasing level of interconnectedness of their business processes (e.g., in e-commerce and virtual organizations), the deficiencies of traditional systems readily emerge.

The practical need of overcoming the problems mentioned above has led IS developers to rethink systems design in terms of independent but collaborating parts, each of which is charged with specific responsibilities. This evolution of development methodologies of the past thirty years has progressed from structured to object-oriented to component-based approaches. The objective was to evolve toward the ideal of developing IS from independent units of software composition (i.e., components).

The idea of component-based development (CBD) was set out by McIlroy (1969). McIlroy coined the term mass-produced software components and expressed his vision of the benefits that would derive from component-based systems—benefits such as greater reuse, increased interoperability, and easier software evolution. These advantages echo throughout the software development literature up to today (Brown and Wallnau 1996; Brereton and Budgen 2000; Crnkovic and Larsson 2002).

Among the cited benefits, reuse plays a crucial role in ensuring effective and efficient IS change. In software development, reuse can be defined as further use or the repeated use of an artifact (Jacobson et al. 1997). In a development project, the successful reuse of software artifacts is conditioned by many factors. These include the existence of reusable artifacts (e.g., components), availability of selection and assembly techniques, technological support, and an organizational structure and culture orientated toward reuse. Thus, methodological, technological, and organizational factors are all key to the adoption of reuse strategies within organizations.

In addressing these factors, this chapter is organized as follows. The next section defines the fundamental concepts of component-based development. The presentation of various CBD issues follows, starting with the developmental aspects of component-based systems. These aspects concern the bifaceted nature of CBD, that is, development for reuse (or development of reusable components) and development with reuse (or component assembly). Next, the organizational implications of CBD are considered, followed by a discussion of research methods for component-based information systems. Finally, the chapter presents an overview of the book and some conclusions.

DEFINING COMPONENT-BASED DEVELOPMENT

Component-based development is based on the fundamental concept of composition (Szyperski 1999). This implies that software solutions are developed by assembling independent software parts and that desired system behavior is achieved through the collaboration of those parts. The notion of components has existed within the software development literature for decades, generally assuming different meanings. At times, the notion has been synonymous with concepts such as function, procedure, module, class, package, and so on. Although a standard, universal definition of the term component is not available, in recent years the term has assumed a narrower connotation, defined by specific characteristics. This point was illustrated by a workshop at the Eleventh International Conference on Software Engineering (Brown and Wallnau 1996). Table 1.1 summarizes a few of the proposed definitions.

Table 1.1

Definitions of Component

Author	Component definition
Philippe Krutchen, Rational Software	A component is a nontrivial, nearly independent, and replaceable part of a system that fulfills 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.
Gartner Group	A run-time 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 run-time.
Clemens Szyperski, Microsoft	A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
Wojtek Kozaczynski, SSA	A business component represents the software implementation of an “autonomous” business concept or business process. It consists of all the software artifacts necessary to express, implement, and deploy the concept as a reusable element of a larger business system.

The third of the definitions in Table 1.1 was originally formulated at the Workshop on Component-Oriented Programming (Szyperski and Pfister 1997) held at the 1996 European Conference on Object-Oriented Programming. This definition was subsequently used by Szyperski (1999). Szyperski’s definition is widely referenced throughout the component-based literature. In the context of this definition, the significant characteristics of software components are as follows:

• Unit of composition and independent deployment. Composition and independent deployment are relative concepts. First, composition and deployment of software components are dependent on context dependencies. Second, both the literature and anecdotal evidence confirm that a component is not generally adopted as is, but adapted to meet specific requirements (functional, nonfunctional, and architectural) before deployment.

• Contractually specified interfaces. A component can support three types of interfaces: provided, required, and configuration (Bosch 2000). Provided interfaces define the services that a component offers. Required interfaces define the services that the component requires from other components. Configuration interfaces provide access to variation points, allowing the component user to configure the component to the instance context. Reflection and introspection provide a candidate for a fourth type of interface, which provides information concerning the component’s structure and behavior to other interrogating components and to allow self-adaptive behavior (Maes 1995).

• Context dependencies. Required interfaces and a component framework model, providing the “glue” infrastructure, define context dependencies. Microsoft’s Component Object Model (COM) and Distributed Component Object Model (DCOM), the Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA), and Sun Microsystems’ Java platform provide examples of component frameworks. Cross-platform integration is currently a challenging issue. Work in this area is being undertaken by the Common Component Architecture (CCA) OMG working group (OMG 2001). CCA is a specification for cross-platform portability among components.

Component-Based Development Life Cycles

The current state of the art in component-based development (see Brown and Wallnau 1998; Brereton and Budgen 2000; Crnkovic and Larsson 2002) highlights a number of concerns associated with both components themselves and with assembling sets of commercial off-the-shelf (COTS) components. In the context of component development, these concerns relate to processes, methods, and tools for component generation alongside the management of those components and their respective interfaces. In the assembly context, the concerns are similar but raised to the system level, emphasizing component documentation, assembly mechanisms, adaptation, and customization.

Traditional software development has been primarily concerned with the production and delivery of whole working systems whose functionality is aimed...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• Series Editor’s Introduction
• Acknowledgments
• 1. Development of Component-Based Information Systems: An Introduction
• Part I. Component-Based Development Methodologies and Systems Architectures
• Part II. Managing Component-Based Development
• Part III. Component-Based Development with Commercial Off-the-Shelf Products
• Editors and Contributors
• Series Editor
• Index