8/14/2019 icse2001

1/6

Controlling Configuration Items in

Component Based Software Development

Carl S. Lebsack, Austin J. Mroczek, Carl J. Mueller

Computer Science Department

Illinois Institute of TechnologyChicago, IL 60616 USA

lebscar@iit.edu, mrocaus@iit.edu, mueller@iit.edu

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 data-

base. 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, con-

figuration management, configuration item.

1 INTRODUCTION

In 1968 NATO sponsored the first conference on Soft-

ware Engineering to discuss why there was a gap betweenthe systems that were being proposed and those that were

being successfully implemented. One of the papers intro-

duced at this conference formalized the notion of mass

produced software [9]. To accomplish his concept of

mass-produced software, McIlroy proposed reuse of com-

ponents to build new applications. Although the discus-

sion that followed the presentation was generally positive,

nothing of significance was done to implement this con-

cept until the cold war ended. At that time, NATO gov-

ernments 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 [6] and Component

Based Software Development (CBSD) [4] evolved out of

the need to reduce development costs. Domain Engineer-

ing 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 sat-

isfy the requirements for a specific application but aregeneral enough in nature to be reused in other applica-

tions. Component Based Software Development reduces

software development costs through the reuse of previ-

ously 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 identifi-

cation of the available components. Development organi-

zations frequently spend a large amount of time develop-

ing 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. Con-

structing a database identifying the properties of each

component would reduce the search time significantly [7].

Another problem with CBSD is the effort required in

building a reuse library. It could take a number of yearsto 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 com-

ponents. Software purchased from an outside source is

known as Commercial Off-The-Shelf or COTS software.

Using COTS software for a traditional development envi-

ronment has advantages and disadvantages [14]. Advan-

tages of using COTS components are: functionality is

8/14/2019 icse2001

2/6

instantly accessible; they cost less than in-house devel-

opment; and they frequently are built by problem domain

experts. Disadvantages of developing with COTS com-

ponents are: limited documentation is provided; there is

no guarantee of adequate testing; portability is not guaran-

teed; limited or no source code access is provided.

Traditionally, the only COTS software components usedin an application were compilers, database managers, and

operating systems. Occasionally, some components sup-

porting communications protocols or special device inter-

faces were also included. Most of the components of new

systems were developed in-house or under special con-

tracts 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 [2], COTS

components are addressed under the heading subcontrac-

tor and vendor control; but not much direction is provided

to deal with the issues of COTS components.

New development environments and tools have added tothis problem. Many of the newer programming and

scripting languages require source distribution or a pre-

compiled middle language like Javas 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.

Microsofts new .net framework is adding to these diffi-

culties with its Just-In-Time (JIT) environment. The .net

framework is being proposed as a solution to version and

interface problems with DLLs [13]. The primary con-

figuration management problem with COTS components,

in all forms, is controlling a configuration when individ-

ual components are outside of that control. A developermay 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 com-

ponent 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)

[3]. A configuration item is defined as a collection of

hardware and software that is designated for configuration

management [1]. 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 docu-

ments, source code, test cases, and review documents areall configuration items that shape the resultant piece of

software. Any time a single configuration item is modi-

fied, it splits into two distinct items: the original version

and the newly created version. The purpose of configura-

tion 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 accom-plished 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 configura-

tion items are not automatically tracked and must be ac-

counted for manually. Configuration items, such as com-

pilers, 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 us-

ing Component Based Software Development is that there

is an additional phase for evaluation that occurs after the

requirements phase and before the components are inte-grated into the application [4]. The Software Engineering

Institute (SEI) defines six different types of evaluations

that should be performed when selecting a COTS compo-

nent [15]. Four of these evaluations are technical or re-

quire technical information to complete them. Conduct-

ing these evaluations is usually extremely time consum-

ing, 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 harnessthat supports verification and validation reports, the har-

ness used to evaluate the prospective components under

consideration should also fall under configuration item

management. The question of how CBSD affects the con-

figuration management process affects almost every con-

figuration 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 aCBSD environment?

How is a Software Development File [3] main-

tained in such a dynamic environment?

All of these questions revolve around configuration items

