Wansition to a

Life Cycle Judith D. Ahrens Drexel University and Computer Command and Control Company

Noah S. Prywes University of Pennsylvania and Computer Command and Control Company

m Augmenting domain engineer-

ing with legacy software

reengineering can help an

organization move into the

software reuse mode.

fter several decades of discussion, the so-called software prob- lem is still with us. Characterized by high costs and long back - logs in software development and maintenance, this problem

can constrict an organization’s competitive posture. In business process reengineering, for example, software must be modified rapidly to reor- ganize business processes across administrative boundaries and to respond to marketing opportunities and changes in customer needs. Clearly, large development and maintenance backlogs diminish an orga- nization’s capacity to respond to these competitive demands.

Researchers in software engineering, business process improvement, and information engineering all want to drastically modernize software life-cycle processes and technologies to correct these problems and to improve the quality of software. Research goals have included ancillary issues, such as improving user services through conversion to new plat- forms and facilitating software processes by adopting automated tools. Automated tools for software development, understanding, maintenance, and documentation add to process maturity, leading to better quality and reliability of computer services and greater customer satisfaction.’

Recently, researchers have focused on achieving the above goals through organizational changes and methodologies for systematic soft- ware reuse.2 These methodologies are aimed at developing reusable build- ing blocks of adaptable software components from which application software can be constructed. The Software Productivity Consortium’for- malized the concepts of domain engineering, a process for developing a library of reusable software components for an application domain, along with those of application engineering, a process for assembling building blocks automatically into application software on the basis of a customer’s requirements. Similar concepts have also been described under the topic meg~programming.~

However, moving from present software practice4ominated by large, complex legacy applications with development and maintenance back- logs-to a future based on software reuse and automatic program gener- ation has proved very difficult. One problem is that the advocated transition methodologies require committed experts with extensive knowledge of both the application domain and the software technology. These experts are charged with progressively creating a computerized knowledge base of potential application requirements. Such a knowledge base would be supported by a library of adaptable, reusable software com- ponents and a set of decision rules and automated processes for selecting and assembling the components into the desired software application. This approach, which creates a domain and software reuse environment from scratch, has so far proved costly and risky, with long-delayed pay- back periods for recovering the initial investment.’

October 1995 0018-9162/95/$4 00 1995 IEEE

The essence of the approach we recommend is this: Given the appropriate enabling tools and properly functioning legacy software, domain and software knowledge can be extracted from legacy software and used to define applica- tion requirements and their supporting reusable software components. Legacy software processing then becomes a key catalyst for transitioning to a reuse-based approach for software production, reducing the cost and time of domain engineering.

Figure 1 presents an overview of this approach. Legacy software is one of the information resources for transi- tioning to the reuse-based mode of operation. The other two resources are domain and software experts. The approach separates domain and software expertise because the same individual is unlikely to have equivalent expertise in both areas. The range and depth of experi- ence assumed in the definition of domain knowledge sup- ports this expectation. Domain knowledge is defined3 as the knowledge and expertise characteristic of a domain; it includes relevant business considerations and strategies; scientific theory and engineering practice; capabilities and uses of existing systems; expertise in past system devel- opment, maintenance, and work products; potential developments in related or supporting technology; and potential changes in customer needs.

This article describes transition processes that offer an organization alternatives for deciding how to best migrate from current practice to software development and main- tenance based on technologies for software reuse and automatic program generation. The products of the tran- sition (see Figure 1) include a domain definition, domain specification, and domain architecture, as well as the code and documentation of reusable software components.

The strategy of reengineering legacy software to build a domain architecture and reusable software components reduces dependence on the domain expert, who repre- sents the scarcer resource. Automated tools for legacy code analysis assist in this strategy. With these tools, the soft- ware expert can, to a large extent, acquire and use the domain knowledge extracted from legacy software. However, we do not assume that all legacy software pro- vides a good base for the creation of domain components.

Only legacy software of good quality and reliability, whose functionality remains relevant to the present domain, should be selected for the extraction of reusable applica- tion components. Typically, most organizations possess some very large, complex, and reliable application soft- ware that functions satisfactorily for its users. This situa- tion represents an opportunity to move the software requirements, architecture definition, and code en masse to a domain repository. From there, these legacy software artifacts can be reused directly, added to previously defined reuse artifacts, or modified into new reuse arti- facts. The artifacts of legacy software are a key resource for defining the architecture of a software domain.

