icse2001
TRANSCRIPT
-
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
[email protected], [email protected], [email protected]
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/