10/15/2024 1

Software Re-Engineering
Course Code: SE473
Lecture # 05

Department of Software Engineering,

10/15/2024 2
 Outlines
Program comprehension

Overview

Program comprehension process

Comprehension techniques
 Program comprehension
Program comprehension is the study of how software engineers understand programs.

Program comprehension is needed for:

▪ Debugging

▪ Code inspection

▪ Test case design

▪ Re-documentation

▪ Design recovery

▪ Code revisions.

4
 Program comprehension process
Involves the use of existing knowledge to acquire new knowledge about a program.
Existing knowledge:
▪ Programming languages • Computing environment
▪ Programming principles
▪ Architectural models
▪ Possible algorithms and solution approaches
▪ Domain-specific information
▪ Any previous knowledge about the code
New knowledge:
▪ Code functionality
▪ Architecture
▪ Algorithm implementation details
▪ Control flow
▪ Data flow Program Comprehension
5
 Program comprehension process
Programming Languages
Knowledge of the programming language in which the code is written helps developers
understand syntax, data types, control structures, and libraries.
Example: A developer proficient in Java would easily understand how classes, objects, and
methods work, while someone unfamiliar with Java might struggle with interpreting the same
code.
Computing Environment
The computing environment refers to the system's hardware, software, operating system, and
tools where the program runs. This knowledge is crucial in understanding system constraints
and optimizations.
Example: A program running on Linux might use specific shell commands or libraries, and a
developer with experience in Linux environments would better comprehend how the program
interacts with the system.

6
 Program comprehension process
Programming Principles
These are fundamental concepts like modularity, abstraction, encapsulation, and design
patterns. Familiarity with these principles helps in understanding the structure and design of
the code.
Example: If the code follows the SOLID principles (e.g., single responsibility, open-closed
principle), a developer familiar with these will quickly grasp how different components work
and interact within the codebase.
Architectural Models
Architectural models define the high-level structure of a system, including components,
modules, and how they communicate.
Example: In a client-server architecture, the developer knows there’s a clear separation
between the client (front-end) and server (back-end), which makes understanding the
program’s flow easier.

7
 Program comprehension process
Possible Algorithms and Solution Approaches
Understanding common algorithms and data structures helps in identifying the logic behind
the code. This can include searching, sorting, or problem-solving techniques commonly used
in programming.
Example: When reading a program with a binary search algorithm, a developer with
algorithmic knowledge will recognize its purpose in searching sorted data efficiently.
Domain-Specific Information
Some programs are designed for specific domains, like finance, healthcare, or education.
Understanding the domain helps in making sense of business rules or technical
requirements.
Example: A software solution in the banking domain may involve terms like interest
calculations or account balances, which a domain-experienced developer would easily
understand.

8
 Program comprehension process
Any Previous Knowledge About the Code
If a developer has prior exposure to a similar codebase or the same project, it significantly
reduces the time needed to comprehend the current code.
Example: A developer returning to a project they previously worked on will already be familiar
with its logic, structure, and dependencies, reducing the effort needed to understand the code
again.

9
 Program comprehension process
Any Previous Knowledge About the Code
If a developer has prior exposure to a similar codebase or the same project, it significantly
reduces the time needed to comprehend the current code.
Example: A developer returning to a project they previously worked on will already be familiar
with its logic, structure, and dependencies, reducing the effort needed to understand the code
again.

10
Program comprehension process (New knowledge)
Code Functionality
This refers to understanding what the program or a specific piece of code is designed to do.
When analyzing a new codebase, the developer must figure out how the code functions in
relation to the overall program objective.
Example: Suppose you are looking at a Python script that automates the backup of files:
def backup_files(source, destination):
files = os.listdir(source)
for file in files:
shutil.copy(os.path.join(source, file), destination)
New knowledge in this case would be understanding that this function copies all files from the source
directory to the destination. Once the code is understood, you realize its functionality is for backing up
files

11
 Program comprehension process
Architecture
New knowledge involves identifying how the software is structured, including its layers,
modules, and how components interact. This may require understanding a new architectural
model or framework used by the application.
Example: When encountering a new codebase using the Model-View-Controller (MVC)
architecture, new knowledge gained might include:
•Model: Represents the data and logic (e.g., database models).
•View: Manages what the user sees (e.g., HTML templates or UI code).
•Controller: Handles user inputs and updates the model or view accordingly.
If the program is a web application, new knowledge might involve recognizing which files
represent each layer (models, views, controllers) and how they interact within the web
framework.

12
 Program comprehension process
Algorithm Implementation Details
This refers to understanding not just which algorithm is used, but how it is implemented in the
program. Gaining this knowledge involves deciphering the logic, data structures, and
conditions used within the algorithm.
Example: In a sorting function:
def bubble_sort(arr):
n = len(arr)
for i in range(n):
for j in range(0, n-i-1):
if arr[j] > arr[j+1]:
arr[j], arr[j+1] = arr[j+1], arr[j]
return arr

13
 Program comprehension process
Here, understanding the bubble sort algorithm implementation, where adjacent elements are
swapped to sort the list, is key. Recognizing the nested loop and swap mechanism is part of
understanding the algorithm’s implementation details.
Control Flow
Control flow refers to how the execution of a program proceeds through various branches
and loops. This involves understanding conditional statements, loops, and function calls that
control the execution sequence of the program.
Example: Consider a decision-making process in code:
if user.is_authenticated():
display_dashboard()
else:
redirect_to_login()

14
 Program comprehension process