We present a generalized model of the software life cycle that recognizes explicitly the critical contribution of legacy software to the attainment of software production from reusable software components. The model defines information products of the software life cycle, denoted as states, leaving the choice of processes for moving between states open to various methodologies. Then we describe alternative methodologies for transitioning from current practices to the new software life cycle. This includes evaluation criteria for enabling an informed deci- sion concerning the selection of a transition methodology. Finally, the key to making the alternative transition methodologies feasible is the supporting automated envi- ronments. Our experience at integrating automated envi- ronments helps us to illustrate the transitions to, and operation within, the proposed software life cycle.

THE LEGACY- AND REUSE-BASED SOFTWARE LIFE CYCLE

Historically, software life-cycle models have not ade- quately represented software maintenance and reengi- neering processes, which today account for the vast majority of software labor costs.7 Nor have they been good at representing state-of-the-art concepts for radically improving software engineering practices, such as megapr~gramming,~ domain and application engineer- ing, and software reuse.3 These concepts and practices per- mit us to understand a software application as a product engineered, customized, and maintained from a product

family’s generic reusable components.

Resources Processes

Transition from current practice

to software development and

maintenance based on:

Reuse Automatic program generation

software

Products

Domain definition, specification, and

+ architecture (including use of modern computerkommunication technology) - Reusable components (code and documentation)

Automatic generation of + new application software

from reuse library

Figure 1. Overview of the transition to a legacy- and reuse-based software life cycle.

These customizable, reusable components provide the capabilities, functions, and behaviors needed in a definable business area, or domain, such as avionics or order processing.

The legacy and reuse software life cycle presented in Figure 2 incorporates these concepts. Rectangles represent life cycle product and information states. Transfor- mation processes, denoted by arrows, con- vert artifacts in one state to information products in a neighboring state. Forward transformations are represented by dotted lines, reverse transformations by solid lines. This software life-cycle model pro- vides the framework for later discussion of transition methodologies and enabling technologies. The model fits into the larger scope of the risk-oriented, iterative nature

1 Computer

of the spiral model originated by Boehm.K The spiral model also defines the information products produced at the con- clusion of a life cycle phase but leaves open the selection of methods for their attainment.

The software life-cycle model of Figure 2 integrates both top-down forward engineering and bottom-up reverse engineering processes for traversing the life cycle. Traversal is triggered when new information becomes available in one or more states and concludes when all states become consistent. For instance, assume that a cus- tomer’s new application requirements may be satisfied partly from reengineering legacy software and partly from creating new domain components. In this case, both for- ward and reverse engineering traversals occur. First, in a reverse traversal, the legacy software is reengineered (that is, analyzed, possibly translated, then restructured and redocumented) and included as reuse software in a reuse library. Software documentation, reverse engineered from the legacy software, can be used to update the informa- tion products of the design, architecture, and specifica- tion states. Then, a forward engineering traversal produces new software components. This traversal cre- ates information products for the requirements, compo- nent specification, architecture, design, and reuse software states. Forward engineering processes produce the new software components, which, when integrated with the legacy components, produce a customer’s new software application.

As stated earlier, we leave the processes involved in mov- ing between life cycle states open to alternative method- ologies. For example, prototyping may be used to validate customer requirements. The legacy and reuse software life cycle does not include a separate maintenance state, because the integrated forward and reverse engineering processes, supported by enabling technology, permit con- tinuous improvement of software processes and products. This life cycle model provides an integrated framework for processes involved in creating, maintaining, and evolving- over many years, possibly even decades-software domains that incorporate legacy software and utilize reuse libraries.

TRANSITION PROCESSES The legacy and reuse software life-cycle model

described above identifies information product states rather than the processes for moving between states. Now we focus on transitioning from current practices to the legacy and reuse software life cycle. In the following sec- tion, we describe software tools that enable the transition to the proposed software life cycle and support its ongo- ing operation after the transition.

The transition processes proposed here augment the synthesis methodology described in the Software Productivity Consortium’s document entitled Reuse-Driven Software Process Guidebook. Synthesis uses a top-down process for achieving reusable software and consists of domain and application engineering. We augment the domain engineering top-down process with a bottom-up domain reengineering process that reclaims value from legacy software. Figure A in the sidebar “Augmented methodology” illustrates both processes. As in Figure 1, input information is provided by domain and software experts, as well as by legacy software applications. Either

v 1

Requirements I

t v 4 Component specifications 4- - - - - - - - - - - +

