This action might not be possible to undo. Are you sure you want to continue?
Carl S. Lebsack, Austin J. Mroczek, Carl J. Mueller Computer Science Department Illinois Institute of Technology Chicago, IL 60616 USA email@example.com, firstname.lastname@example.org, email@example.com
ABSTRACT Component Based Software Development has increased the demand to reuse software components and to integrate software from outside sources. A configuration item management tool is needed to track components and their relationships. Using a configuration item database to store information about components is a possible solution. A prototype configuration management tool was created to explore the characteristics of a configuration item database. The prototype displayed many functions that should be further investigated. This paper explains the possible uses of a configuration item database and the resulting prototype. Keywords: Component-Based Software Development, software reuse, Commercial-Off-The-Shelf software, configuration management, configuration item. 1 INTRODUCTION In 1968 NATO sponsored the first conference on Software Engineering to discuss why there was a gap between the systems that were being proposed and those that were being successfully implemented. One of the papers introduced at this conference formalized the notion of mass produced software . To accomplish his concept of mass-produced software, McIlroy proposed reuse of components to build new applications. Although the discussion that followed the presentation was generally positive, nothing of significance was done to implement this concept until the cold war ended. At that time, NATO governments were less inclined to spend large amounts of money to develop new systems. This prompted defense contractors to search for more cost-effective methods of software production. The concepts of Domain Engineering  and Component
Based Software Development (CBSD)  evolved out of the need to reduce development costs. Domain Engineering provides an in-house source for components for both the application under development and for additions to the reuse library. One of the primary objectives of Domain Engineering is to produce solutions to a problem that satisfy the requirements for a specific application but are general enough in nature to be reused in other applications. Component Based Software Development reduces software development costs through the reuse of previously developed software by adapting these components to a new application. As with most new technologies, there are advantages and disadvantages to this approach. The advantage is that it does appear to reduce cost and delivery time for producing new applications. One of the disadvantages with this faster and more cost effective method of development is that a number of Configuration Management problems have emerged. One problem is the difficulty associated with the identification of the available components. Development organizations frequently spend a large amount of time developing the same functionality repeatedly. A reason for this continuous redevelopment is that other groups within the organization may not know that a given function has been developed. Publishing the characteristics of the reusable components is a solution to this problem; but when there are a large number of reusable modules, manual searches may take more time than building the component. Constructing a database identifying the properties of each component would reduce the search time significantly . Another problem with CBSD is the effort required in building a reuse library. It could take a number of years to develop a robust library from in-house or contracted development. One way to reduce the time necessary to acquire a robust reuse library is to buy the software components. Software purchased from an outside source is known as Commercial Off-The-Shelf or COTS software. Using COTS software for a traditional development environment has advantages and disadvantages . Advantages of using COTS components are: functionality is
instantly accessible; they cost less than in-house development; and they frequently are built by problem domain experts. Disadvantages of developing with COTS components are: limited documentation is provided; there is no guarantee of adequate testing; portability is not guaranteed; limited or no source code access is provided. Traditionally, the only COTS software components used in an application were compilers, database managers, and operating systems. Occasionally, some components supporting communications protocols or special device interfaces were also included. Most of the components of new systems were developed in-house or under special contracts and tailored to the application in progress. From a configuration management perspective, not much has been done with COTS software. In the IEEE Standard Software Configuration Management Plans , COTS components are addressed under the heading subcontractor and vendor control; but not much direction is provided to deal with the issues of COTS components. New development environments and tools have added to this problem. Many of the newer programming and scripting languages require source distribution or a precompiled middle language like Java’s byte code. For applications developed with these languages, placing the translator and its supporting components under version, control is frequently not practical and often not possible. Microsoft’s new .net framework is adding to these difficulties with its Just-In-Time (JIT) environment. The .net framework is being proposed as a solution to version and interface problems with DLL’s . The primary configuration management problem with COTS components, in all forms, is controlling a configuration when individual components are outside of that control. A developer may have no discretion in implementing modifications required by changes made to a component by a COTS vendor. However, it is necessary to track the COTS component as a configuration item to know where it is used. Identification and control of configuration items is one of the primary activities of Configuration Management (CM) . A configuration item is defined as a collection of hardware and software that is designated for configuration management . Some agencies extend this definition to include the test-harness and other items. The definition is broad because the concept is broad. Compilers, third party libraries, requirements documents, design documents, source code, test cases, and review documents are all configuration items that shape the resultant piece of software. Any time a single configuration item is modified, it splits into two distinct items: the original version and the newly created version. The purpose of configuration item management is to ensure that only the configuration items that are part of the current version of the software are included in the release. The changing face of software development, characterized by compo-
software development, characterized by component reuse and integration of COTS products, has created the need for more sophisticated control of configuration items. This identification and control is necessary to provide the information for performing configuration audits that are required by a software configuration management plan. Frequently, control of configuration items is accomplished using a notebook, folder or set of note cards. In certain environments, version control systems are adopted to track configuration items that exist as source code. Even with version control in place, many key configuration items are not automatically tracked and must be accounted for manually. Configuration items, such as compilers, interpreters, documentation, and many COTS components are items that are commonly unaccounted for within a version control system. One of the changes to the development process when using Component Based Software Development is that there is an additional phase for evaluation that occurs after the requirements phase and before the components are integrated into the application . The Software Engineering Institute (SEI) defines six different types of evaluations that should be performed when selecting a COTS component . Four of these evaluations are technical or require technical information to complete them. Conducting these evaluations is usually extremely time consuming, so controlling the harness that was used to conduct the evaluation may be as important as controlling the test cases used to validate the application. Because of the cost of the evaluation and the possibility that the component may be a candidate for another application, the evaluation reports should be under configuration control in addition to the components evaluated. As with the test harness that supports verification and validation reports, the harness used to evaluate the prospective components under consideration should also fall under configuration item management. The question of how CBSD affects the configuration management process affects almost every configuration management activity. A short list of questions about CBSD might include: • • How does CBSD affect a configuration audit? Since changes to components can occur outside the normal change control process, how are these component changes introduced? How is a change impact analysis conducted in a CBSD environment? How is a Software Development File  maintained in such a dynamic environment?
All of these questions revolve around configuration items and their relationships to each other. There are two specific relationships that are critical in a CBSD environ-
ment: 1) what components comprise a configuration item and where are these components used? 2) With these new demands on configuration management, what properties and/or functions should a Configuration Item Database (CID) incorporate? 2 CONFIGURATION ITEM DATABASE The notion of using a configuration management database is not a new concept for automating status accounting and auditing tasks [5, 8, 10, 11, 12]. A configuration management database is a composite of a number of databases consisting of change control, defect tracking, version control and configuration item tracking. It is the Configuration Item database that we feel can address some of the configuration management problems in a CBSD environment. Many companies use the Software Development File (SDF), formerly called the Unit Development Folder, to hold all information about a given piece of software . This file contains the item’s history of changes, audits, test reports, and other valuable information. The contents of the SDF are very similar to the types of information found in a Product Data Management (PDM) file. Software Engineers benefit from maintaining the file by being able to analyze a change request. It allows them to see what modules are affected by a problem and helps determine if it is a recurring problem. However, these files are difficult to keep current with the demanding workload within many companies. Automating the SDF increases its efficiency and usefulness. An electronic format eliminates a lengthy search through cabinets full of folders or boxes full of 3x5 cards. It also makes data available to multiple developers at the same time. Version control systems are often used to manage configurations. The primary purpose of version control systems is to ensure only one person is modifying a document at a time. All pieces of code are held by the system, which allows users to check out modules. Once finished with a module, a developer checks it back in allowing other users to check it out. The system keeps track of all changes to the module. Most version control systems cannot be used to track the dependencies between different configuration items. Information about the relationships between configuration items is necessary to conduct change impact analysis. Also, the maintenance of the software development folder is accomplished separately from the version control tool. Using a configuration item database, in conjunction with a version control system, provides a means to produce the reports necessary for conducting change impact analysis and configuration audits. The directed graph in Figure 1 shows a set of "uses" relations for Configuration Item A. Each item in the database
has a similar set of relations. A graph of the "used by" relations could be obtained by inverting the graph of the "uses" relations. The most important aspect of the CID is that each node in the graph does not necessarily need to correspond directly to a physical entity under version control. It could represent a composite object, a compiler, a hardware platform, or the individual responsible for maintaining a particular item.
A F D
Figure 1. Configuration item directed graph. The format in which the configuration item data is stored is extremely important to the functionality of the system. Configuration item dependencies are recorded in the database, enabling dependency reports, which show the possible effect of a change to a single item. The database stores these dependencies as a many-to-many relationship. It keeps track of the items that are used by a component while at the same time storing which items the component uses. Also, all versions of each configuration item should be saved to allow the change history to be traced. Figure 2 illustrates the complex relationships between configuration items within the CID. The configuration item data store holds information about various properties of configuration items. Project name, version number, date modified, location, and many other attributes relevant to the configuration item are stored in the database. The data store also holds the relationships between configuration items. A reference to the previous version of the item enables comparisons to different versions of the same item. A many-to-many relationship exists among configuration items in that each may depend on any number of other configuration items. Dependencies may also be mutual;
meaning item A might depend on item B where item B also depends on item A. These relationships can become very complex when a system consists of more than a few items. A hierarchy chart or class diagram is generally constructed in the design phase and is used only to denote the relationships of large components to the overall system. This chart leaves off many of the important configuration items such as header files and libraries. The resulting data structure, formed by the actual relationships between all of the configuration items within a piece of software, is recursive in that a simple traversal of the graph would result in repeated encounters of the same configuration items. Manual tracking of these relationships would be extremely difficult.
ated to address the issues of establishing a component library and tracking system. CMpro allows maintenance of configuration items that comprise an application and provides a means of tracking the relationship between these items. CMpro automatically maintains consistency of relationships between configuration items in the database both up and down. If item A is updated to depend on item C within the database, CMpro also adds the reverse dependency. This allows the user to traverse dependencies of configuration items in either direction, the items that depend on the current item or the items the current item depends upon. Once the configuration item database is constructed, it can be continually updated and maintained. This is a necessity due to the continual process of software modification. Each configuration item may have multiple versions, as does the configuration as a whole. In order to maintain a relation between the versions of the individual configuration items within the system and the version of the system as a whole, the database must be expanded to maintain a complete representation of the system across all versions of the software. This increases the complexity of the data structure within the configuration item database but provides a means to generate various meaningful reports. The user can navigate interactively through the configuration item database via the dependencies among the configuration items or display reports, such as a listing of all configuration items for a particular software version. Other reports include a list of all deliverables for a software version and a detailed report of a single configuration item, including its description and version information. By adding some simple additional queries to CMpro, one can enable users to retrieve the entire history or construct a dependency tree for a particular configuration item. This could be useful in both change impact analysis and determination of defect injection. CMpro is a client server application that was written to allow any number of separate projects to be run from the same server in separate databases. This feature opens the door for decomposition of larger products into separately managed pieces of software. This means that a single complex software project can be broken down so that each library, executable, or even data packages, could be split into separate databases with one database combining each of the project pieces into the whole. The level of abstraction is unlimited, catering very well to component based software development by allowing a component to be either maintained as a distinct software product or represented as a single configuration item within a larger software system.
Reference to previous version of Configuration Item *..1
Software version dependendent set of relations
Figure 2. Configuration Item Database Each configuration item has a one-to-one relationship with its previous version. These references are used to step through the history of an item to generate item history reports. This helps to provide tracking for threads of development across several versions of a component. 3 CMPRO PROTOTYPE A prototype CID system was recently developed in an attempt to incorporate characteristics desirable to a modern CM tool. Figure 2 illustrates the prototype configuration item database for the CMpro system, which was cre-
Two of the most important factors in determining the implementation of CMpro were platform independence and network multi-user access. Platform independence is important because software is developed on many different platforms and CASE tools should cater to these environments. Secondly, the network multi-user access is important because configuration management by definition assumes maintenance of a unique standardized set of components that comprise a piece of software. In a development environment where many developers are collaborating on a single project, there must be a common repository used to maintain a configuration. The solution to both issues was to implement CMpro as a software system that runs on a web server, thus providing the network multi-user access and catering to all platforms with Internet clients. This method also provides a common interface across platforms and simplifies the development of the application. In addition, by running CMpro as a web application, it can be used for distributed development from separate work sites. 4 FUTURE RESEARCH DIRECTIONS The CMpro prototype consists of a simple web interface to allow a user to construct and maintain a complete system of configuration items and their relationships. The CID was created as a stand-alone product, but it is not intended to be used by itself. It assumes a process based development environment with certain CASE tools already in place. Future research involves using CMpro in actual CBSD, refining the fields for configuration items and their relations and integrating CMpro with other tools. This investigation would begin by refining the database and deploying CMpro to actively maintain a real system. This would provide useful information needed to evaluate CMpro’s effectiveness as a CASE tool. CMpro records several types of information about each CI stored in the database. These fields include the CI name, description, version and other relevant information. The field types were chosen based on suspected usefulness. A deployed system would provide feedback to determine which additional fields would be useful and which fields could be removed. Another area of investigation involves integrating CMpro with a change control system. Change control is an integral part of a development environment in that decisions must be made in regard to which changes will be undertaken and which changes will not. All changes undertaken should be recorded to provide traceability of modifications made throughout the life of the product. CMpro currently has the ability to incorporate the recording of changes, but this could be extended to follow a specific process.
Another important investigation in continued development is interaction with a defect tracking system. The information necessary for assisting in defect tracking is inherently built into the CID. One of the main concerns in defect tracking is the determination of injection. By correlating the appearance of a defect with a specific version of the software, injection could be narrowed to the CIs in the system that had changed from the previous version. Once at this stage, the tool would be ready for widespread deployment. It would still run the risk of being neglected in many environments where deadlines and release dates often pressure developers to set process aside in the short term with the intention of retroactively filling in the process requirements. An additional integration with a version control system could help to ensure proper use of the tool by forcing CID updates to coincide with modifications to the Configuration Items within the version control system. Once CMpro was in use, it could be very easily extended to include an interface to an index of all items available for reuse. Each item within the CID already contains a complete description. The records for Configuration Items could be modified to include specific reuse information such as component type (e.g. data structure, communications interface, algorithm, etc.) as well as fields denoting the flexibility of the component. All of the necessary information for both a reuse index and a CID would be included in the same repository. The only difference is how the information is cross-referenced and made available to the user. Once in place, this type of system could have a dramatic impact on the development of CBSD systems. The CMpro system was developed with a process environment in mind and aims at assisting such an environment by automating the creation and maintenance of a CID. This provides a means of generating reports necessary to configuration audits and change impact analysis. To ensure the system performs as required, it should be deployed within a real environment and integrated with other CASE tools. This would provide a more thorough investigation regarding the use of a CID within CBSD. 5 CONCLUSIONS Component Based Software Development presents new challenges to CI management because developers no longer have complete control of the system. Configuration audits must account for items from outside sources. When a COTS component changes, a decision must be made on how to introduce the change. In some instances, the decision might be to use a comparable component from another vender. In order to make this decision, a change impact analysis must be conducted before any
subsequent cost-benefit analysis can be conducted. Manually maintaining a software development file becomes extremely tedious for a CBSD user. All of these issues revolve around maintaining a description of a system in terms of its components and their relationships to each other. There seems to be a void in this area of tools for Configuration Item Management. Version control tools provide a much-needed service of controlling access to CIs within a development environment. A problem arises however, when converting to CBSD where components are modified outside the immediate development environment. This presents new challenges to CI management because version control alone offers no safeguards against changes to COTS components. CMpro was written as a database for recording information about the CIs within a system without storing the actual items. This allows for flexible tracking of any CI whether internal, COTS or even hardware. This allows CMpro to generate full reports of the CIs within the system, useful when performing configuration audits. CMpro also maintains a set of relations between the CIs within the system providing the additional information needed to perform change impact analysis. The CMpro system could also be expanded to add additional features including an interface to a reuse library. This could make the process of evaluation much less expensive and time consuming by providing a directory of the components that are tested and already available. Once tested further to streamline the CID and the interaction with other CASE tools, CMpro might make an ideal addition to a CBSD environment by automating tasks that help to produce quality software. REFERENCES  IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (ANSI).  IEEE Std 828-1998, IEEE Standard Software Configuration Management Plans. (ANSI).  R. H. Berlack. Software Configuration Management. Wiley and Sons, New York. 1991.  Brown, A.W., Wallnau, K. “Engineering of Component Based System”. Proceedings 2nd IEEE Intl. Conf. on Eng. of Complex Computer Systems, Montreal. October 1996. pp 414-441.  Choi, K.J. Kim, K.B. Jin, S.L. "A Modelling Method of Software Configuration Change Control." IEEE(PACRIM'97), August 1997 pp.430-433.  Christensen, S. R. “Software Reuse Initiatives at Lockheed”. CrossTalk, May 1995. http://stc.hil.af.mil/CrossTalk/1995/may/Lockheed.asp.  Hall, R. J. “Generalized Behavior-based Retreival”. Proceedings of the 15th Intl Conf. On Software Eng, Baltimore. May 1993. pp 371-380
Larson, M. Applying Configuration Management Techniques to Component-based Systems. Licentiate Thesis MRTC, December 2000. M. D. McIlroy. “Mass Produced Software Components”. Report on a Conference sponsored by the NATO Science Committee. January 1969. pp 138155. Miller, T. C. “A schema for configuration management”. Procd of the 2nd Intl Workshop on Software configuration management. October, 1989, Princeton, NJ USA. Pages 26-29. National Oceanographic and Atmospheric Administration. “Configuration Management for the National Virtual Data System”. August 2000. http://126.96.36.199/NVDSCMdoc.html. Ploedereder, E. and Fergany, A. “The data model of the configuration management assistant”. Procd of the 2nd Intl Workshop on Software configuration management. October, 1989, Princeton, NJ USA. pp. 5-14. Pietrik, M. “Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework”. October 2000. MSDN Magazine. J. Voas, "COTS Software the Economical Choice?", IEEE Software, March/April 1998, pp. 16-19. Wallnau, K., Carney, D., Morris, E., Oberndorf, P., Buhman, C., “A Tutorial on the Theory and Practice of COTS Software Evaluation,” 20th Intl. Conf. on Software Eng., Kyoto, Japan, 1998 http://www.sei.cmu.edu/cbs/cbs_slides/98symposiu m/eval_tut/index.htm.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.