New knowledge involves understanding that the control flow of the program depends on
whether the user is authenticated. If the user is authenticated, the program flows to the
display_dashboard() function; otherwise, it redirects to the login page.
Data Flow
Data flow represents how data moves and is transformed through the system. Understanding
how data is passed between functions, modules, or external systems (e.g., databases, APIs)
is essential in program comprehension.
Example: In a shopping cart system
def calculate_total(cart_items):
total = 0
for item in cart_items:
total += item.price * item.quantity
return total

15
 Program comprehension process
Here, the data flow involves passing cart_items (a list of objects) into the
calculate_total function.
The function then processes this data by multiplying price and quantity for each item,
aggregating the total cost.
Understanding how cart_items are transformed into a total is part of data flow
comprehension.

16
 Program comprehension process
Program Comprehension
This is the overall process of acquiring all the above knowledge elements — combining both
existing knowledge and new insights into the codebase to fully understand how the program
works.
Example: Let’s say you are tasked with comprehending a legacy system for managing payroll. You
will need to understand:
•How it processes employee data (data flow),
•How it decides on deductions (control flow),
•The algorithms used for tax calculation (algorithm implementation),
•The system’s architecture (e.g., it might be using a microservices architecture),
•And the program’s overall functionality, like generating pay slips and reports.

17
 Comprehension techniques
Reading by step-wise abstraction
• Determine the function of critical subroutines, work through the program hierarchy until the
function of the program is determined.
Checklist-based reading
• Readers are given a checklist to focus their attention on particular issues within the
document.
• Different readers were given different checklists, therefore each reader would concentrate on
different aspects of the document.

18
 Comprehension techniques
Defect-based reading
Defects are categorized and characterized (e.g., data type inconsistency, incorrect
functionality, missing functionality, etc.)
A set of steps (a scenario) is then developed for each defect class to guide the reader to find
those defects.
Perspective-based reading
Similar to defect-based reading, but instead of different defect classes, readers have different
roles (tester, designer and user) to guide them in reading. Program Comprehension.

19
 Sources of variation
Aside from the issue of how comprehension occurs, comprehension
performance and effectiveness are affected by many factors:

•Maintainer characteristics
•Program characteristics
•Task characteristics

20
 Sources of variation
Maintainer characteristics:
Familiarity with code base
Application domain knowledge
Programming language knowledge
Programming expertise
Tool expertise
Individual differences

21
 Sources of variation
Program characteristics:
Application domain
Programming domain
Quality of problem to be understood
Program size and complexity
Availability and accuracy of documentation

22
 Sources of variation
Task characteristics:
Task type
•Experimental: recall, modification
•Perfective, corrective, adaptive, reuse, extension.
Task size and complexity
Time constraints
Environmental factors

23
 Models
Mental models
•Internal working representation of the software under consideration.
Cognitive models
•Theories of the processes by which software engineers arrive at a mental model.

24
 Mental Models
Static elements
•Text structure knowledge
•Microstructure
•Chunks (macrostructure)
•Plans (objects)
•Hypotheses
Dynamic elements
•Strategies (chunking and cross-referencing)
Supporting elements
•Beacons
•Rules of discourse 25
 Mental Models
Text structure:
• The program text and its structure
• Control structure: iterations, sequences, conditional constructs
• Variable definitions
• Calling hierarchies
• Parameter definitions
Microstructure —actual program statements and their relationships.

26
 Mental Models
Chunks:
Contain various levels of text structure
abstractions.
Also called macrostructure.
Can be identified by a descriptive label.
Can be composed into higher level chunks.

27
 Mental Models
Plans (objects):
Knowledge elements for developing and validating
• expectations, interpretations, and inferences.
Include causal knowledge about information flow and
relationships between parts of a program.
Programming plans
•Based on programming concepts.
•Low level: iteration and conditional code segments.
•Intermediate level: searching, sorting, summing algorithms; linked lists and trees.
•High level: designing an entire system or developing a program with modular components
that work together

28
 Mental Models
Plans (objects):
Domain plans
•All knowledge about the problem area.
Examples: problem domain objects, system environment,
domain-specific solutions and architectures

29
 Mental Models
Hypotheses:
Conjectures that are results of comprehension activities that can
take seconds or minutes to occur.
Three types:
• Why — hypothesize the purpose/rationale of a function of design choice.
• How — hypothesize the method for accomplishing a certain goal.
• What — hypothesize classification.
Hypotheses are drivers of cognition. They help to define the direction of further
investigation.

30
 Mental Models
Hypotheses:
Code cognition formulates hypotheses, checks them whether they are true or
false, and revises them when necessary.
Hypotheses fail for several reasons:
• Can’t find code to support a hypothesis.
• Confusion due to one piece of code satisfying different
hypothesis.
• Code cannot be explained.

31
 Mental Models
Supporting elements:
Beacons
• Cues that index into existing knowledge.
o A swap routine can be a beacon for a sorting function.
• Experienced programmers recognize beacons much faster than novice
programmers.
• Used commonly in top-down comprehension.
Rules of discourse
• Rules that specify programming conventions.
• Examples: coding standards, algorithm implementations, expected use of data
structures.

32
 Mental Models
dynamic elements
Strategies
•Sequences of actions that lead to a particular goal.
Actions
•Classify programmer activities implicitly and explicitly
during a maintenance task.
Episodes
•Sequences of actions.
Processes
•Aggregations of episodes.

33
 Cognitive Models
Distributed Cognition
Traditional cognitive models deal the cognitive processes inside one person’s brain.
On real projects, software developers:
• Work in teams
• Can ask people questions
• Can surf the web for answers
How do these affect the cognitive process?

34