Week-9: Re-engineering Concepts

Software Re-engineering
(SREE)
Course Code: SESE4183

Taimoor Hassan
Senior Lecturer (SE), FOIT
taimoor.hassan01@ucp.edu.pk
4.4.2 Source Code Reengineering Reference Model

• The SCORE/RM model was proposed by

Colbrook, Smythe and Darlison.
• The framework, depicted in Figure, consists of
four kinds of elements:
– function,
– documentation,
– repository database, and
– metrication.
• The function element is divided into eight
layers, namely:
– encapsulation, transformation,
– normalization, interpretation,
– abstraction, causation, Figure 4.6 Source code reengineering
– regeneration, and certification. reference model © IEEE, 1990
4.4.2 Source Code Reengineering Reference Model

• The eight layers provide a detailed approach to:

(i) rationalizing the system to be reengineered by removing redundant data and alteringe
control flow,
(ii) comprehending the software’s requirements, and
(iii) reconstructing the software according to established practices.
The first six of the eight layers together constitute a process for reverse engineering,
and the final three a process for forward engineering.
• Improvements in the software as a result of reengineering is quantified by means
of the metrication element.
• The metrication element is described in terms of the relevant software metrics
before executing a layer and after executing the same layer.
• The repository database is the information store for the entire reengineering
process, containing the following kinds of information:
– metrication,
– documentation, and
– both the old and the new source code.
4.4.2 Source Code Reengineering Reference Model
• The interfaces among the elements are shown in Figure.
• For simplicity, any layer is referred to as (N)− layer, while its next lower and
next higher layers are referred to as (N − 1)− layer and the (N + 1)− layer,
respectively.
• The three types of interfaces are explained as follows:
• Metrication/Function: (N)-MF – the structures describing the metrics and their values.
• Documentation/Function: (N)-DF – the structures describing the documentation.
• Function/Function: (N)-FF – the representation structures for source code passed
between the layers.

Figure 4.7 The interface nomenclature © IEEE, 1990

 • The phase
4.4.3 Phase Reengineering Model

Figure 4.8 Software reengineering

model of
process phases © IEEE, 1992

software
reengineering
was originally
proposed by
Byrne and
Gustafson.
• The model
comprises five
phases: analysis
and planning,
renovation,
target system
testing,
redocumentatio
n, and
acceptance
testing and

and tasks can be further decomposed

to reveal the detailed methodologies.
• Tasks represent a phase’s activities,
system
transition, as
depicted in
Figure 4.8.

represented by each phase.

• A major process activity is
• The labels on
the arcs denote
the possible
information that
flows from the
tail entities of
the arcs to the
head entities.
 Analysis and planning:
4.4.3 Phase Reengineering Model

• Analysis addresses three technical and one

economic issue.
• The first technical issue concerns the present state
of the system to be reengineered and
understanding its properties.
• The second technical issue concerns the
identification of the need for the system to be
reengineered.
• The third technical issue concerns the specification
of the characteristics of the new system to be
produced.
• The economic issue concerns a cost and benefit
analysis of the reengineering project.
• Planning includes:
• understanding the scope of the work;
• identifying the required resources;
• identifying the tasks and milestones;
• estimating the required effort; and
• preparing a schedule.
4.4.3 Phase
Reengineering
Model
 Renovation:
4.4.3 Phase Reengineering Model

• An operational system is modified into the target

system in the renovation phase.
• Two main aspects of a system are considered in
this phase:
(i) representation of the system.
It refers to source code, but it may include the
design model and the requirement specification
of the existing system.
(ii) representation of external data.
It refers to the database and/or data files used by
the system. Often the external data are
reengineered, and it is known as data
reengineering.
• An operational system can be renovated in many
ways, depending upon the objectives of the
project, the approach followed, and the starting
representation of the system.
• It may be noted that the starting representation
can be source code, design, or requirements.
• Table 4.1 discussed earlier recommends several
alternatives to renovate a system.
 Renovation:
Example
• A project in which the
objective is to re-code
the system from Fortran
Figure 4.9 Replacement strategies for recording