and their relationships to each other. There are two spe-

cific relationships that are critical in a CBSD environ-

8/14/2019 icse2001

3/6

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 databaseis not a new concept for automating status accounting and

auditing tasks [5, 8, 10, 11, 12]. A configuration man-

agement database is a composite of a number of databases

consisting of change control, defect tracking, version con-

trol and configuration item tracking. It is the Configura-

tion Item database that we feel can address some of the

configuration management problems in a CBSD environ-

ment.

Many companies use the Software Development File

(SDF), formerly called the Unit Development Folder, to

hold all information about a given piece of software [3].

This file contains the items history of changes, audits,

test reports, and other valuable information. The contentsof the SDF are very similar to the types of information

found in a Product Data Management (PDM) file. Soft-

ware 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 deter-

mine 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 elimi-

nates 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 con-

figurations. The primary purpose of version control sys-

tems is to ensure only one person is modifying a docu-

ment 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. In-

formation about the relationships between configuration

items is necessary to conduct change impact analysis.

Also, the maintenance of the software development folderis 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" rela-

tions 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 con-

trol. It could represent a composite object, a compiler, a

hardware platform, or the individual responsible for main-

taining a particular item.

A

B

D

C

E

F

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 da-

tabase, enabling dependency reports, which show the pos-

sible effect of a change to a single item. The database

stores these dependencies as a many-to-many relation-

ship. It keeps track of the items that are used by a com-

ponent 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 rele-

vant to the configuration item are stored in the database.The data store also holds the relationships between con-

figuration 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;

8/14/2019 icse2001

4/6

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 sys-

tem. This chart leaves off many of the important configu-

ration items such as header files and libraries. The result-

ing data structure, formed by the actual relationships be-

tween 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 relation-

ships would be extremely difficult.

ConfigurationItem

Depends On

Software versiondependendentset of relations

Reference toprevious version ofConfiguration Item

*..1

*..1

*

*

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 his-

tory reports. This helps to provide tracking for threads ofdevelopment 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 mod-

ern CM tool. Figure 2 illustrates the prototype configura-

tion item database for the CMpro system, which was cre-

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 relation-

ships between configuration items in the database both upand down. If item A is updated to depend on item C

within the database, CMpro also adds the reverse depend-

ency. This allows the user to traverse dependencies of

configuration items in either direction, the items that de-

pend on the current item or the items the current item de-

pends upon.

Once the configuration item database is constructed, it

can be continually updated and maintained. This is a ne-

cessity due to the continual process of software modifica-

tion. Each configuration item may have multiple ver-

sions, 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 ofthe 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 complex-

ity of the data structure within the configuration item da-

tabase but provides a means to generate various meaning-

ful reports.

The user can navigate interactively through the configura-

tion item database via the dependencies among the con-

figuration 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 soft-

ware version and a detailed report of a single configura-

tion item, including its description and version informa-

tion. 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 configura-

tion 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 besplit 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 rep-

resented as a single configuration item within a larger

software system.

8/14/2019 icse2001

5/6

Two of the most important factors in determining the im-

plementation of CMpro were platform independence and

network multi-user access. Platform independence is

important because software is developed on many differ-

ent platforms and CASE tools should cater to these envi-

ronments. Secondly, the network multi-user access is

important because configuration management by defini-

tion assumes maintenance of a unique standardized set of

components that comprise a piece of software. In a de-

velopment environment where many developers are col-

laborating 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 net-

work 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 develop-

ment from separate work sites.

4 FUTURE RESEARCH DIRECTIONSThe CMpro prototype consists of a simple web interface

to allow a user to construct and maintain a complete sys-

tem 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 al-

ready 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

CMpros 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 addi-

tional 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 inte-

gral part of a development environment in that decisions

must be made in regard to which changes will be under-taken and which changes will not. All changes under-

taken should be recorded to provide traceability of modi-

fications 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 develop-

ment 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 ver-

sion of the software, injection could be narrowed to the

CIs in the system that had changed from the previous ver-

sion.

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 proc-

ess requirements. An additional integration with a ver-

sion control system could help to ensure proper use of the