t v Architecture 1. .. . . -. . . .. -4

+--+ I , I t v I

Applicationheuse software

4 ______..____....____-..

Transformed software x Legacy software

..... b Forward software engineering transformations Reverse software engineering transformations 0 Software life-cycle state

Requirements-Domain or application software requirements defined in terms o f functionality, capabilities, performance, user interface, inputs, and outputs.

Component specifications-Domain or application software requirements specified in terms o f capabilities o f hardware and software components and interfaces. This state is exemplified by the software specifications in Department of Defense Military Standard 498, ”Software Development and Documentation,” December 1994.

Architecture-The hierarchy of software components, rules for component selection, and interfaces between components.

Design-Program interfaces, control flow, and logic, defined in greater detail.

Applicationheuse software-In application software, a unique software product; in software reuse, a library of adaptable reusable software components. The reuse software components are tested, verified, and validated.

Transformed software-Legacy software restructured and trans- lated, if needed, into a modern programming language.

Legacy software-Application software created in a previous traversal of a software life cycle.

_ _ ~ igure 2. The legacy and reuse software l i f e cycle.

process can be used to create the desired products: a repos- itory populated by domain definitions, specifications, and architecture, as well as reusable software components and documentation artifacts. The bottom-up process is newly proposed here to augment the top-down synthesis methodology of domain engineering.

October 1995 1

The steps described in the text below correspond to those listed in Figure A.

Topdown domain engineering Step I: "Domain definition" defines3 the scope, extent,

feasibility, and cost justification for a domain. It includes a domain synopsis, glossary, assumptions, and status.

Step 2: "Domain specification" defines the product fam- ily for a domain used for application engineering. The domain specification includes a decision model, product family requirements, and a hierarchy of component require- ments. The decision model describes the abstract form (con- cepts, decisions, and structure) of an application modeling notation, as well as the criteria by which software compo- nents are selected, adapted, and composed into complete work products (applications) in the application engineer- ing process. Product requirements are identified through a process in which a family of similar systems are analyzed to discover the functions, capabilities, and characteristics shared in common (their commonalities) as well as the spe- cific ways in which they differ (their variabilities). The com- ponent requirements that are part of the product family are represented hierarchically. These processes produce information for the requirements and specification states in Figure 2 of the main text.

Step 3: "Domain design" includes the definition of an architecture, the design of components, and generation design. The architecture is a set of components adaptable for the applications of the domain. The architecture includes a set of relationships among components (for example, hier- archical structure, interfaces, communications, process dependencies, and databases). Existing off-the-shelf and legacy components may be included. Component design describes the internal logic, dataflow, and dependencies that define a program's behavior. Generation design is a process that specifies a procedure for mapping from a deci- sion model and product architecture to software compo- nents and documentation for an application. The procedure defines how to select, adapt, and compose components to create application software. This process produces infor- mation for the architecture and design states in Figure 2.

Step 4: "Domain verification" is a process for evaluating the consistency of a domain's requirements, specification, and design.

Step 5: "Domain implementation" is a component devel- opment activity for supporting application engineering pro- jects. This activity includes the implementation of adaptable components and application generation procedures. This step produces information and products for the applica- tionheuse software state of Figure 2.

Step 6: "Domain validation" evaluates the quality and effectiveness of application engineering process support from the perspective of application engineering project needs.

Bottomvp domain reengineering Step 7: "Legacy application software analysis and trans-

lation'' is a process that uses as input the software available from a legacy application. Legacy software analysis involves

automatic processes for discovering the hierarchical soft- ware components, their interfaces, and other relationships that define the software architecture. Software component and architecture documentation captures whatever require- ments can be extracted from program comments, as well as from existing legacy requirements documents. This step may also involve program language translation and restructur- ing. The legacy software understanding (and possibly trans- lation) produced during this process results in the transformed software state of Figure 2 .

Step 2: "Legacy application conversion" is a mostly man- ual process in which components from the legacy software are converted to use a modern operating system and mod- ern hardware. Documentation of the converted software components, including their architecture and requirements, is an automated process that also results in the transformed software state of Figure 2.

Step 3: "Augment or adapt reusable components" is first a process of identifying transformed legacy components suitable for reuse. Then, selected components are added to a software reuse library, and the components' requirements are used to update the domain specification. Alternatively, software components with requirements similar to those provided by legacy components may be found in the reuse library. These reuse components can be adapted to broaden their requirements to include those found in similar legacy components. Step 3 thus updates the information of the software reuse state of Figure 2.