to C.
• Figure 4.9 shows the
three possible
replacement strategies.
• First, to perform source-
to-source translation,
program migration is
used.
• Second, a high-level
design is constructed
from the operational
source code, say, in
Fortran, and the
resulting design is re-
implemented in the
target language, C in this
case.
• Finally, a mix of
compilation and
4.4.3 Phase Reengineering Model

decompilation is used to
obtain the system
implementation in C
 Target system testing:
4.4.3 Phase Reengineering Model

• In this phase for system testing,

faults are detected in the target
system.
• Those faults might have been
introduced during reengineering.
• Fault detection is performed by
applying the target system test
plan on the target system.
• The same testing strategies,
techniques, methods, and tools
that are used in software
development are used during
reengineering.
• For example, apply the existing
system-level test cases to both
the existing and the new system.
• Assuming that the two systems
have identical requirements, the
test results from both the
scenarios must be the same.
4.4.3 Phase Reengineering Model

Redocumentation:
• In the redocumentation phase,
documentations are rewritten, updated,
and/or replaced to reflect the target system.
• Documents are revised according to the
redocumentation plan.
• The two major tasks within this phase are:
(i) analyze new source code, and
(ii) create documentation.
• Documents requiring revision are:
• requirement specification.
• design documentation.
• a report justifying the design decisions,
assumptions made in the implementation.
configuration.
• user and reference manuals.
• on-line help.
• document describing the differences between
the existing and the target system.
 Acceptance and system
4.4.3 Phase Reengineering Model

transition:
• In this final phase, the reengineered
system is evaluated by performing
acceptance testing.
• Acceptance criteria should already
have been established in the
beginning of the project.
• Should the reengineered system
pass those tests, preparation begins
to transition to the new system.
• On the other hand, if the
reengineered system fails some
tests, the faults must be fixed; in
some cases, those faults are fixed
after the target system is deployed.
• Upon completion of the acceptance
tests, the reengineered system is
made operational, and the old
system is put out of service.
• System transition is guided by the
prior developed transition plan.
 • Reverse engineering was first applied in electrical
engineering to produce schematics from an
electrical circuit.
4.5 Code Reverse Engineering

• It was defined as the process of developing a set

of specifications for a complex hardware system
by an orderly examination of specimens of that
system.
• In the context of software engineering, Chikofsky
and Cross II defined reverse engineering as a
process to:
(i) identify the components of an operational software.
(ii) identify the relationships among those components.
(iii) represent the system at a higher level of abstraction
or in another form.
• Reverse engineering is performed to achieve two
key objectives:
• redocumentation of artifacts
• It aims at revising the current description
of components or generating alternative
views at the same abstraction level.
Examples of redocumentation are pretty
printing and drawing CFGs.
• design recovery
• It creates design abstractions from code,
expert knowledge, and existing
documentation.
4.5 Code Reverse Engineering

•
in
er
e
n
gi
n
e
re
g,
in
er
e
n
gi
n
e
d
ar
w
r
fo
n
e
e
w
et
b
p
hi
s
n
o
ti
la
re
e
h
T
Figure 4.10 Relationship between reengineering and reverse engineering ©IEEE, 1990
 • Six objectives of reverse engineering, as identified
by Chikofsky and Cross II:
• generating alternative views.
• recovering lost information.
• synthesizing higher levels of abstractions.
• detecting side effects.
• facilitating reuse.
• coping with complexity.
• Six key steps in reverse engineering, as
documented in the IEEE Standard for Software
Maintenance, are:
• partition source code into units.
• describe the meanings of those units and identify the
functional units.
• create the input and output schematics of the units
identified before.
• describe the connected units.
• describe the system application.
• create an internal structure of the system.
• The first three of the six steps involve local
analysis, the rest involve global analysis.
4 .5 C o d e R e v e rs e E n g in e e rin g
4.5 Code Reverse Engineering
Reverse engineering has been effectively applied in the following problem areas:

• computing change impact

• aspect-oriented software development
• cleaning up code smells
• detecting duplications and clones
• deriving conceptual data models
• finding objects in procedural programs

• building traceability between code and

• recovering design patterns
• discovering design architectures,
• identifying reusable assets
• redocumenting programs
• transforming binary code into source
code

