EN 
DE 
Sometimes simply extending old code isn't enough: a complete overhaul is needed. This article describes the process of embedded software redesign and explains the concepts of reverse engineering, refactoring, and reengineering.
Event formats like workshops are ideal for capturing and documenting requirements with the relevant knowledge holders. No tools exist on the market for deriving requirements from program code. This requires manual work. Experience shows that it is impossible to capture all requirements implemented in the software.
The corresponding acceptance criteria are now developed and documented based on the captured requirements. Besides certain UML tools, ALM (Application Lifecycle Management) or PLM (Product Lifecycle Management) tools are suitable, such as... IBM DOORS for documenting requirements and acceptance criteria.
Figure 4: Flowchart decision aids for software reverse engineering, part 2
Ideally, an automated and traceable software test can be performed based on the acceptance criteria to verify the software's observable behavior. This behavior, as well as the requirements and acceptance criteria, must not change during the software redesign. As a compromise, reverse engineering in practice is often limited to creating the software documentation.
Once the prerequisites for a successful embedded software redesign are in place, you can begin with software refactoring. Software refactoring improves the internal software structure and coding of the finished software without altering its externally observable behavior.
A distinction is made between "small" and "large" refactoring. Small refactoring refers to changes at the source code/design level, while large refactoring is responsible for changes at the architectural level. A large refactoring automatically results in several smaller refactorings.
Figure 5: Prerequisites for a successful redesign with refactoring
As mentioned previously, the embedded software must behave externally in the same way after refactoring as before. This should be verified after each refactoring by rerunning the unchanged software tests. Please only add new features after a successful refactoring.
The process for embedded software refactoring can look like this.
Figure 6: Embedded software refactoring
Taking the goal definition into account, you identify refactoring potentials, so-called "smells", in the embedded software (see the following table):
| Refactoring potential „Smell“ | Refactoring category | Refactoring selection |
| Large Method [3] ->Minor refactoring |
Simplify Conditional Expression [3] | Decompose Conditional [3] |
| Operating system porting not possible -> Major refactoring |
Extending the architectural layer model | Introduce OSAL (Operating System Abstraction Layer) |
Table 1: Refactoring Examples
Pre-built refactoring catalogs offer individual refactorings categorized into different types. You select the refactoring that best suits your needs and implement it. However, in embedded software, refactoring requirements are often highly specialized, meaning you may need to develop your own refactorings and categories.
A modern program code editor such as Eclipse Alternatively, suitable plug-ins can assist with refactoring implementation. To use these, you must select the program code to be refactored; a menu will then offer suitable refactorings and implement them directly upon selection.
We implement major refactorings manually in small, planned steps. If you make changes at the software code level, you usually also need to adapt the unit tests.
Important: In many cases, it is only during the refactoring process that it can be assessed and decided whether the software can actually be meaningfully refactored or whether it would be more promising to redevelop the software.
In summary, software redesign is divided into optional reverse engineering, if one of the required artifacts is missing. You then perform refactoring until you achieve your goal.
As a further source on the topic of refactoring, I would like to mention Martin Fowler. Besides his book “Refactoring” is also his Refactoring Online Portal Recommended.
Figure 7: Flowchart for software redesign
Once all refactorings have been implemented and the embedded software behaves as before (proof via Software tests), then you must now at the latest the Software documentation Adjust. This is the only way to maintain the consistency of the embedded software artifacts.
Pro tipTransfer the refactorings you have performed into Guidelines, This prevents the same errors from creeping in again. Depending on the refactoring, you can also supplement your architecture, design, modeling, and/or coding guidelines with this.
Sometimes a software redesign in the sense of reverse engineering and refactoring is not enough.
An immature development process can also contribute to deficiencies in internal software quality. In this case, you need to optimize the development process, which is what we at Embedded Software-Reengineering to describe. A generic approach to doing this might look like this:
Figure 8: Embedded software reengineering
The optimization goals arise from current challenges that are not addressed in the development process. Depending on the company, the development process may not be documented. Or it may be documented, but not implemented by employees, or implemented inconsistently. Especially in these cases, we should clarify the actual development process.
Afterwards, everyone involved has the same view of the development process, and a goal-oriented analysis can be carried out. The aim here is to find the causes of the shortcomings. To eliminate these causes, we optimize the development process in a goal-oriented manner.
Now the optimized approach must prove itself in practice. In a pilot project, we will apply the optimized development process and verify at the end of the project whether we have achieved the originally defined optimization goals. If not, we must carry out another optimization run with a further pilot project.
Once we have achieved our optimization goals, we begin defining new optimization goals. Embedded software reengineering is a continuous process.
Checklist: How can a necessary redesign be avoided?
The need for embedded software redesigns can be effectively minimized with the following measures:
- High qualification of employees
- Raise awareness within the team of the importance of requirements, architecture, and design
- Model and document embedded software using UML (Unified Modeling Language).
- Create your own architecture, design, modeling, and coding guidelines.
- Thinking and acting in a future-oriented manner at all levels (management, project management and development).
- Development teams consisting of electrical engineers and (technical) computer scientists are formed
- Continuously adapt and optimize the development process
- The Clean Code Developer Initiative consequences
- Prevent software erosion permanently and automatically through the use of tools, e.g., Bauhaus Suite. Axivion
____________________________________________________
The first part of the series This addresses the question of when it is necessary to completely revise old code and considers the criteria of process quality, external product quality, and internal product quality. third part Among other things, it will examine how requirements can be identified and documented with the help of suitable knowledge holders.
Go to calendar view
Embedded software redesign guide:
Part 1 „Deficits and Triggers“
Part 3 „Requirements and Checklist“
Further information
MicroConsult Training & Coaching on the topic of software quality
MicroConsult expertise on the topic of software quality
