The software developer organisation can also change its business: a subcontractor has a possibility to turn to a component supplier. A component is a part of ...
Documented Quality of COTS and OCM Components Päivi Kallio, Eila Niemelä VTT Electronics, Embedded Software P.O. Box 1100, 90571 OULU, Finland {Paivi.Kallio, Eila.Niemela}@vtt.fi ABSTRACT The reuse of components increases the need to document the components in a standard way, because proper documentation assists a buyer to assess the credibility and maturity of a component and validate the functional and quality properties of a component. This document provides a general template for documenting software components in a standard way whereby the component buyer and developer views are taken into account. Keywords: software documentation, COTS, OCM, software acquisition, software reuse 1. INTRODUCTION The need to cut costs and reduce time-to-market has substantially increased the use of COTS (CommercialOff-The-Shelf) and OCM (Original software Component Manufacturer) components also in embedded systems during the last years [10]. COTS and OCM components can extensively be used in product lines that have been adopted, and have proved to be successful in the development of embedded systems [9]. This signifies a new role that a company can play in the business of embedded systems and software [2]. The owner of a product line acts as an integrator that orders components from suppliers by specifying the required properties of a component. The software developer organisation can also change its business: a subcontractor has a possibility to turn to a component supplier. A component is a part of software system in the form of a binary code and its documentation. The common interest of component developers and integrators is to describe the
capabilities and constraints of a component thoroughly and in such a way that both sides can understand the descriptions in the same way. Using COTS components increases the importance to document the properties of a component carefully so that the component could be identified, managed and stored as one. COTS components are not documented in a standard way, and therefore, integrators have difficulties to find out the capabilities of components - consequently a separate, maybe long-term evaluation phase is required to asses the quality of components. Integrators need more precise information about the components that have to meet the functional and quality requirements of the product line. These requirements are set by the software architecture of the systems in which the components are intended to be utilised [1]. From the integrator’s (a buyer) point of view, component documentation should provide information for assisting in q
selection of components,
q
validation of interoperability of components,
q
analysis of combined quality attributes, and
q
maintenance of components.
Granularity and portability of components are the key issues software developers are interested in because they define in which platforms the components can be used and how often they are used. In most cases, the set of possible components to be considered is small. If components were classified according to the domains that guide finding component candidates, they would be easy to find. However, brokers normally have classified COTS components on the bas is of used technologies. The structure of a component documentation should also be organised in a logical way whereby all necessary information is easy to find out. Proper documentation assists a buyer to assess the credibility and maturity of a component. The assumptions made by component documentation should be valid in the customer's systems and the component should not have any side effects, either. The delivered component meets the functional and quality requirements only if the buyer and supplier co-operate and follow standard procedures to document them.
This paper focuses on the problem of how software components should be documented from the component buyer’s and supplier’s points of view. 2. CONTENT OF A COMPONENT DOCUMENT Figure 1 illustrates problems encountered when COTS and OCM components are applied in software systems. Although quality is important in all systems, it is extremely important in product lines, in which an unwanted property or a side effect causes higher additional expenses than it would cause when the component is used only in a single system. Therefore, the quality of a component is the interest of both component buyers and component suppliers. Buyer organisation
Supplier organisation
Component reuser
Component developer
For_REUSE Process
Functionald and Quality Requirements of a Component
Delivered Component with Documentation
Component Acquisition Process
With-REUSE Process
developed for a specific purpose. Software documentation is classified into parts according to a purpose: user documentation, system documentation, process documentation, and reuse documentation [11]. The reuse documentation includes a coarse-grained functional specification and information that guides reuse, management, and assessment of a component. In a genre system [5], a reusable software component has two parts: the reusable part and a part that supports reuse. The reusable part includes objectives and design rationale for the component, results of the work, and testing results. The supporting reuse part consists of maintenance information, consuming information, and management information. The idea is to map the roles of a component provider, a maintainer, a software developer and a reuse manager to all information pieces produced during the for-reuse and with-reuse processes. For-reuse means making efforts to develop reusable components and withreuse reusing existing components [7]. The maintainer of a component repository actively updates the repository by assessing, procuring, certifying, adding and deleting components. However, a software developer who reuses components needs all the available information: instructions for how to find, select, adapt and integrate a proper component. A classification scheme is a solution for that problem [8]. The reuse manager updates management information with a creator, support, pricing etc. The model is appropriate when a reuse process inside an organisation is considered. If components are ordered outside, the for-reuse process is split between two organisations (component buyer and component supplier) and the with-reuse process is applied in several organisations. Therefore, the model is not appropriate for COTS and OCM components as such. 3. A DOCUMENT TEMPLATE OF A SOFTWARE COMPONENT
The functional and quality requirements are defined by the architecture in which the component is intended to be used. The requirement specification standard classifies requirements to functional and quality requirements [4]. An architecture design method [1, 3] is a way to describe how the requirements are converted to responsibilities the systems have to meet. In architecture design, these responsibilities are clustered and mapped to architectural elements, i.e. styles, patterns and components. Therefore, it is the responsibility of an architect to define the functional and quality requirements of a component.
A general model for documenting software components includes the information produced by the component buyer (a requirement specification) and the component developer (the rest of document). The information gathered during the with-reuse process is also included in the history of a component. The component document is a set of information pieces that are produced by the following roles: an architect, component designer, reuser, and maintainer. The architect defines the functional and quality requirements of a component. The component designer describes technical details and how the requirements are met. Reusers update the document by adding comments of bugs, changes made, etc. The maintainer updates components and their history with quality information.
The requirement specification principles can not be used straightforwardly for defining components because components are intended to be used wider than software
The information in component documentation is divided into four categories that are derived from the literature [4, 6, 7, 8] and, furthermore, refined and applied in the
Figure 1. Quality and documentation in component acquisition.
development of software components for embedded systems [3, 12] (Figure 2). 1.
Basic information 1.1 General information of the component 1.2 History of the component 1.3 Functional specification 1.4 Interfaces 1.5 Composition
2.
Detailed information 2.1 Technical details 2.2 Installation guide 2.3 Constraints 2.4 Modifiability 2.5 Performance 2.6 Safety and security
3.
Acceptance test
4.
Support and additional information
Figure 2. The structure of a component document. The four categories of information are described more thoroughly in the next paragraphs. General information includes: q
Component name
q
Identification
q
Component type
q
Design rationale and objectives of the component.
It is the responsibility of an architect to define this information. Component names should be well-defined and follow guidelines provided for the architecture. All components should have an unambiguous identification. A component type is a property of how the component is intended to be used, e.g. as a procedure, a function-block or a subsystem. Components should follow the same design rationale as the architecture. Objectives of a component are fundamental issues that are needed in order to understand why the component is made.
Interface descriptions define the provided and required interfaces of a component. An interface determines how a component can be used and interconnected with other components. Communications interfaces specify the networks and network protocols to be used. Hardware interfaces define the hardware the software is executed on. A software interface determines the compatibility of the software with other software, i.e. how a component can be used and interconnected with other components. Different forms of composition define the composition of the component. In internal composition, the component is included in a software system. In external composition, the component runs as an independent program. Functional and object-oriented compositions are based on activation of the components by function calls. Textual composition is used for macros. The detailed information should answer the questions: what information does the documentation include, why information has been produced, by whom and at what stage of the process. Component's technical details provide information about: q
The format of the component
q
The technical environment for software development
q
Physical resources the component needs
q
Execution and composition platforms
q
Interdependencies with other components, and
q
Technical limitations and restrictions on the use of the component.
Installation guide explains how the component has to be installed into a different environment and the form of implementation. Constraints should describe all items that will limit the developer's options for building the components. Interface constraints define how communication is done with other systems, what hardware is to be used and what software the component has to be compatible with and how it must interact with human operators. [4]
q
Inputs
q
Outputs
q
Functionality of the component in detail, for example in the form of a sequence diagram
Modifiability of the component determines how the component can be modified to a new environment and to new changes quickly and cost effectively. The connecting of a component optimally requires minimal changes to the design - preferably not any at all. A new requirement should cause modifications for a minimum number of components and the scope of modification should be easy to see.
q
Data handling, and
The performance of the component is measured by:
q
Functional exceptions (optional).
The component functional specification describes:
q
Size
q
Prioritisation of the events
q
Capacity
q
Throughput
q
Error detection, and
q
Allocation time of resources.
Size defines the size of the component for example as lines of code. Capacity measures the amount of work a component can perform. Throughput is the number of event responses that have been completed over a given observation interval. Metrics that measure performance can be collected during the development of the component (priori metrics) and when a component is reused (posteriori metrics) [7]. Error detection describes how the component copes with fail-situations. Safety defines the strategies against viruses and hackers, recovery methods in attack-situations, and protectingmethods of the data.
described documentation template with UML and a commercial CASE tool. REFERENCES 1.
Bachmann, F., Bass, L., Chastek, G., Donohoe, P., Peruzzi, F. 2000. The Architecture Based Design Method. Carnegie Mellon University, CMU/SEI2000-TR-0001. 50 p.
2.
Brereton, P., Budgen, D. 2000. Component-based systems: A classification of issues. IEEE Computer, November, pp. 54-62.
3.
Dobrica, L., Niemelä, E. 2000. A strategy for analysing product line software architectures. Espoo: VTT, VTT Publications 427, 124 p.
4.
ESA Board for Software Standardisation and Control, 1991. Guide to the user requirements definition phase. ESA PSS-05-02 Issue 1. 34 p.
5.
Forsell, M., Päivärinta, T. 2001. A Proactively Explicated Genre System for Documenting Reusable Software Components. Sent for publication for journal Database for Advance in Information Systems. 20 p.
6.
Ippolito, L.M. et al. Software Quality Assurance: Documentation and Reviews. NISTIR 4909. On-line at: http://hissa.ncsl.nist.gov/publications/nistir4909/
7.
Karlsson, E-A, 1996. Software reuse - a holistic approach. Chichester: John Wiley & Sons. 510 p.
8.
McClure, C. Reuse Engineering. Extending Information to Enable Software Reuse. Extended Intelligence Inc. On-line at: http://www.reusability.com/papers4.html
9.
Niemelä, E., Ihme, T. 2001. Product line software engineering of embedded systems. 8 p. Accepted for the Symposium on Software Reusability, SSR’01.
The acceptance test information of the component describes [6]: q
Test environment
q
Test support
q
Test data that the component has been tested with
q
Test cases used in testing
q
Test methods, and
q
Test results
The scope of testing should be restricted. The component specification should contain black box tests that the component should pass. [12]. The customer support information describes unsolved bugs and problems and their severity and state. The customer is also provided with a point of contact to get help in problem situations. Additional documentation includes, for example , experiences of the component use and improvement proposals.
4. CONCLUSIONS Although there is a need to utilise COTS and OCM components, there are still barriers that prevent from getting full benefit from the software component business. As a means to qualify a component its documentation is a fundamental factor. In order to get reusers assured that the quality of a component is in conformance with the quality of the product or products the component will be used in, the thorough documentation is the only way. That is why a standard documentation template is needed for software components, especially for COTS and OCM components. The current research concentrates on integrating the above
10. Niemelä, E., Kuikka, S, Vilkuna, K., Ahonen, J., Lampola, M., Forssel, M., Korhonen, R., Seppänen, V., Ventä, O. 2000. Industrial software components. Development concerns and strategic initiatives. Technology survey 89/2000. Technology Development Center Tekes, (in Finnish), 129 p. 11. Sametinger, J. 1997. Software engineering with reusable components. New York: Springer Verlag. 272 p. 12. Salmela, M., Korhonen, J., Kalaoja, J. 1999. Automated test reuse for product families. Software Quality Week Europe, QWE '99. Brussels, BE, 1 - 5 Nov. 1999. Software Research Insitute (1999), 13 p.