documentation
• redesigning user interfaces
• parallelizing largely sequential programs
• translating a program to another language
• migrating data
• extracting business rules
• wrapping legacy code
• auditing security and vulnerability
• extracting protocols of network
applications
4.5 Code Reverse Engineering
• A high level organizational paradigm is found to be useful while setting up a
reverse engineering process, as advocated by Benedusi et al.

• The high level paradigm plays two roles:

(i) define a framework to use the available methods and tools, and
(ii) allow the process to be repetitive.

• The paradigm, namely, Goals/Models/Tools, which partitions a process for

reverse engineering into three ordered stages: Goals, Models, and Tools.
4.5 Code Reverse Engineering
Goals:
• In this phase, the reasons for setting up a process for reverse engineering are
identified and analyzed.

• Analyses are performed to identify the information needs of the process and the
abstractions to be created by the process.

• The team setting up the process first acquires a good understanding of the
forward engineering activities and the environment where the products of the
reverse engineering process will be used.

• Results of the aforementioned comprehension are used to accurately identify:

(i) the information to be generated.
(ii) the formalisms to be used to represent the information.
4.5 Code Reverse Engineering
Models:
• In this phase, the abstractions identified in the Goals stage are analyzed to create
representation models.
• Representation models include information required for the generation of
abstractions.
• Activities in this phase are:
- identify the kinds of documents to be generated.
- to produce those documents, identify the information and their relations to be
derived from source code.
- define the models to be used to represent the information and their relationships
extracted from source code.
- to produce the desired documents from those models, define the abstraction
algorithm for reverse engineering.
• The important properties of a reverse engineering model are: expressive power,
language independence, compactness, richness of information content,
granularity, and support for information preserving transformation.
4.5 Code Reverse Engineering
Tools:
• In this phase, tools needed for reverse engineering are identified, acquired,
and/or developed in-house.

• Those tools are grouped into two categories:

(i) tools to extract information and generate program representations
according to the identified models.
(ii) tools to extract information and produce the required documents.
Extraction tools generally work on source code to reconstruct design
documents.

• Therefore, those tools are ineffective in producing inputs for an abstraction

process aiming to produce high-level design documents.
 • The well-known analysis
techniques that facilitate
4.6 Techniques Used for Reverse

reverse engineering are:

1. Lexical analysis.
2. Syntactic analysis.
3. Control flow analysis.
4. Data flow analysis.
5. Program slicing.
6. Visualization.
7. Program metrics.
Engineering
 • Lexical analysis is the process of
decomposing the sequence of
characters in the source code into its
constituent lexical units.
• A program performing lexical analysis
is called a lexical analyzer, and it is a
part of a programming language’s
compiler.
• Typically it uses rules describing
lexical program structures that are
4.6.1 Lexical Analysis

expressed in a mathematical
notation called regular expressions.
• Modern lexical analyzers are
automatically built using tools called
lexical analyzer generators, namely,
lex and flex (fast lexical analyzer).
 • Syntactic analysis is performed by a parser.
• Similar to syntactic analyzers, parsers can
be automatically constructed from a
description of the programatical
properties of a programming language.
• YACC is one of the most commonly used
parsing tools.
• Two types of representations are used to
hold the results of syntactic analysis: parse
tree and abstract syntax tree.
• A parse tree contains details unrelated to
actual program meaning, such as the
4.6.2 Syntax Analysis

punctuation, whose role is to direct the

parsing process.
• Grouping parentheses are implicit in the
tree structure, which can be pruned from
the parse tree.
• Removal of those extraneous details
produces a structure called an Abstract
Syntax Tree (AST).
• An AST contains just those details that
relate to the actual meaning of a program.
• Many tools have been based on the AST
concept; to understand a program, an
analyst makes a query in terms of the
node types.
• The query is interpreted by a tree walker
to deliver the requested information.
 • After determining the structure of a
program, control flow analysis (CFA) can
be performed on it.
• The two kinds of control flow analysis are:
Intraprocedural: It shows the order in
which statements are executed
within a subprogram.
4.6.3 Control Flow Analysis

Interprocedural: It shows the calling