Step 4: "Domain validation" is an evaluation process rather than a process for transitioning to a new state. A domain is validated through the creation of new applica- tion software from reusable components.

Step 5: "Update domain design" is a process that pro- duces information for the design and architecture states of the software life-cycle model in Figwre 2. Updated legacy software design specifications are created a t the overall architecture level and a t the reusable component level.

Step 6: "Update domain specifications" is a process that uses information produced for the design state to create manually the requirements' documentation for the soft- ware components. The decision model is also updated to include the requirements where legacy components were either used directly or restructured for adaptability, as in step 3. Decision rules are formulated for the range of cur- rent and anticipated variabilities.

Step 7: "Update domain definition" is a mostly manual process that uses as input the information produced from the component specification state of Figure 2, as well as knowledge of domain experts.

Step 8: "Domain verification" is a mostly manual evalua- tion process that uses information produced for the design, architecture, and specifications states to determine their consistency.

Application engineering Step 7: "Define customer's application software require-

ments" is a process in which an application model defining a customer's software requirements is developed via the notation and representation technique defined during

Augmented methodology

Computer

domain engineering. Development of the customer's appli- cation model produces in format ion fo r the requirements state of Figure 2.

Step 2: "Use rules i n decision model to select reusable components." In this process the application engineer uses as input the customer's application model and responds to questions posed by t h e decision model software. This

process uses information f rom the component specification state (e.g., component capabilities), the architecture state (e.g., component interfaces), and the design state (e.g., com- ponent logic and parameters) of Figure 2.

Steps 3, 4, and 5: These include processes to "generate appl icat ion software," "test appl icat ion software," and "generate application documentation," respectively.

1. Define customer's application software requirements

2. Use rules in decision model t o select ,

reusable components 3. Generate

application software

4. Test application software

5. Generate application documentation

cus

\ f I Application engineering

User requirements Auto. program generation Tool: Boeing SEE-KAMEL I

1

1 I

mer technology feedback

"Top-down domain

software engineering" process steps

1. Domain definition 2. Domain specification:

2.1 Decision model 2.2 Product

requirements 2.3 Component

requirements 3. Domain design:

3.1 Architecture 3.2 Components 3.3 Generation

design 1. Domain verification 5. Domain

implementation 5.1 Adaptable

components 5.2 Generation

procedures 5. Domain validation

6.1 Application engineering

Application engineerinq

process stem I \

Domain and software experts

L--

Legacy application

engineering

SEE-ROAMS

I

I Domain: /

Definition Specification Architecture Reuse library Documentation

" Bottom-up domain

software reengineering"

process steps

1. Legacy application analysis and translation 1.1 Components 1.2 Architecture 1.3 Documentation

2. Legacy application conversion (to new HW, OS, etc.) 2.1 Components 2.2 Architecture 2.3 Documentation

(incl. requirements)

(incl. requirements) 3. Augmentladapt

reusable components 3.1 Add legacy components t o reuse library

3.2 Adapt reusable components for legacy requirements

4.1 Create application software

5. Update domain design 5.1 Architecture 5.2 Components

6. Update domain specifications 6.1 Update component requirements

6.2 Update decision model

definition

verification

4. Domain validation

7. Update domain

8. Domain

Figure A. Augmented methodology processes and steps.

October 1995

The next process, application engineering, takes user requirements as input and produces an individual appli- cation as a product. The process steps are similar to those of the synthesis methodology.

The feedback loop in Figure A shows that both top-down and bottom-up processes can be interleaved and applied iteratively, incrementing the domain with each applica- tion of the process. Note that using the two processes in a different sequence will not necessarily lead to the same reuse library. Ultimately, however, the evaluation criteria for a reuse library should include the percentage of reuse code used in a new application, as well as the percentage of reuse components requiring modification to accom- modate a new application.6

When the top-down process alone is selected, it is driven by iterations for designated domain areas, after which appli- cation software may be obtained from these partial domains. In later iterations, smaller additions to the domain are needed to produce software for a new application. Giving precedence to domain increments that are central to the organization’s business helps the domain develop- ment because it determines earlier the main features of the domain architecture.

When combined top-down and bottom-up processes are selected, they are driven by iterations for extracting reusable legacy applications to produce domain increments. For

Domain applications 0

software . produced 0

. from A,-

A* - A, - reuse library

Time A A A

Completion of increment in domain architecture

