An informal COTS Specification Model : Enabling Component Acquisition

In today’s global market, the need for well functioning and robust information systems is greater than ever. Organizations also have to continuously adjust and improve their business practices to maintain a competitive edge at the same rate the information systems have to be adapted in accordance with these changes. This is a big challenge for the software development community, and has been a big issue in the software engineering field for at least two decades. The challenge is to increase the productivity of software system development and to augment the flexibility of software systems to react to business process changes. One approach to achieve this is taking clues from traditional production techniques. Software systems should be constructed from prefabricated, easily identifiable software components (Szyperski, 2002, Christiansson, 2001) that can be widely used. To develop software systems with a component-based approach is one of the newer trends within the software development community. However for component-based software development to be successful in organizations, the software developers must give close attention to the design of components as independent abstractions with well-specified behaviors. Without well-specified behaviors the possibility to distribute and acquire software components will be limited. Langefors (1995, p. 142) describes the development of software systems as finding the solutions to: ”Two fundamental problems with information systems were pinpointed at the outset: (1) The "infological” problem of how to define the information to be made available to the information system user, and how to design data that may represent the information to the user; and (2) The ”datalogical” problem of how to organize the set of data and the hardware so as to implement the information system. ”. We take our point of departure in this description. We believe that emphasis during software development needs to be on both these problem areas also regarding component-based software development or even more so regarding component-based development. We believe this is accurate due to two facts firstly software component development should be focused on assembly rather than about construction. This means that we do not have to focus on how the actual development is done; the software component is an existing artifact. Secondly software component development is about acquisition, we need to be able to identify which components we need when assembling systems; this conveys the need for a specification of the components behavior (Szyperski, 2002, Heineman & Councill, 2001). This acquisition we believe needs to be based on an ‘infological’ specification as well as a “datalogical” one, using Langefors (1995) terms. In this paper we describe an informal “infological” model to specify software components used by the largest software component distributor Componentsource (2003). We argue for the need of an informal approach for addressing the ‘infological’ problem of software development that enables acquisition rather than construction. We have previously shown (Christiansson & Christiansson, 2003) that such approaches are missing in the research community. In this paper we focus on an existing solution created in practice. We believe an optimal approach probably can be found somewhere in the middle between “unreflected” practitioners problem solving ad-hoc solutions and “reflected” theorists “unused” efforts.