relationship among program units.
Intraprocedural analysis:
• The idea of basic blocks is central to
constructing a CFG.
• A basic block is a maximal sequence of
program statements such that execution
enters at the top of the block and leaves
only at the bottom via a conditional or an
unconditional branch statement.
• A basic block is represented with one node
in the CFG, and an arc indicates possible
flow of control from one node to another.
• A CFG can directly be constructed from an
AST by walking the tree to determine basic
blocks and then connecting the blocks
with control flow arcs.
 Interprocedural analysis:
• Interprocedural analysis is performed by
constructing a call graph.
• Calling relationships between subroutines in a
program are represented as a call graph which
is basically a directed graph.
4.6.3 Control Flow Analysis

• Specifically, a procedure in the source code is

represented by a node in the graph, and the
edge from node f to g indicates that
procedure f calls procedure g.
• Call graphs can be static or dynamic. A
dynamic call graph is an execution trace of the
program.
• Thus a dynamic call graph is exact, but it only
describes one run of the program.
• On the other hand, a static call graph
represents every possible run of the program.
 • Data flow analysis (DFA) concerns how values
of defined variables flow through and are
used in a program.
• CFA can detect the possibility of loops,
whereas DFA can determine data flow
anomalies.
• One example of data flow anomaly is that an
undefined variable is referenced.
• Another example of data flow anomaly is that
4.6.4 Data Flow Analysis

a variable is successively defined without

being referenced in between.
• Data flow analysis enables the identification
of code that can never execute, variables that
might not be defined before they are used,
and statements that might have to be altered
when a bug is fixed.
• Control flow analysis cannot answer the
question: Which program statements are
likely to be impacted by the execution of a
given assignment statement?
• To answer this kind of questions, an
understanding of definitions (def) of variables
and references (uses) of variables is required.
• If a variable appears on the left hand side of
an assignment statement, then the variable is
said to be defined.
• If a variable appears on the right hand side of
an assignment statement, then it is said to be
referenced in that statement.
 • Originally introduced by Mark Weiser,
program slicing has served as the basis
of numerous tools.
• In Weiser’s definition, a slicing criterion
of a program P is S < p; v > where p is a
program point and v is a subset of
variables in P.
• A program slice is a portion of a
program with an execution behavior
identical to the initial program with
respect to a given criterion, but may
have a reduced size.
• A backward slice with respect to a
4.6.5 Program Slicing

variable v and a given point p

comprises all instructions and
predicates which affect the value of v
at point p.
• Backward slices answer the question
“What program components might
effect a selected computation?”
• The dual of backward slicing is forward
slicing.
• With respect to a variable v and a point
p in a program, a forward slide
comprises all the instructions and
predicates which may depend on the
value of v at p.
• Forward slicing answers the question
“What program components might be
effected by a selected computation?”
4.6.5 Program Slicing: Example of Backward Slice
4.6.5 Program Slicing: Example of Forward Slice
 • Software visualization is a useful
strategy to enable a user to better
understand software systems.
• In this strategy, a software system
is represented by means of a visual
object to gain some insight into
how the system has been
structured.
• The visual representation of a
software system impacts the
effectiveness of the code analysis
or design recovery techniques.
• Two important notions of designing
software visualization using 3D
4.6.6 Visualization

graphics and virtual reality

technology are
• Representation: This is the depiction of
a single component by means of
graphical and other media.
• Visualization: It is a configuration of an
interrelated set of individual
representations related information
making up a higher level component.
• For effective software visualization, one needs to
consider the properties and structure of the
symbols used in software representation and
visualization.
 • When creating a representation the
following key attributes are considered:
1. Individuality. 5.
Distinctive appearance.
2. High information content.
6. Low visual complexity.
3. Scalability of visual complexity.
7. Suitability for
automation.
4. Flexibility for integration into
visualizations.
The following requirements are taken into
4.6.6 Visualization

•
account while designing a visualization:
1. Simple navigation. 6.
Effective visual metaphors.
2. High information content. 7.
Friendly user interface.
3. Low visual complexity. 8.
Integration with other
information sources.
4. Varying levels of detail. 9.
Good use of interactions .
5. Resilience to change. 10.
Suitability for automation.
 • To
