Understanding ‘variation’ in component-based development: case findings from practice

https://doi.org/10.1016/S0950-5849(00)00159-2Get rights and content

Abstract

This paper discusses the importance of understanding and capturing variation in component-based development using the context of a six-month action research project carried out within a major system solution provider. The issues raised in the empirical context show that the norms of given development disciplines need to adapt for component-based development projects and that this is neither trivial nor easy. In addressing such issues, the implications of adopting a domain-based approach to component-based development are explored alongside the means by which this may be undertaken. This exploration highlights the need to provide an explicit understanding of variation and the ramifications of providing a component with varying degrees of context independence are explored via a scenario developed in practice. The scenario shows that neither reuse nor variation should be allowed to be chaotic if component-based development is to handle flexibility in a more cost-effective and coherent manner than system maintenance currently does. The paper concludes by presenting an example of an elaborated use case to illustrate how existing techniques can be modified to provide a structured environment for understanding variation. Holistically, the discussion shows that component-based development should not be viewed as a singular discipline, but rather as an umbrella activity that requires the melding of a number of important research areas.

Introduction

Component-based development aims at the dynamic ‘plug-and-play’ composition of information systems from heterogeneous off-the-shelf software components. Though this has been an historical industry goal [21], the approach is now supported with the requisite underlying technologies and is gaining in popularity. In ideal terms, components represent constituents that are governed within the confines of software architecture. This architecture provides the mechanisms that allows components to be removed, replaced and reconfigured in a dynamic fashion and provides a flexible environment in which to cater for change. Within architectural confines, each component represents a unit of independent production, acquisition and deployment [31]. As units of independent production, different people can develop components at different times, with the ‘market’ acting as an intermediary. As units of acquisition and deployment, organisations potentially benefit from the reduced cost and risk associated with commercial-off-the-shelf software. Consequently, the possibility exists for an organisation to select the functionality they require, purchase the appropriate components and compose a system from them. Component-based development thus aims to provide an environment where reuse and interoperability are the rule rather than the exception.

Confining the discussion to ‘production’, this ideal indicates that some re-education is required, as the ethos of composition and reuse is required to be pervasive. At the component level, this is evident in the fact that, while a component may be developed in isolation, it must be adequately prepared to socialise with a population (or populations) of components in the context of an enforced etiquette. Examples can be seen across the development lifecycle to support this view. For analysis the question is raised of how domain knowledge should be captured, as markets mediate between developers and third parties. For design, an emphasis is placed on synergy with analysis, as opportunities for reuse may be missed unless they are recognised [26]. In addition, conformance to common design rules takes the place of direct communication and agreement among both developers and third parties [3]. For programming, added emphasis is placed on features such as polymorphism (substitutability), modular encapsulation (higher level of information hiding), late binding and loading (independent deployability) and type and module safety issues [31]. For testing, the focus is placed firmly on atomic and architectural components as the units of testing, as the dynamic extensibility of the resulting system questions the very basis of integration/system testing.

Concentrating on the production aspect of component-based development, this paper argues that a raised level of awareness is required for understanding and capturing variation in the needs of a given market. Using findings from an empirical case study, the paper argues that the norms of given development disciplines need to adapt to the context of component-based development and that this is neither trivial nor easy. The paper begins by discussing the empirical context of the research and then describing the method of research. With these aspects made clear, the implications of adopting a domain-based approach to systems analysis are explored alongside the means by which this may be undertaken. This exploration shows the need for an explicit understanding of variation and the ramifications of providing a component with varying degrees of context independence are explored via a scenario developed in practice. The paper concludes by presenting an example of an elaborated use case to illustrate how existing techniques can be modified to provide a structured environment for understanding variation. An overall output of the exercise is that component-based development should not be viewed as a singular discipline but, rather, as an umbrella activity that requires the melding of a number of research areas.

Section snippets

The context of research

The research discussed here was set in the context of a multinational ‘systems solution’ provider who will be referred to as ‘ComCo’ for the remainder of the paper. Traditionally seen as a proprietary mainframe vendor, the company has sought to make information management its strategic focus since the mid-1990s. ComCo's vision of an information management company is one that provides a mix of industrial and organisational understanding alongside the application and support of appropriate

Research method employed

