Understanding ‘variation’ in component-based development: case findings from practice
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)
- 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...
- et al.
The Microstructure of Designs
(1997) - et al.
How reuse influences productivity in object-oriented systems
Communications of the ACM
(1996) - et al.
Diversity in information systems action research methods
European Journal of Information Systems
(1998) - et al.
Summary of the Second International Workshop on Component-Oriented Programming
From Framework through Experience to Learning: The Essential Nature of Action Research
- et al.
Information, Systems and Information Systems — Making Sense of the Field
(1998) Structuring use-cases with goals
Journal of Object Oriented Programming
(1997)The Research Act: A Theoretical Introduction to Sociological Methods
(1978)
Objects, Components and Frameworks with UML: The Catalysis Approach
Building Business Objects
UML Distilled: Applying the Standard Object Modeling Language
Migrating to Object Technology
Making reuse work at Hewlett–Packard
IEEE Software
C3 Domain Analysis: Lessons Learned
Object-Oriented Software Engineering: A Case Driven Approach
Software Reuse: Architecture, Process and Organisation for Business Success
Cited by (8)
Action Research Can Swing the Balance in Experimental Software Engineering
2011, Advances in ComputersAligning the economic modeling of software reuse with reuse practices
2008, Information and Software TechnologyCitation 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.
Fixed priced projects in agile: Fixed projects in agile software development environments
2016, Emerging Innovations in Agile Software DevelopmentA Theoretical Framework of Component-Based Software Development Phases
2010, Data Base for Advances in Information SystemsService orientation
2006, Service OrientationA review of component-based software development
2005, Association for Information Systems - 26th International Conference on Information Systems, ICIS 2005: Forever New Frontiers