und
erst
and
and
con
trol
the
ove
rall
soft
war
e
engi
nee
ring
pro
cess
,
pro
gra
m
met
rics
are
app
lied
.
• Tabl
4.6.7 Program Metrics

e
4.3
sum
mar
izes
the
co
mm
onl
y
use
d
pro
gra
m
met
rics.
 • Based on a module’s fan-in and fan-out information
flow characteristics, Henry and Kafura define a
complexity metric,
Cp = (fan-in fan- out).
×

• A large fan-in and a large fan-out may be symptoms

of a poor design.
• Six performance metrics are found in the
Chidamber-Kemerer CK metric suite:
• Weighted Methods per Class (WMC) – This is the
number of methods implemented within a given
class.
• Response for a Class (RFC) – This is the number of
methods that can potentially be executed in response
to a message being received by an object of a given
class.
• Lack of Cohesion in Methods (LCOM) – For each
attribute in a given class, calculate the percentage
of the methods in the class using that
attributes. Next, compute the average of
all those percentages, and subtract the
average from 100 percent.
• Coupling between Object Class (CBO) –
This is the number of distinct non-
inheritance related classes on which a
given class is coupled.
• Depth of Inheritance Tree (DIT) – This is
Program Metrics

the length of the longest path from a

given class to the root in the inheritance
hierarchy.
• Number of Children (NOC) – This is the
number of classes that directly inherit
from a given class.
 • Kontogiannis et al. developed
techniques to detect clones in
programs using five kinds of
metrics:
• fan-out.
• the ratio of the total count of input and
output variables to the fan-out.
• cyclomatic complexity.
• function points metric.
4.6.7 Program Metrics

• Henry and Kafura information-flow

metric.
4.6.7 Program Metrics
Program Restructuring
What is a Software Architecture?
• Paulisch, Frances. "Software Architecture and Reuse- An Inherent Conflict?" 214. Proceedings of the 3rd International Conference on Software Reuse. Rio de
Janeiro, Brazil, November 1-4, 1994. Los Alamitos, CA: IEEE Computer Society Press, 1994

• Architecture of the system

• An architecture is considered to consist of components and the connectors
(interactions) between them
• Definitions of architecture, component, and connector (protocols) vary
among researchers, this definition of architecture serves as a baseline for
this technology description.
• Design vs Architecture
• Design explicitly addresses functional requirements
• Architecture explicitly addresses functional and non-functional
requirements such as:
• reusability, maintainability, portability, interoperability, testability, efficiency, and
fault-tolerance and the other Quality Attributes

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 37

CS-545-Fall-2002
The Goal of SW Architecture
• Enable the construction of very large system architectures.
• Many, many connections
• Dynamic creation of components and dynamically de-selectable connections.
• Support for a Hierarchical design Process
• So we can gradually introduce the ranked ordered set of quality attributes we care about.
• Test & Validate partially instantiated architectures
• Especially true in large systems
• (QA: subsetability)
• Flexibility in allowing modules to be assigned to interfaces
• (QA: Interoperability)
• So How do we do this ?

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 38

CS-545-Fall-2002
Architecture Representation
Concepts •

• Component:
(Computer 2) Core Architecture Refinement: IEEE Transactions on Software Engineering, Vol 21, No .4 April 1995, pgs 356-372

• An object with independent Existence, i.g. A module, process, procedure, or variable

• Interface:
• A typed object that denotes a logical point of interaction between a component and its
environment.
• Connector:
• A typed Object relating interface points, components, or both

• Configuration:
• A collection of Constraints that wire the objects into a specific architecture

• Mapping:
• A relationship that defines a syntactical translation from the language of an abstract architecture to the
language of a concrete architecture
• Architectural Style:
• A vocabulary of design elements, constraints that determine how they are to be used and a
What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
semantic definition of the connectors associated with this style.

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 39

CS-545-Fall-2002
Architecture Evaluation and Analysis:
SEI: Architecture Quality Attributes Used for Evaluation & Analysis
• http://www.sei.cmu.edu/publications/documents/00.reports/00tn017.html