tool by forcing CID updates to coincide with modifica-

tions to the Configuration Items within the version control

system.

Once CMpro was in use, it could be very easily extendedto 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 envi-

ronment in mind and aims at assisting such an environ-

ment by automating the creation and maintenance of a

CID. This provides a means of generating reports neces-

sary 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 nolonger have complete control of the system. Configura-

tion 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

8/14/2019 icse2001

6/6

subsequent cost-benefit analysis can be conducted.

Manually maintaining a software development file be-

comes extremely tedious for a CBSD user. All of these

issues revolve around maintaining a description of a sys-

tem in terms of its components and their relationships to

each other.

There seems to be a void in this area of tools for Configu-ration 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 modi-

fied 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 hard-

ware. This allows CMpro to generate full reports of the

CIs within the system, useful when performing configura-tion audits. CMpro also maintains a set of relations be-

tween the CIs within the system providing the additional

information needed to perform change impact analysis.

The CMpro system could also be expanded to add addi-

tional features including an interface to a reuse library.

This could make the process of evaluation much less ex-

pensive 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 interac-

tion with other CASE tools, CMpro might make an ideal

addition to a CBSD environment by automating tasks that

help to produce quality software.

REFERENCES

[1] IEEE Std 610.12-1990, IEEE Standard Glossary of

Software Engineering Terminology (ANSI).

[2] IEEE Std 828-1998, IEEE Standard Software Con-

figuration Management Plans. (ANSI).

[3] R. H. Berlack. Software Configuration Manage-

ment. Wiley and Sons, New York. 1991.

[4] Brown, A.W., Wallnau, K. Engineering of Compo-

nent Based System. Proceedings 2nd

IEEE Intl.

Conf. on Eng. of Complex Computer Systems,

Montreal. October 1996. pp 414-441.

[5] Choi, K.J. Kim, K.B. Jin, S.L. "A Modelling

Method of Software Configuration Change Con-

trol." IEEE(PACRIM'97), August 1997 pp.430-433.[6] Christensen, S. R. Software Reuse Initiatives at

Lockheed. CrossTalk, May 1995.

http://stc.hil.af.mil/CrossTalk/1995/may/Lock-

heed.asp.

[7] Hall, R. J. Generalized Behavior-based Retreival.

Proceedings of the 15th Intl Conf. On Software Eng,

Baltimore. May 1993. pp 371-380

[8] Larson, M. Applying Configuration Management

Techniques to Component-based Systems. Licenti-

ate Thesis MRTC, December 2000.

[9] M. D. McIlroy. Mass Produced Software Compo-

nents. Report on a Conference sponsored by the

NATO Science Committee. January 1969. pp 138-

155.

[10] Miller, T. C. A schema for configuration manage-

ment. Procd of the 2nd Intl Workshop on Software

configuration management. October, 1989, Prince-

ton, NJ USA. Pages 26-29.

[11] National Oceanographic and Atmospheric Admini-

stration. Configuration Management for the Na-

tional Virtual Data System. August 2000.

http://140.90.236.89/NVDSCMdoc.html.

[12] 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.

[13] Pietrik, M. Avoiding DLL Hell: Introducing Ap-plication Metadata in the Microsoft .NET Frame-

work. October 2000. MSDN Magazine.

[14] J. Voas, "COTS Software the Economical Choice?",

IEEE Software, March/April 1998, pp. 16-19.

[15] 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.

http://stc.hil.af.mil/http://stc.hil.af.mil/http://140.90.236.89/NVDSCMdoc.htmlhttp://www.sei.cmu.edu/cbs/cbs_slides/98symposium/eval_tut/index.htmhttp://www.sei.cmu.edu/cbs/cbs_slides/98symposium/eval_tut/index.htmhttp://www.sei.cmu.edu/cbs/cbs_slides/98symposium/eval_tut/index.htmhttp://www.sei.cmu.edu/cbs/cbs_slides/98symposium/eval_tut/index.htmhttp://www.sei.cmu.edu/cbs/cbs_slides/98symposium/eval_tut/index.htmhttp://140.90.236.89/NVDSCMdoc.htmlhttp://stc.hil.af.mil/