Maintenance & Reengineering

by Ronni Kahalani, Copenhagen School of Design & Technology.

With inspiration from the book Software Engineering - A Practitioner's Approach.

​

Regardless of its application domain, size or complexity,

computer software evolves over time.

Change drives this process and changes occurs continually.

Who am I?

Thank you for stopping by.

​

I’m Ronni. I hope you’re well and wish you a safe and worthy journey.

​

This presentation is part of the Software Engineering Series, from my lectures at Copenhagen School of Design & Technology.

​

You can view the Introducing Myself, if you want to know a little more about who I am.

​

All my presentations and materials are free and available at my blog post: Software Engineering.

​

​

Don’t let me uphold you,

continue your journey, go to next slide.

2

X /Twitter

@RonniKahalani

�LinkedIn

https://www.linkedin.com/in/kahalani/

�Blog�LearningIsLiving

Agenda

• Intro
• Quick Look
• Software Maintenance
• Reverse Engineering
• Reverse Engineering to Understand Data
• Reverse Engineering to Understand Processing
• Reverse Engineering User Interfaces
• Reverse Engineering – Software Tools

Intro

Regardless of its application domain, its size, or its complexity, computer software will evolve over time.

​

Change drives this process and occurs when:

• Errors are corrected.
• When the software is adapted to a new environment.
• When the customer requests new features or functions.
• When the application is reengineered to provide benefit in a modern context.

Intro

Detailed analyses of industry-grade software and systems in an effort to develop a unified theory for software evolution.

- by Manny Lehman and his colleagues over the past 40 years.

• The Law of Continuing Change (1974)*
• The Law of Increasing Complexity (1974)*
• The Law of Self Regulation (1974)
• The Law of Conservation of Organizational Stability (1980)
• The Law of Conservation of Familiarity (1980)*
• The Law of Continuing Growth (1980)*
• The Law of Declining Quality (1996)*
• The Feedback System Law (1996)

* 9^th Edition

Quick Look

• What is it?
• Consider any product that has served you well, but it's getting old.
• For a time, you try to fix it, patch it, even extend its functionality.
• That's called maintenance. It becomes increasingly difficult as the years pass.
• There comes a time when you'll need to rebuild it. That's reengineering.
• Who does it?
• Maintenance is performed by support staff that are part of the software engineering organization.
• Reengineering is performed by business specialists, and at the software level, reengineering is performed by software engineers.

Quick Look

Why is it important?

• The demands on business functions and the information technology that supports them are changing at a pace.
• Maintain continually to keep pace.

What are the steps?

• Maintenance corrects defects.
• Adapts the software to meet a changing environment.
• Enhances functionality to meet the evolving needs of customers.
• At a strategic level, business process reengineering (BPR) defines business goals, identifies and evaluates existing business processes, and creates revised business processes that better meet current goals.
• Software reengineering encompasses inventory analysis, document restructuring, reverse engineering, program and data restructuring, and forward engineering.

Quick Look

• What is the work product?
• A variety of maintenance and reengineering work products
• The final output is upgraded software
• How do I ensure that I've done it right?
• Use the same SQA practices
• Technical reviews assess the analysis and design models
• Specialized reviews consider business applicability and compatibility
• Testing is applied to uncover errors in content, functionality, and interoperability

Software Maintenance

It begins almost immediately, as software is released to end users and…

​

​

Software Maintenance

It begins almost immediately, as software is released to end users and…

• Within days, bug reports filter back to the software engineering organization.
• Within weeks, one class of users indicates that the software must be changed so that it can accommodate the special needs of their environment.
• Within months, another corporate group that wanted nothing to do with the software when it was released now recognizes that it may provide unexpected benefit.

​

They'll need a few enhancements to make it work in their world.

Software Maintenance

Challenge of software maintenance has begun:

• Faced with a growing queue of bug fixes.
• Adaptation requests.
• Outright enhancements that must be planned, scheduled , and ultimately accomplished.

​

As time passes, your organization finds that it's spending more money and time maintaining existing programs than it is engineering new applications.

Software Maintenance

Software organization to expend as much as 60 to 70 % of all resources on software maintenance.

​

Why so much maintenance is required and why so much effort is expended?

• Much of the software we depend on today is on average 10-15 years old.
• Another reason for the software maintenance problem is the mobility of software people.

​

Software Maintenance

Types of software maintenance

​

​

​

​

​

​

​

Software maintenance tasks

Software Maintenance

Both analysis and design lead to an important software characteristic that we call maintainability.

Challenges every senior software engineer has experienced:

• Software team (or person) that did the original work is no longer around.
• Worse, other generations of software people have modified the system and moved on.
• And today, there may be no one left who has any direct knowledge of the legacy system.

Software Maintenance