Usable for new applications without

More economical i f domain is not

Advantages

legacy software

overly complex (a) Top-down approach

Domain i . . . ~ ~ ........_ ~ ......

applications 1 0

software ~

produced j 0

0

0

~ A 2 r from

library I ’ !A,!

t t t Time

Completion of adding legacy software application t o

domain architecture Advantages

Produces some applications software earlier Less reliance on scarce domain experts Saves on implementation by use of legacy

(b) Combined top-down and bottom-up approach

software components

Figure 3. Comparison of top-down approach (a) anc combined top-down and bottom-up approaches (b)

example, first a top-down process is used to define a high- level architecture. Then a bottom-up process is interleaved for filling in the detailed architectural levels. Application software can then be produced from the incremented domain. The time required to increment a domain for a legacy application is assumed to be proportional to the size and complexity of the legacy application software. Again, giving precedence to legacy applications that are central to the organization’s business will determine the overall domain software architecture.

Comparing top-down with combined top- down and bottom-up processes

Figure 3 illustrates the envisaged timing of payback for the top-down process by itself and for the combined top- down and bottom-up processes. The vertical axis repre- sents the fraction of applications that can be produced from the reuse library. The horizontal axis represents time. The dotted lines at the top of Figures 3a and 3b represent an assumed progression toward a state in which all appli- cation software production is from reusable components.

As shown, the top-down approach by itself requires sig- nificantly more time than the combined approach to com- plete the first domain increment of reusable software components for an application. This is assumed for two reasons: First, the top-down approach requires more input from human domain experts; second, the synthesis methodology3 requires the entire domain to be specified before applications are produced. Therefore, the desired domain increment is likely to cover more of the organiza- tion’s activity than the first requested software application requires. However, the top-down approach by itself has an advantage when developing a domain for which there is sufficient domain expertise but no legacy applications, or when the domain is not overly complex and can be well defined manually. The combined approach can more quickly add components from a legacy software applica- tion to the domain architecture, leading to faster and less expensive production of new software applications than the top-down approach. Additionally, the combined approach relies more on software experts extracting domain knowledge embedded in good legacy software, while the top-down approach depends on the present and historical domain expertise of the organization’s current employees. The combined approach thus reduces reliance on the scarcer resource.

In summary, the combined approach presents an alter- native for software managers that lets them more quickly achieve a domain software architecture increment capa- ble of producing new application software. Additionally, the combined approach economizes on the domain exper- tise needed to transition to reuse-based software life-cycle practices.

ENABLING TECHNOLOGY The processes in the top-down and bottom-up approaches

shown in Figure A require enabling technology to make the entire undertaking worthwhile. Automated tools must sup- port the human cognitive processes inherent in the steps described above, especially in the understanding of soft- ware. Many organizations are working on various aspects of this technology. One way to provide this support is to inte-

Computer

grate existing tools. Enabling technology is illustrated by three independently developed environments that were inte- grated to support the top-down and bottom-up processes and to populate the repositorywith domain artifacts. These environments are shown in Figure 4.

Here we describe how these environments support the processes in Figure A. The technology facilitating tool inte- gration has been described by B r ~ w n . ~ The tools described below use Digital’s DECdesign graphics and its metalan- guage to define the interactive protocols involved in human software understanding and to support the processes listed in Figure A. Graphical representation of software can enhance human software understanding because it relies on visual perception rather than on lan- guage. Nardi describes this and other aspects of software visualization technology.’O

Software Engineering Environment Boeing developed the Software Engineering

Environment” (SEE) under the Advanced Research Projects Agency (ARPA) Software Technology for Adaptable Reliable Systems (STARS) program. SEE was developed to support the human knowledge-intensive top- down processes in Figure A. Of special interest are the tools for definition, organization, and use of domain architec- tures, corresponding to the top-down process steps 1 through 6 of Figure A.

Domain information, including reuse software, is orga- nized into a hierarchical architecture and stored in a repos- itory. Each component in the hierarchy has a related specification that includes its position, requirements, inter- faces, and dependencies on other components.

The SEE repository tool, Reusable Object Access and Management System (ROAMS in Figure 5), includes facil- ities for constructing the domain glossary, cataloguing the domain’s contents, modeling the domain architecture, and defining decision rules for selecting application parame- ters. The ROAMS repository includes a library containing reuse artifacts.

The domain engineer works interactively with the Knowledge-based Application Model Evaluation Language (KAMEL in Figure 5) to develop rules for mapping an appli- cation’s requirements into related domain components.