The author joined the programme in mid-1998, following discussions related to problems being experienced by the company in question. Given the interpretative beliefs of the author and ComCo's perceived need to change the status quo within the development programme, action research was adopted as the strategy of preference. The aim of using this approach was a dual one that sought to contribute to the resolution of the practical concerns of people in an immediate problematic situation, in

The implications of a domain-based approach

The purpose of the former part of the action research was akin to that of providing a ‘map’ of the organisational ‘territory’ with the aim of identifying salient issues and instigating corrective action where necessary [35]. The investigation itself uncovered a number of issues related to: (a) the programme itself, (b) the development process and style, (c) project management, (d) human resources, team structure and communication, and (e) documentation. Though the detail of these issues is

The importance of variation

Taking the above points in turn, it is proposed that an understanding of variation should flow logically from an understanding of the commonality and difference of a given feature within a domain. This may be differentiated in terms of both nature and type but the ComCo case shows that the analysis of features is neither a neat nor ‘one shot’ process. This was evidenced in an existing ComCo system whose requirements were developed in conjunction with a client partner (Option 4 in Fig. 1) and

Making variation explicit: a use case example

In the examination of the ComCo programme, the lack of understanding relating to variation manifested itself in what many development staff referred to as ‘black hole’ thinking; important details were either left to the province of others or remained implicit during analysis and design. The point of the above discussion, however, is to make it clear that the elucidation and representation of such detail is particularly important in the domain/market/reuse oriented situation. Choices need to be

Conclusions

This paper has sought to raise the level of awareness related to understanding and capturing variation in component-based development, based on knowledge gained from a six-month empirical case study. The study was undertaken in the context of component-based development programme instigated within a multinational system solution provider. One of the major insights of the totality of this work was that component-based development should not be thought of as a singular discipline but rather as an

References (37)

  • C. Argyris et al.

    Action Science — Concepts, Methods and Skills for Intervention

    (1985)
  • S.C. Bailin, J.M. Moore, R. Bentz, M. Bewtra, KAPTUR: Knowledge Acquisition for Preservation of Tradeoffs and...
  • C.Y. Baldwin et al.

    The Microstructure of Designs

    (1997)
  • V.R. Basili et al.

    How reuse influences productivity in object-oriented systems

    Communications of the ACM

    (1996)
  • R. Baskerville et al.

    Diversity in information systems action research methods

    European Journal of Information Systems

    (1998)
  • J. Bosch et al.

    Summary of the Second International Workshop on Component-Oriented Programming

  • P. Checkland

    From Framework through Experience to Learning: The Essential Nature of Action Research

  • P. Checkland et al.

    Information, Systems and Information Systems — Making Sense of the Field

    (1998)
  • A. Cockburn

    Structuring use-cases with goals

    Journal of Object Oriented Programming

    (1997)
  • N.K. Denzin

    The Research Act: A Theoretical Introduction to Sociological Methods

    (1978)
  • D.F. D'Souza et al.

    Objects, Components and Frameworks with UML: The Catalysis Approach

    (1999)
  • P. Eeles et al.

    Building Business Objects

    (1998)
  • M. Fowler et al.

    UML Distilled: Applying the Standard Object Modeling Language

    (1997)
  • I. Graham

    Migrating to Object Technology

    (1995)
  • M.L. Griss et al.

    Making reuse work at Hewlett–Packard

    IEEE Software

    (1995)
  • R.M. Holmes et al.

    C3 Domain Analysis: Lessons Learned

    (1993)
  • I. Jacobson

    Object-Oriented Software Engineering: A Case Driven Approach

    (1992)
  • I. Jacobson et al.

    Software Reuse: Architecture, Process and Organisation for Business Success

    (1997)
  • Cited by (8)

    • Aligning the economic modeling of software reuse with reuse practices

      2008, Information and Software Technology
      Citation Excerpt :

      The cost of black-box reuse is therefore primarily determined by the effort required to configure the reused asset. This effort will generally depend on the number of variation points, which is determined by the degree of commonality among applications in the target domain [3,29,37]. As a consequence, relatively large software assets can have few variation points, whereas relatively small software assets can have many variation points.

    • A Theoretical Framework of Component-Based Software Development Phases

      2010, Data Base for Advances in Information Systems
    • Service orientation

      2006, Service Orientation
    • A review of component-based software development

      2005, Association for Information Systems - 26th International Conference on Information Systems, ICIS 2005: Forever New Frontiers
    View all citing articles on Scopus
    View full text