Software Engineering Reengineering

A sequence of characters, typically enclosed in quotation marks.

The process of analyzing program data flow to identify anomalies and understand how data is used and manipulated.

A portion of a program containing instructions and predicates that influence the value of a variable at a specific point in the code.

A portion of a program containing instructions and predicates that depend on the value of a variable at a specific point in the code.

The process of analyzing the structure and flow of control in a program to understand how the program executes.

A structured approach to transforming legacy software systems into more maintainable and modern versions without altering functionality.

A model that guides software reengineering by organizing elements related to functionality, documentation, database, and metrics.

A set of distinct phases that constitute the reengineering process, including planning, analysis, renovation, testing, and transition.

The initial phase of software reengineering where the current system is analyzed, potential issues are identified, and requirements for the new system are defined.

The core phase of software reengineering where the legacy software is transformed (renovated) into the desired target system.

Involves transforming the source code, design model, and/or requirement specification of the existing system into a more maintainable format.

Deals with the transformation of the database and/or data files used by the system, often referred to as data reengineering.

Emphasizes ensuring the reengineered system meets the planned requirements and functions correctly.

This phase involves analyzing and understanding the legacy source code. The goal is to extract key design components and requirements, preparing the system for transformation.

This involves transforming the legacy system's code into a new, more suitable programming language while preserving its functionalities. This significantly improves the maintainability and efficiency of the system.

This phase addresses the challenges of detecting and fixing issues introduced during the reengineering process due to code modifications. It ensures the reengineered system meets its intended requirements and functionality.

This involves updating, revising, and/or creating new documentation for the reengineered system to reflect the changes made to the code and design. It ensures system clarity and maintainability.

This is the final stage where the completed reengineered system is assessed against predefined acceptance criteria to ensure it meets the desired standards and functionality.

This involves replacing the original system with the reengineered system and deploying it to production. It smoothly transitions the users to the upgraded version.

Extracting the current structure of data from its original format (like code or a database). Imagine taking apart a Lego model and listing all the bricks and how they're connected.

Creating a high-level description of what the data means, like defining the concepts and relationships. Imagine drawing a diagram that shows how the Lego bricks relate to each other.

Analyzing the source code to understand its structure, flow, and logic. Imagine dissecting a program to understand how it works on the inside.

Analyzing the database or data files to understand their structure and content. Imagine exploring the storage of a program's data.

The process of analyzing existing data assets in a system to understand their structure, relationships, and dependencies, with the goal of improving their usability and value.

The recovery and reconstruction of data assets from an existing system, enabling their use in a new or improved system.

A specific type of DRE that focuses on understanding and redocumenting an application's database and files.

An abstract, implementation-independent representation of the data stored in a database, describing the entities, attributes, and relationships.

A concrete representation of the data structures used in a database, reflecting how the data is stored and managed.

A specific implementation of the logical schema, defining how the data is physically stored on the database system.

The process of translating a conceptual schema into a logical schema, then into a physical schema for implementation.

The process of analyzing an existing database system to extract its conceptual schema, logical schema, and physical schema.

The process of transforming executable binary code (machine-readable) back into readable high-level source code (like C++ or Java). This is like reverse engineering, but focuses specifically on the code.

A program that takes an executable file and attempts to produce understandable source code. The output might not be identical to the original, and might not even be in the same programming language.

A program that takes an executable file as input and generates assembly language code.

A reverse engineering technique that aims to create a higher-level representation of a system (like source code or design diagrams) from its lower-level representation (like executable code).

The act of converting high-level source code into executable binary code, which is what computers can understand.

A potential application of decompilation where you can recover lost source code, potentially saving time and effort.

Decompilers can help spot and fix errors within a software system, particularly those hidden within compiled code.