Powered By

Strategies for Changing Software Systems

• Software Maintenance: Preventing software from failing by bug fixing and carrying out support activities after
delivery of software.

• Software Evolution: Continual change in software requirements, creating new designs to support new
functionalities and improve performance.

• Maintenance Tasks: Primarily fixing bugs while preserving functionalities, with planned and unplanned activities.

• Software Re-engineering: Transforming existing systems into better ones, improving maintainability, migrating to
new technology, improving quality, and preparing for functional enhancement.

• Re-engineering Risks: Potential lack of functionality and lower quality in target system, and potential failure to
achieve desired benefits within required time frame.

• Reengineering Concepts: Abstraction and Refinement as key concepts used in software development and
reengineering.

Principles and Concepts of Software Abstraction and Refinement

• Abstraction is a technique used by software maintenance personnel to reduce system complexity by focusing on
significant information and hiding irrelevant details.

• Refinement is the reverse of abstraction and gradually increases the level of abstraction by replacing details with
abstract information.

• Forward engineering is the creation of a new software system by moving from the highest to the lowest level of
abstraction.

• Reverse engineering involves analyzing software components, representing them at a higher level of abstraction,
and decompilation.

• Software development models use the concepts of abstraction and refinement with four levels: conceptual,
requirements, design, and implementation.

• Alteration is a non-essential principle that involves making changes to a system without changing the degree of
abstraction.

• The reengineering process takes existing code and produces renovated code, which can be as simple as
translating code from one language to another or recreating a design from existing source code.

General Model for Software Reengineering

• Find the requirements of the system being reengineered.

• Compare the existing requirements with the new ones.

• Remove those requirements that are not needed in the renovated system.

• Make a new design of the desired system.

• Code the new system.

• The model proposed by Eric J. Byrne suggests that reengineering involves reverse engineering, re-design, and
forward engineering activities.

• The horseshoe model describes a three-step architectural reengineering process.

• Definitions of reengineering by Chikofsky and Cross II, Byrne, and Arnold provide different perspectives on the
process.

• Reengineering entails creating a more abstract view of the system, restructuring it, and implementing it in a new
form.

• Rehosting is a term used to describe reengineering without adding or reducing features in the transformed source
code.

Types of Change and Software Reengineering Strategies

• Recode: Changes are made to the source code of a program through rephrasing and program translation, either
within the same language or by transforming it into a different language.

• Redesign: The design characteristics of the software are modified, including restructuring the architecture,
modifying the data model, and replacing procedures or algorithms.

• Respecify: The requirements of the system are changed, either by altering the form or expanding the scope.

• Rethink: The concepts of an existing system are manipulated to create a system that operates in a different
problem domain.

• Rewrite strategy: Operational systems are transformed into new ones while preserving the abstraction level of the
original system.

• Rework strategy: Unstructured control flow constructs are replaced with structured constructs through abstraction,
alteration, and refinement processes.

• Replace strategy: Characteristics of a system are reconstructed at a higher level of abstraction and a suitable
representation is generated at a lower level through abstraction and refinement.

Different Approaches to Software Reengineering

• The "Big Bang" approach replaces the entire system at once, achieving all project objectives and constructing the
target system.

• The incremental approach reengineers the system gradually, producing and releasing several interim versions
that satisfy more project goals over time.
• The partial approach only reengineers a portion of the system and integrates it with the non-engineered portion
using either the "Big Bang" or "Incremental" approach.

• The iterative approach involves repeating a series of steps to enhance the system incrementally.

Reengineering Process and Source Code Reengineering Reference Model

• The reengineering process involves applying operations on source code procedures in stages, allowing for the
coexistence of old components, components being reengineered, reengineered components, and new
components.

• The iterative reengineering process ensures continued system operation and familiarity for maintainers and users,
but requires tracking of the four types of components.

• The "Evolutionary" approach replaces original system components with reengineered ones, focusing on
functionally cohesive components.

• The SCORE/RM model for source code reengineering consists of elements such as function, documentation,
repository database, and metrication.

• The model includes eight layers, providing a detailed approach for rationalizing, reverse engineering, and forward
engineering.

• The metrication element quantifies software improvements before and after each layer, and the repository
database stores information including metrics, documentation, and source code.

• Interfaces among the elements are depicted in a diagram.

Interface Nomenclature and Software Reengineering Phases

• Interfaces in software reengineering are categorized as (N)-MF, (N)-DF, and (N)-FF.

• The phase model of software reengineering consists of five phases: analysis and planning, renovation, target
system testing, redocumentation, and acceptance testing and system transition.

• Each phase represents a major process activity.

• Tasks within each phase can be further decomposed to reveal detailed methodologies.

• Analysis and planning involves addressing technical and economic issues, understanding system properties,
identifying the need for reengineering, specifying characteristics of the new system, and conducting cost and
benefit analysis.

• The renovation phase involves modifying an operational system into the target system, considering system
representation and external data.

• Renovation strategies can involve source-to-source translation, high-level design re-implementation, or

compilation and decompilation.
• Target system testing is a phase dedicated to system testing.

Notes on Reengineering and Code Reverse Engineering

• Fault detection in the target system is performed to identify any faults that may have been introduced during
reengineering.