Maintainability is a qualitative indication of the ease with which existing software can be corrected, adapted, or enhanced.

• Software engineering is about is building systems that exhibit high maintainability.

​

What is maintainability?

• Exhibits effective modularity.
• It makes use of design patterns.
• Constructed using well-defined coding standards and conventions.
• Undergone a variety of quality assurance techniques.

Reverse Engineering

Extracting design information from source code

Reverse Engineering

Reverse engineering can extract design information from source code, but the abstraction level, the completeness of the documentation, the degree to which tools and a human analyst interact together, and the directionality of the process are highly variable.

• Abstraction level
• Completeness
• Interactivity
• Directionality
• Extract abstractions

Reverse Engineering Process

Reverse Engineering

Abstraction level

• Ideally, the abstraction level should be as high as possible.
• As the abstraction level increases, you are provided with information that will allow easier understanding of the program.

​

Completeness

• In most cases, the completeness decreases as the abstraction level increases.
• Difficult to develop a complete set of UML diagrams or models.

Reverse Engineering

Interactivity

• The degree to which the human is "integrated" with automated tools to create an effective reverse engineering process.
• In most cases, as the abstraction level increases, interactivity must increase or completeness will suffer.

​

Directionality

• One –way: All information extracted from the source code is provided to the software engineer who can then use it during any maintenance activity.
• Two-way: The information is fed to a reengineering tool that attempts to restructure or regenerate the old program.

Reverse Engineering

​

Extract abstractions

• Core activity of a reverse engineering.
• Evaluate the old program and from the (often undocumented) source code, develop a meaningful specification of the processing that is performed, the user interface that is applied, and the program data structures or database that is used.

Reverse Engineering to Understand Data

​

Occurs at different levels of abstraction

• At the system level, global data structures (e .g., files, databases) are often reengineered to accommodate new database management paradigms (e .g., the move from flat file to relational or object-oriented database systems).
• Reverse engineering of the current global data structures sets the stage for the introduction of a new systemwide database.

Internal data structures

Focus on the definition of classes of objects

• Accomplished by examining the program code with the intent of grouping related program variables.
• The data organization within the code identifies abstract data types.

​

For example, record structures, files, lists, and other data structures often provide an initial indicator of classes.

Database structure

Reengineering one database schema into another requires an understanding of existing objects and their relationships

Following may be used to define the existing data model as a precursor:

• Build an initial object model.
• Determine candidate keys.
• Refine the tentative classes.
• Define generalizations.
• Discover associations using techniques that are analogous to the CRC approach.

Finally, map the old database structure into a new database structure

Reverse Engineering to Understand Processing

Begins with an attempt to understand and then extract procedural abstractions represented by the source code.

The code is analyzed at varying levels of abstraction:

• System
• Program
• Component
• Pattern
• Statement

The overall functionality of the entire application must be understood before more detailed reverse engineering work occurs.

Reverse Engineering to Understand Processing

Look for sections of code that represent generic procedural patterns.

In almost every component…

• A section of code prepares data for processing (within the module).
• A different section of code does the processing.
• And another section of code prepares the results of processing for export from the component.

​

Within each of these sections, you can encounter smaller patterns:

• For example, data validation and bounds checking often occur within the section of code that prepares data for processing.

Reverse Engineering User Interfaces

Redevelopment of user interfaces are the most common types.

• Before a user interface can be rebuilt, reverse engineering should occur.

​

Merlo and his colleagues suggest 3 basic questions that must be answered:

• What are the basic actions (e .g., keystrokes and mouse clicks) that the interface must process?
• What is a compact description of the behavioral response of the system to these actions?
• What is meant by a "replacement”, or more precisely, what concept of equivalence of interfaces is relevant here?

Reverse Engineering User Interfaces

It is important to note that a replacement GUI may not mirror the old interface exactly, in fact, it may be radically different.

​

It is often worth while to develop a new interaction metaphor.

​

For example

• An old UI requests that a user provide a scale factor (ranging from 1 to 10) to shrink or magnify a graphical image.
• A reengineered GUI might use a touch-screen slide bar to accomplish the same function.

Reverse Engineering – Software Tools

​

Helps software developers understand complex or legacy C and C++ software: https://www.imagix.com/

​

Help you understand, navigate and maintain source code�(Ada, Fortran, C, C++, C#, PHP, HTML, JavaScript, Python and Java�https://www.scitools.com/

​

Finally…

​

It has been created by software engineers who recognize that they may not be around when changes must be made.

​

Therefore, the design and implementation of the software must “assist" the person who is making the change.

Questions?

Anything? What’s on your mind? Come on ask me anything…

​

Feedback?

Thank you for your precious time.

I hope it was worth it and would love to get your feedback.

​

Please share your feedback here