KAMEL, an expert consultative system, is used in the application engineering transition processes shown in Figure A. KAMEL queries an application engineer about the application’s requirements. Using its ROAMS domain knowledge, KAMEL recommends specific components in the domain architecture.

Software Reengineering Environment The Software Reengineering Environment,” shown at

the bottom left of Figure 4, supports steps 1 through 8 in the bottom-up process of Figure A. The SRE was devel-

Software Specification Environment ( S E )

a f i e r Software t ‘i Application

requirements documents -mm

Application documents

t Application abstraction graphs, tables, and text

Application

I / Software Reengineering Environment (SRE)

Visualized application architecture

software

STARS (Boeing) Forward Software

Engineering Environment (SEE)

Domain engineer

Domain architecture specifications and

reuse artifacts

Application enaineer

lomain wtifacts ___,

Ipplicatior ;oftware ___+

Figure 4. Overview of integrated tools that enable the reengineered software life cycle.

October 1995

oped by Computer Command and Control Co. under the US Navy’s Engineering of Complex Systems and the Joint Logistic Commanders programs. (Documents are avail- able from the respective organizations.) It incorporates facilities for software translation, architecture discovery, visualization, documentation, and understanding. Figure 6 illustrates the SRE’s dataflow and capabilities. The SRE consists of two major parts, software restructuring and software understanding.

Software restructuring supports step 1 of the bottom- up process (Figure A), legacy-application analysis and translation. The legacy software is first parsed and then translated 100 percent, statement by statement, into entity-relation-attribute (ERA) diagrams of pseudo-Ada, called Elementary Statement Language Ada (ESL-Ada). If the legacy software is not already in Ada, as shown in Figure 6, SRE facilities can be used for automatic transla- tion from CMS-2 or Fortran. The ESL-Ada is a graphical

Function Tools

Project manager

9-

a-

Q-

Domain engineer

Application engineer

Documentation/ reports

Project E-mail communication

Interleaf, Amadeus, Denali

Office automation DECdecision, Interleaf

Domain engineering1 application engineering

Project management ~ DECplan

ROAMS, KAMEL

Process engine Process Engine, DECplan, Amadeus

Problem DECdesign-Ptech, understanding/ requirements definition manager

Design DECdesign-Ptech, Interface definition, design hierarchy

Evaluation and DEC Source verification Code Analyzer

Configuration management

Version control, problem manager, baseline support

4

representation in which the statements form nodes and the relations form edges. The relations/edges between software statements include

scope or precedence, variable reference to or from variable declaration, procedure caller to procedure called, input/output to or from files, message entry caller to task entry called, type or generic to instantiation, and with/use to respective package.

Nodes and edges contain related attributes. Sofhvare understanding is achieved through graphical

representation and manipulation. First, the legacy soft- ware architecture is discovered by a user-guided procedure for partitioning the software into multilevel hierarchical components. Along with detailed graphs of individual com-

Processes

Project and process management

Domain and application engineering

Information resource management and control

Figure 5. Tools incorporated in the BoeinglSTARS Software Engineering Environment (SEE).

- - ponents, the SRE generates a map describ- ing the overall architecture. The tree- structured map displaying the hierarchy of components facilitates understanding of the software’s overall architecture. Individual component diagrams enable a software engineer to examine each com- ponent’s detailed design. For example, a hierarchical architecture diagram for a component is generated from the edges of the scope and precedence relations; a dataflow diagram is generated from nodes containing instantiations of variables, pro- cedures, tasks, and I/O files, and from edges representing procedure calls, I/O messages, and variable references. Textual reports list each component’s code and interfaces. A query language is also pro- vided for ad hoc graphical browsing. When a user selects the node and edge types, a graph is displayed containing only those nodes and edges. For example, selecting procedure nodes and procedure call edges produces a procedure call tree. This lets the software engineer selectively and progres- sively achieve software understanding by focusing on one aspect of the software at a time.

Component diagrams facilitate under- standing of the detailed code. These and other software documentation diagrams shown in Figure 6 are stored in the SRE’s graphics repository. Additionally, an entire tree or subtree of components can be trans- ferred to either the Software Specification Environment (SSE) repository or to the Software Engineering Environment (SEE) repository.

These diagrams and the SSEs repository of past documents (discussed below) facili- tawthe further specification of components derived from human or documentation resources.

The SRE, with the additional informa-

Computer