• The same testing strategies, techniques, methods, and tools used in software development are also used in
reengineering.

• Reengineering involves applying the existing system-level test cases to both the existing and the new system to
ensure consistent results.

• In the redocumentation phase of reengineering, documentations are rewritten, updated, and/or replaced to reflect
the target system.

• Revision of various documents, such as requirement specification, design documentation, and user manuals, is
part of the redocumentation phase.

• The acceptance and system transition phase involves evaluating the reengineered system through acceptance
testing.

• Preparation for transitioning to the new system begins if the reengineered system passes the acceptance tests.

• Faults detected in the reengineered system must be fixed before transitioning, and in some cases, the fixes are
deployed after the target system is operational.

• The old system is put out of service once the acceptance tests are completed, and the reengineered system is
made operational.

• Code reverse engineering is the process of examining a complex system to identify its components, relationships,
and represent it at a higher level of abstraction or in another form.

• Redocumentation of artifacts and design recovery are the two objectives of code reverse engineering.

• Six objectives of reverse engineering include generating alternative views, recovering lost information, creating
higher levels of abstractions, detecting side effects, facilitating reuse, and coping with complexity.

• The IEEE Standard for Software Maintenance outlines six key steps in reverse engineering, including partitioning
source code into units, describing the meanings of those units, and creating input and output schematics.

Program Comprehension: Understanding and Acquiring Knowledge

• The program comprehension process involves local and global analysis.

• Good program comprehension is crucial for effective software maintenance and evolution.

• Different tasks associated with program maintenance require understanding the system or problem.

• Cognitive models have been developed to understand program comprehension.

• Code cognition models provide a background material for understanding program comprehension.

• A code maintainer aims to understand a program with a specific goal in mind.

• Program comprehension is a process of knowledge acquisition.

• Programmers possess both general knowledge and software-specific knowledge.

• Acquiring new knowledge involves understanding functionality, architecture, control flow, data flow, exception
handling, stable storage, and implementation details.

• Programmers acquire general and software-specific knowledge iteratively through the program comprehension
process.

• Mental models represent a programmer's understanding of the program being comprehended.

Understanding the Mental Model of a Program in Program Comprehension

• A mental model of a program is not unique; different programmers view and interpret a program in different ways.

• A programmer develops a mental model by identifying both static and dynamic elements of the program.

• Static elements of a mental model include text-structures, chunks, schemas, plans, and hypotheses.

• Text-structures, such as loop constructs and conditional statements, help in gaining control flow knowledge in
program understanding.

• Chunks are blocks of related code segments that enable higher level abstractions.

• Schemas guide the programmer's interpretations, inferences, expectations, and attentions when comprehending
passages.

• Plans are broad kinds of knowledge elements used in understanding a program, including domain plans and
programming plans.

• Domain plans include knowledge about the real-world problem and the program's environment.

• Programming plans are program fragments representing action sequences that programmers repeatedly apply
while coding.

Notes on Programming Plans and Mental Models in Code Understanding

• A for loop is an example of a programming plan to implement a system.

• Programming plans differ in their granularities to support low level or high level tasks.

• Programmers develop an understanding of code and related documents as they read them.

• Conjectures (hypotheses) help programmers test their understanding of program elements.

• Why conjectures hypothesize the purpose of a program element.

• How conjectures hypothesize the method for realizing a program goal.

• Conjectures enable programmers to classify program elements.

• Chunking is the process of creating higher level abstraction structures by combining lower level chunks.

• Chunking is repeatedly applied to create increasingly higher levels of abstractions.

• Cross-referencing helps link elements of different abstraction levels in a program.

• Understanding code involves acquiring knowledge from code and the level of expertise of the code reader.

• Beacons in code provide cues to the computation being performed.

• Rules of programming discourse specify conventions followed while writing code, such as function and variable
naming.

Letovsky's Program Comprehension Model

• The rules set expectations for the program in a reader's mind.

• Expert programmers organize knowledge by functional characteristics, while beginners focus on program syntax.

• Experts comprehend code with flexibility and generate a breadth-first view of the program.

• Development of specialized design schemas helps organize complex entities.

• Various cognition models for program understanding include Letovsky model, Shneiderman and Mayer model,
Brooks model, Soloway, Adelson, and Ehrlich model, and Pennington model.

• Letovsky model emphasizes programming expertise, knowledge base, goals, problem domain, rules of discourse,
external representations, and mental representation.

Program Comprehension Models and Processes

• The Letovsky model describes the assimilation process in program comprehension, where programmers merge
their knowledge base and external representations to create mental models.

• Assimilation can occur through three methods: top-down, bottom-up, and opportunistic.

• Top-down assimilation starts with a goal and examines possible implementations.

• Bottom-up assimilation involves identifying program plans from code and moving upward.

• Opportunistic assimilation combines top-down and bottom-up approaches.

• The Purpose Unit captures goals with unclear implementations.

• The Shneiderman and Mayer model explores program comprehension with three components: short term
memory, knowledge, and internal semantics.

• Internal semantics represent the program between top-level goals and detailed implementations.

• Knowledge includes domain knowledge and programming knowledge stored in long term memory.

• Short term memory has limited capacity and requires the ability to identify chunks and create abstractions.