• http://www.sei.cmu.edu/str/taxonomies/view_qm.html
Organizational Measures
–Cost of Ownership
• Maintenance Measures Cost of Operation
• Maintainability Operations Personnel
• Understandability Training
• Complexity Operations System
• Simplicity Cost of Maintenance
• Structuredness Maintenance Personnel
• Readability Training
Maintenance Control
• Adaptive Measures
HW Maintenance
• Interoperability
SW Maintenance
• Compatibility
Requirements Growth
• Openness
Life-Time Operational Capability
• Portability Acquisition Cycle Time
• Scalability Software Change Cycle Time
• Reusability –Productivity
• Functional Scope
Retrievability
What are the• different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 40

CS-545-Fall-2002
Architecture Evaluation and Analysis: ISO: Architecture Quality Attributes
• ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991.

• Functionality
• Suitability, Accuracy, Interoperability, Compliance, Security
• What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?

• Reliability
• Maturity, Fault-Tolerance, Recoverability
• What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?

• Usability
• Understandability, Learn ability, Operability
• What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?

• Efficiency
• Time behavior, Resource Behavior
• What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?

• Maintainability
• Analyzability, changeability, Stability, Testability
• What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?

• Portability
• Adaptability, Install ability, Conformance, Replace ability
• What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 41
CS-545-Fall-2002
ISO vs. SEI Differences?
Architecture Recovery: Some
References
Architecture Recovery

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 42

CS-545-Fall-2002
Architecture Recovery: Some
References
Architecture Recovery

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 43

CS-545-Fall-2002
Architecture Recovery: Some
References
Architecture Recovery

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 44

CS-545-Fall-2002
Architecture Recovery: Some
References
Architecture Recovery

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 45

CS-545-Fall-2002
Architecture Representations: Static View vs. Dynamic View
• http://www-old.ics.uci.edu/pub/arch/dynamic-arch.html

• “Current software architecture research assumes a system's

architecture is static, …it does not evolve during execution.”
• Architectures must be able to evolve during execution.

• “First, the architectures of many existing systems change during execution,

and are poorly modeled using existing techniques.
• Examples include systems built using OLE, OpenDOC, or CORBA, in which new
components may be loaded and unloaded during execution.”

• “Second, many systems would benefit from the dynamism afforded by a

dynamic architecture.
• Examples include systems characterized as long running and mission critical
since the delays and risks associated with shutting down these systems for
upgrades may be expensive.”
Give Examples of Real World Problems (Internet?)

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 46

CS-545-Fall-2002
Architecture Recovery: Some
References
• How can we reconstruct an architecture from the implementation?
• Melissa P. Chase, Steven M. Christey, David R. Harris and Alexander S. Yeh, "
Recovering software architecture from multiple source code analyses", Proceedings of
Workshop on Program Analysis for Software Tools and Engineering, June 16, 1998, Montreal
Canada, pp. 43-50
• Huw Evans and Peter Dickman, "
Zones, Contracts and Absorbing Changes: An Approach to Software Evolution", Proceedings
of OOPSLA'99, November 1-5, 1999, Denver, CO, USA, pp. 415-434
• D. R. Harris, H. B. Reubenstein, A. S. Yeh, "Reverse Engineering to the Architectural Level ",
Proceedings of the 17th Int'l Conference on Software Engineering, 1995, pp. 186-195
• D. Garlan, R. Allen, and J. Ockerbloom, "Architectural Mismatch, or why it's hard to build
systems out of existing parts“, Proceedings of the 17th. Int'l Conference on Software
Engineering, Seattle, WA, April 1995, pp. 179-185

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 47

CS-545-Fall-2002
Architecture Recovery: Some
References
Software Re-engineering Economics

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 48

CS-545-Fall-2002
Architecture Recovery: Some
References
Software Re-engineering Economics

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 49

CS-545-Fall-2002
Architecture Recovery: Some
References
Software Re-engineering Economics

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 50

CS-545-Fall-2002
Architecture Recovery: Some
References
Software Re-engineering Economics

Fall 2002 http://www.sei.cmu.edu/about/disclaimer.html 51

CS-545-Fall-2002