tion from the SSE, lets a software engineer learn and restructure the domain in a pro- gressive, logical fashion. By comparing the capabilities of components in the hierar- chy, the software engineer can identify those components that need modification. Specifying rules for the decision model for mapping application requirements to reusable software components can be facil- itated by the search and retrieval facilities of the SSE and SRE repositories.

Software Specification Environment

The Software Specification Environ- ment (SSE), by the developers of the SRE,

Legacy Software software restructuring

n n i Analysis

Graphic representations

Parsers allocation Translators (in CMS-2,

Fortran) Relationships and interfaces

Fortran Restructuring

Software understanding

Documentation

Dataflow Interfaces Objects

dependency

Graphic repository

supports processes that develop and up- date information for the requirements, specification, architecture, and design states of the life cycle shown in Figure 2. Figure 7 shows the SSE in more detail. A document administrator uses the Document Manager subsystem to load and catalog into its repository possibly thousands of pages of historical documents, including the legacy software’s preliminary requirements and software spec- ifications. A supervisor uses the Assignment Manager subsystem to plan, allocate work assignments, and con- trol the work of staff engaged in producing specifications. Specifiers review their assignments and, assisted by the Step-by-step subsystem, search for, retrieve, compose, annotate, and store component documents. Key dia- grams and text generated by the Software Reengineering

Figure 6. Architecture and capabilities of the Software Reengineering Environment (SRE).

motivated the decision to interleave the bottom-up process. Legacy Ada software for the environment seg- ment of the F-15 aircraft simulator was processed by the Software Reengineering Environment to reengineer the environment segment of the aircraft trainers domain. Similarly, Fortran legacy code for simulating propulsion for aircraft is used in the propulsion segment of the air- craft trainers domain.

MAJOR IMPEDIMENTSTO THE ADOPTION and diffusion of the domain/reuse paradigm using the top-down process

Environment are inserted into the Software Specification Environment repository (Figure 4). The documents generated by the SRE include overall com- ponent architecture diagrams, and for each component, a dataflow diagram, an interface table, and comments text for deriving software capabilities. These loaded documents and the SRE diagrams are used in the bottom-up process step 5 for annotating the component design, and in step 6 for annotating the domain spec- ifications, as shown in Figure A.

AN APPLICATION EXAMPLE An ongoing project for the domain of

Navy aircraft trainers at the US Naval Air Weapon Center, Training Systems Division, exemplifies the application of these inte- grated environments and of the transition processes we have described. In this pro- ject, the top-down process using the Soft- ware Engineering Environment resulted in a high-level domain architecture consist- ing of 12 segments (flight station, flight controls, flight dynamics, propulsion, envi- ronment, and so forth) interconnected by a virtual network. However, development of lower level components using the top- down process progressed very slowly. This

Historical Software documents, Specification

(preliminary and Environment earlier versions)

Document I I artifacts:

requirements specifications

(498: SISS, SISDD, SRS,

IRS) I I -

by Software Reengineering Environment (architecture,

Assignment Manager

and comments)

Step-by-step I

Figure 7. Overview of the Software Specification Environment (shaded boxes represent SSE subsystems).

October 1995

alone include the large start-up effort and expense involved in constructing a domain architecture and com- ponents for the software reuse library. The combined process can mitigate this expense by leveraging the domain knowledge encapsulated in legacy software ap- plications. Such knowledge transfer can leverage an organization’s long-term experience by reducing its dependence on the domain knowledge of its current staff. The benefits of leveraging legacy application software knowledge include shortening the learning curve for cur- rent staff and reducing the lead time for generating new software applications.

The cost of developing software for even a few applica- tions using a conventional methodology should approxi- mately equal the cost of developing the domain reuse components from legacy software and generating the applications from them. The payoff comes in the declin- ing incremental costs of engineering new applications from reusable components.

In the future, new application requirements and tech- nological advances can be expected to drive domain evo- lution, generating a continuous process of domain analysis and domain architecture restructuring. Domain and reuse library artifacts will be continually created and restruc- tured to produce new software product inventories for use in expanded or reorganized domains. As new program- ming languages and platforms are introduced, we will increasingly be concerned with reengineering selected reuse library components rather than reengineering entire legacy software applications. I

Acknowledgments The following individuals provided valuable ideas pre-

