ELEC1005
WEEK 10
MAINTENANCE & Test-
Driven Development
Prepared & Presented by
Dr. Charles Z. Liu
The University of Sydney Page 1
CFG Examples
The University of Sydney Page 2
Example
if A = 0 then
if B > C
A=B
else A = C
endif
endif
print A, B, C
The University of Sydney Page 3
Example
Please draw the CFG corresponding to the given source code
The University of Sydney Page 4
Example
Please draw the CFG corresponding to the given source code
The University of Sydney Page 5
Examples
● Try to read the lines
● Figure out the logic
● Model the control flow
The University of Sydney Page 6
linear independent path (LIP)
● It refers to a path that includes a set of statements or conditions
that have not been processed before
● From the point of view of the control flow graph, a linearly
independent path is a path that contains at least one edge that
has never been seen in other linearly independent paths
● It means: there are edges in this path that are not found in other
paths
● Generally, those with judgments are basically, several judgments
take several paths, and several paths are several linearly
independent paths
The University of Sydney Page 7
LIP
Please find all the Linear Independent Path
The University of Sydney Page 8
LIP
● A-B-F-G-H
The University of Sydney Page 9
LIP
● A-B-F-G-H
● A-B-F-H
The University of Sydney Page 10
LIP
● A-B-F-G-H
● A-B-F-H
● A-B-C-E-B-F-G-H
The University of Sydney Page 11
LIP
● A-B-F–G-H
● A–B–F-H
● A-B-C-E-B-F-G–H
● A-B-C-D-F-H
The University of Sydney Page 12
LIP to Test Case
● A-B-F–G-H
● A–B–F-H
● A-B-C-E-B-F-G–H
● A-B-C-D-F–H
● The test case for the white box test can
be designed based on the LIPs to cover
most logic inferences
The University of Sydney Page 13
Please draw the CFG and find the LIPs corresponding to the given pseudo code
initialize passes to zero
initialize failures to zero
initialize student to one
while student counter is less than or equal to ten
input the next exam result
if the student passed
add one to passes
else
add one to failures
add one to student counter
print the number of passes
print the number of failures
calculate the pass rate = passes/counter
The University of Sydney Page 14
Number of LIPs
● A-B-F–G-H
● A–B–F-H
● A-B-C-E-B-F-G–H
● A-B-C-D-F–H
● How many LIPs represent the
complexity of the program
● How to measure this complexity
The University of Sydney Page 15
Cyclomatic Complexity
● Cyclomatic Complexity is the quantitative measure of the number
of linearly independent paths in it. It is a software metric used to
describe the complexity of a program.
● It is computed using the Control Flow Graph of the program.
● Cyclomatic Complexity M
● M = E – N + 2P
● where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components
●
The University of Sydney Page 16
P=1, as the whole graph is connected
Example
● A control-flow graph of a simple
program. The program begins
executing at the red node, then enters
a loop (group of three nodes
immediately below the red node). On
exiting the loop, there is a conditional
statement (group below the loop), and
finally the program exits at the blue
node.
● This graph has ? edges, ? nodes, and
1 connected component, so the
cyclomatic complexity of the program
is 9 - 8 + 2*1 = 3.
The University of Sydney Page 17
● The same function as above,
represented using the alternative
formulation, where each exit point is
connected back to the entry point.
This graph has E edges, N nodes,
and P = 1 connected component
● M = E-N+2P
● 10-8+2=4
The University of Sydney Page 18
Example The cyclomatic complexity
calculated for the code will be
from control flow graph.
A = 10 The graph shows
seven shapes(nodes),
IF B > C THEN seven lines(edges),
A=B
ELSE M = E – N + 2P
A=C E = the number of edges in the
ENDIF control flow graph (7)
Print A N = the number of nodes in the
control flow graph (7)
Print B P = the number of connected
Print C components
hence cyclomatic complexity is
7-7+2 = 2.
The University of Sydney Page 19
Calculate the Cyclomatic Complexity of the CFGs below
Cyclomatic Complexity M
M = E – N + 2P
where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components
The University of Sydney Page 20
Exercise
Please Calculate the Cyclomatic Complexity
According to the formula
V(G) = E – N + 2P = 12 – 8 + 2 = 6
,
the cyclomatic complex segment in
the figure above is 6.
Although there are 12 nodes on
the graph, 4 of them are throw.
The University of Sydney Page 21
Start
Please draw the CFG Initialize total to zero
corresponding to the
given flow chart, and Initialize total to zero
Initialize counter to zero
calculate the time Initialize counter to zero
complexity, cyclomatic Input the first grade
Input the first grade
complexity, and List out while the user has not as yet enter the
all the LIPs empty
Yes Is the Input add this grade into the running total
empty? add one to the grade counter
No
input the next grade (possibly the
sentinel)
add this grade into if the counter is not equal to zero
the running total set the average to the total divided by
the counter
add one to the grade print the average
counter else
print 'no grades were entered'
Is counter 0
?
Print(avg = print 'no grades
total/counter) were entered'
The University of Sydney Page 22
End
From Changes to Maintenance
The University of Sydney Page 23
Maintenance
– The most expensive phase of
the software life cycle is
Software Maintenance
– In order to improve the
maintainability of the
software, attention should be
paid to the development of
a good programming style
during the coding phase
The University of Sydney Page 24
Maintenance Strategies
● Strategies for software maintenance include
The University of Sydney Page 25
Corrective Maintenance
● Corrective Maintenance is the category of maintenance tasks
performed to correct and repair faulty systems and equipment.
● The purpose of corrective maintenance is to restore systems that
have failed.
● Corrective maintenance can be synonymous with faulty or
reactive maintenance.
The University of Sydney Page 26
Adaptive Maintenance
● Adaptive maintenance is the modification of software to keep it
usable after a change to its operating environment.
● Many factors can change an application's environment,
including new technical knowledge, hardware and security
threats.
The University of Sydney Page 27
Perfective Maintenance
● The process of modifying software due to changes in the
computer hardware and software environment is known as
perfective maintenance.
● It is to adapt the software by adding necessary new features
and removing features that are not relevant or effective for the
given software.
● This process keeps the software relevant as the market and user
needs change.
Note:
Increasing the number of maintenance staff will not speed
up software maintenance operations
The University of Sydney Page 28
Preventive Maintenance
● Preventive maintenance (PM) is the regular and routine
maintenance of equipment and assets to keep them running and
to prevent any costly unplanned downtime due to unexpected
equipment failure.
● A successful maintenance strategy requires planning and
scheduling maintenance on equipment before problems occur.
● Software modifications to prevent future errors.
● It increases software maintainability by reducing the complexity
of the software.
The University of Sydney Page 29
Preventive Maintenance
● The tasks of preventive maintenance include:
● Updating documentation. Update the documentation based on
the current state of the system.
● Optimize code. Modify code to speed up program execution or
to make efficient use of storage space.
● Refactoring code. Transforming the structure of a program by
reducing the source code to make it easy to understand.
The University of Sydney Page 30
Maintenance Impacts
The University of Sydney Page 31
Supportive Maintenance
The University of Sydney Page 32
From SDLC to S Maintenance Life Cycle
The University of Sydney Page 33
Maintenance Activities
The University of Sydney Page 34
Example
The University of Sydney Page 35
Programming Style
● Reading a program is an important part of the software
development and maintenance process, and a program is
actually a text for people to read.
● Programs should be written in a style that will greatly reduce the
amount of time people spend reading them.
● A good coding style helps to write reliable and easy-to-maintain
programs.
● The style of coding largely determines the quality of the
program.
The University of Sydney Page 36
Test-driven development (TDD)
● Acceptance criteria (AC) get
start things ready to be tested
before they are even
developed
Create a test case ● Using AC align perfectly
with Test-driven
Write (correct) a more
tests
Development (TDD)
code segment ● Rule of thumb
no
○ If things can’t be tested,
Run the test(s) more question whether they are
tests actually needed. (as no one
may use them)
find error no error
end ○ If things are used by real
users, then they can be tested
The University of Sydney Page 37
Classification of testing
software engineer software quality engineer
functional White-box approach Black-box approach
testing (Unit testing) (Integration testing)
other
testing Non-functional testing
The University of Sydney Page 38
Integration and functional testing
The University of Sydney Page 39
Using breakpoint
● Breakpoint is a key
feature in Debugger
● Indicating the variable
value (at the
breakpoint)
● Indicating the ”call
stack” (showing the
execution path into this
particular
function/method/code
Paused at the breakpoint section)
source: https://docs.microsoft.com/en-us/visualstudio/debugger/using-breakpoints?view=vs-2022
The University of Sydney Page 40
Using logs
● When issues
from production
are investigated,
logs are the best
“paper trail”.
● Logs are
overwhelming so
filtering is
essential
● Keyword
searching is also
helpful
● Log analysers
source: SolarWinds
are useful tools
The University of Sydney Page 41
Using simulations
● To recreate issues with
hardware
● Simulations are now
indispensable part in software
development especially mobile
development
● Compatibility issues include
browser, operating system,
hardware device and their
combination
The University of Sydney Page 42
Software release
The University of Sydney Page 43
Software release
● Following any formal (final) regression
tests
○ Functional and non-functional
○ Alpha or Beta tests
● Followed by deployment into production
● Release notes
○ Describing what is included in the new version
○ Reasons for upgrade
○ Dependencies
○ Compatibility issues
source: Apple
The University of Sydney Page 44
The Way of Deployment in Production – BLUE /
GREEN
- Create a duplicated set of infrastructure (GREEN stack)
with a new version of application
- Web/App/Database
- Updated application version
- DNS switch (point DNS to the GREEN stack load
balancer)
- If things don’t work well, roll back the DNS to the BLUE
stack.
- No version inconsistency issues
- There is a small window of running two infrastructure
stacks
- Entire process takes seconds (DNS switch)
The University of Sydney Page 45
The Way of Deployment in Production – ROLLING
UPDATE
- If there are N instances running the same service,
replace 1 with the new version, then 2, ..till N-1
and N.
- Replace one at a time. Create a new one and shut
an old one down
- There is a small window of inconsistent versions
(some are running new; others are running old)
- The entire process may take minutes to hours
The University of Sydney Page 46
Site Reliability Engineering
The University of Sydney Page 47
Site Reliability Engineering
– Site Reliability Engineering (SRE) is a discipline that
incorporates aspects of software engineering and applies them
to infrastructure and operations problems. The main goals are
to create scalable and highly reliable software systems.
According to Ben Treynor, founder of Google's Site Reliability
Team, SRE is "what happens when a software engineer is
tasked with what used to be called operations”.
Source: Wikipedia
The University of Sydney Page 48
SPOF - single point of failure
● Review all components
● Find SPOF
● Remove them by introducing
○ Replication or redundancy
○ Backup and Restore
○ Auto-recovery
● If SPOF needs to remain, the failure patterns
need to be studied and mitigated
The University of Sydney Page 49
Service Level Objectives
- Service Level Objectives
- Uptime: e.g. 99.99% (1m 26.4s downtime per day)
- Service Level Agreement (SLA)
- Usually is tied to financial compensation if this is breached.
- Recovery Point Objective (RPO)
- How much data the system might be able to lose
- Recovery Time Objective (RTO)
- How long would it take to recover the services
The University of Sydney Page 50
Design source: AWS SLAs
Monthly uptime service level
agreements (SLA). By
breaching them, there is a
financial penalty.
Service SLA Comment
EC2 99.99
ELB 99.99
RDS 99.95
S3 99.9 S3 is designed for
99.99% yearly
availability
Source: Amazon Web Services
The University of Sydney Page 51
Fail often, and fail fast
● DevOps or Site Reliability
Engineering does not reply
on “guestimates”
● Metrics are needed for
decision making
○ Provisioning of resource per
actual requirements
○ Objective measurement of
fast / slow, good / bad
● If things are failing, fail fast,
and recover fast
○ Rollback is essential
● No manual changes when
things can be automated
The University of Sydney Page 52
Performance test
Red line: specification for scalability and concurrency
● Load test
● Stress test
● Endurance test
● Peak test
Source: Abstracta.us
● Automated with test
harness
● Scripted behaviour
The University of Sydney Page 53
Understanding the performance bugs
● Can’t be reproduced in
most functional tests
● When one component Lambda Main Lambda
starts to flat out Enque queue Deque
(performance hit), the
issues affects multiple
components Failed item
Timeout ~ 10
seconds
● Often the issue then Retry
Offline
processing
becomes unpredictable
● Lambda enqueue, main
queue, Lambda Backup
dequeue, backup queue
queue Indefinite
loop
The University of Sydney Page 54
Logging is Essential
- Logs
- Access logs
- Application logs / Error logs
- Database access logs
- Database system logs
- OS system logs
- Infrastructure activity logs
- ElasticSearch / Kibana (ELK stack)
- Filters & key words
- Error information
The University of Sydney Page 55
Example of Automated Loop
Access logs
• 80% requests
are from 5
IP’s • Access log suggests
there is a potential
issue with five source
IP addresses being
Update attackers
Static Error • Automated Access
ACL:
page Control List update
Block 5 IPs
• Detection of 40x, client
errors
• Display the error page
that is predefined as a
static one
Error logs:
HTTP 40x
The University of Sydney Page 56
Design for failure
● Anything may fail
○ A piece of code
○ A software service
○ AWS zone
○ AWS service
● Failure modes
○ Complete outage
■ Losing a zone multiple zones
■ One or more services go
offline
○ Degraded service levels and slow
response
○ Performance bugs
● Design for negative paths
○ Error injection and handling
○ Simulation and tests
○ Try Chaos Monkey
The University of Sydney Page 57
Monitoring, monitoring and monitoring
● Successful operation is
based on monitoring
● Multiple layers of
monitoring
○ Uptime
○ AWS services
○ Health checks
○ DNS
○ Application performance
○ Security monitoring
● Tools - native and third
party
○ AWS CloudWatch, xRay
○ New Relic, Splunk, SumoLogic
○ Service dashboard
○ Cloud Ping
● Dashboard or notification
The University of Sydney Page 58
Application Performance Monitoring (APM)
● Metrics, metrics and
metrics
● Insights down to the
component level
● Real-time alerts
● Reference data for
future re-architecture
● Examples are AWS x-
ray, Google Cloud
Stackdriver
The University of Sydney Page 59
Synthetic transactions : Making it real in PROD
● Synthetic transactions (ie
fake transaction)
● Built-in during
development
● Specially designed route
and condition usually the Source: tek-tools.com
most critical one
● No impact to real
production
The University of Sydney Page 60
You reached the end of the lecture.
Thank you and see you next week.
The University of Sydney Page 61