sented in this article: Jonathan Schug and Paul Rehmet of Computer Command and Control Co., Philadelphia, and John Neorr and Sandra Pinkney of Boeing Corp., who inte- grated the SRE and SEE and applied them in pilot projects. The SSE work by Computer Command and Control was sponsored by the Joint Logistic Commanders under con- tract N00014-90-C-0160. The SRE work was sponsored by the Naval Surface Warfare Center under contract N60921- 90-C-0298. Integration of the SSE and SRE into the Boeing STARS SEE was sponsored by the ARPWSTARS program under contract N60921-92-C-0196.

References ~. . .-

1. W. Hefley, “The Cobbler’s Children: Applying Total Quality Management to Business Process Improvement, Information Engineering, and Software Engineering,” Software Eng. Notes, Vol. 18, No. 4, Nov. 1993, pp. 19-26.

2. W. Schaefer, R. Prieto-Diaz, and M. Matsumoto, eds., Soft- ware Reusability, Ellis Horwood, New York, 1994.

3. SPC Services Corp., Reuse-Driven SoftwareProcess Guidebook, SPC-92019-CMC, Version 02.00.03, Nov. 1993.

4. G. Wiederhold, P. Wegner, and S. Ceri, “Toward Megapro- gramming,” Comm. ACM, Vol. 35, No. 11,1992, pp. 89-99.

5. R. Joos, “Software Reuse at Motorola,” IEEE Software, Vol. 11, No. 5, Sept. 1994, pp. 42-47.

6. W. Lim, “Effects of Reuse on Quality, Productivity, and Eco- nomics,”IEEESoftware,Vo~. 11, No. 5, Sept. 1994, pp. 23-30.

~

7. J. Ahrens, N. Prywes, and E. Lock, “Software Process Reengi- neering: Toward a New Generation of CASE Technology,”J. Systems and Software, Vol. 30, Nos. 1 and 2, July-Aug. 1995,

8. B. Boehm, “A Spiral Model for Software Development and Enhancement,” Computer, Vol. 21, No. 2, Feb. 1988, pp. 61- 72.

9. A. Brown et al., Principles o fCASE Tool Integration, Oxford Univ. Press, New York, 1994.

10. B. Nardi, A Small Matter ofProgramming, MIT Press, Cam- bridge, Mass., 1994.

11. Boeing Corp. Defense Space Group, Integrated SEE Descrip- tion-SEE Reference Manual, Boeing Systems and Software Eng., POB 3997, N/S 87-37, Seattle, Wash., 1993.

12. Computer Command and Control Co., SE-SEEIntegrated Environment User’s Guide, Version 6.0, 2300 Chestnut St., Philadelphia, Pa., 19103, Jan. 1995.

pp. 71-84.

Judith D. Ahrens is a n assistantprofessor a t the College of Information Science and Technology, Drexel University, Philadelphia. She has worked a t programming, analysis, design, consulting, and management of systems development projects forPhiladelphia area companies. Her research inter- ests include evaluation of software and database develop- men t methodologies and CASE tools, business process reengineering technology, groupware technology, and infor- mation systems fo r competitive advantage.

Ahrens received a PhD in computer and information sci- encesfrom Temple University, Philadelphia, in 1989 and a n M B A f r o m Widener University, Chester, Pennsylvania, in 1978. A certified systems professional since 1985, she is on the editorial boards of Database Management and the Jour- nal of Global Information Management. Ahrens is a mem- ber of the IEEE.

N o a h S. Prywes is professor of computerscience a t the Uni- versity ofPennsylvania, Philadelphia. His recent research interests have been in the area ofprocessing legacysoftware, software reengineering, component-based software, and soft- ware reuse. He has been teaching and conducting research and development in computer architecture and operating systems. He received a BSEEfrom Technion, Israel, in 1949, a n MSEEfrom the Carnegie Institute of Technology in 1951, and a PhD in appliedphysicsfrom Harvard University i n 1954. He is a fellow of the ZEEE.

Ahrens can be reached a t the College of Information Science and Technology, Drexel University, 33rd and Market Streets, Philadelphia, PA 19104; e-mail ahrensjd@duvm.ocs. drexel.edu. Prywes can be contacted a t University of Penn- sylvania, School of Engineering and Applied Science, Depart- ment of Computer and Information Science, 200 South 33rd St., Philadelphia, PA 19104-6389; e-mail nsp@central.cis. upenn.edu.

Howard Rubin, Computer’s software metrics area editor, coordinated the review of this article and recommended it f o r publication. His e-mail address is 71031.377@com- puserve. com.

Computer