Se Code Restructuring With Notes

ETH

Eidgenössische Technische Hochschule Zürich Swiss Federal Institute of Technology Zürich

Reverse Engineering

Code Restructuring

Mainframe

Guest Lecture Session: Basic Techniques October 2007 – 3rd Version

presented by

Dipl. Ing. Ing. Werner Hoffmann EMAIL: pwhoffmann@[email protected] See: © Copyright Note in Note Page.

Date: 27.10.2007

A member of IEEE and ACM Please see the notes pages for additional comments.

SE_CodeRestructuring.ppt

Page: 1

Welcome to the guest lecture called “Code Restructuring". This lecture is one small part of “Reverse Engineering”. © Note: Permission to make digital or hard copies of all or parts of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

1

Audience

Reverse Engineering Code Restructuring © 2007

At least this session may be interested for: • Researcher for Education / Training, • IT Professionals, • Professors, and Students.

"Learning is experience. Everything else is information.“ Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 2

Let me first give a statement about the ANTICIPATED AUDIENCE: We anticipate the audience will consist of participants who are interested in beginning to conduct more rigorous education research, past participants in the “Introduction to Education Research” workshops, ,IT Professionals who are establishing their research careers, and participants who need some protected time and space to think about their research without phones ringing and email dinging. At least this session may be interested for: •Researcher for Education / Training, •IT Professionals, •Professors, and Students.

2

Agenda

1. Introduction 2. Review: Structured Programming 3. Basic Code Restructuring Methods 4. The Spaghetti Bowl Approach 5. Indecomposable program figures 6. Conclusion Note: Some exercises are available!

Date: 21.06.2007

Code Restructuring

Page: 3

Here is the agenda for my session.

3

Agenda

1. Introduction 2. Review: Structured Programming 3. Basic Code Restructuring Methods 4. The Spaghetti Bowl Approach 5. Indecomposable program figures 6. Conclusion

"You do not really understand something unless you can explain it to your grandmother." Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 4

4

Introduction

(1)

Learning to write computer programs is not easy: • Students have difficulty learning programming as they are trying to develop skills in three areas at the same time, these being:

• using the program development environment; • learning the programming language syntax; • and developing logic design.

You need to improve your unstructured code – this session might be right for you…

• With respect to the above, good pedagogy therefore requires the instructor to keep initial facts, models, and rules simple and only expand and refine them as students gain experience.

This session is about “Code Restructuring”. As a result students should get better understand what “structured programming” means. Date: 21.06.2007

Code Restructuring

Page: 5

See above…

5

Introduction

(2)

Defining the 'R' words for maintenance: • Reverse Engineering, • Restructuring, • Reusability. Definitions for the most common "buzz words" in the field of reverse engineering:

This session is about “Restructuring”.

• Forward Engineering, • Reverse Engineering , • Re-documentation , • Design Recovery , • Restructuring , • Reengineering . Date: 21.06.2007

“Insanity: doing the same thing over and over and expecting different results.” Albert Einstein.

Code Restructuring

Page: 6

DEFINING THE "R" WORDS FOR MAINTENANCE: "Don't touch that program! It's working, sort of, and nobody quite knows why. It's the monster program of the system and really does most of the work, but there is no one left from the original development team who can remember exactly what it does. So we leave it alone and add enhancements to the other programs in the system. Let sleeping programs lie.“ This kind of warning, generally given to the new member of the maintenance team, became far too common to suit most modern IT managers. From their call for help was born the field of reverse engineering. According to Eric Bush, chairman of Language Technology, Inc., Salem, Mass., "At the beginning of 1987 there were approximately 750,000 programmers and analysts in the U.S. alone, representing over $54 billion in annual outlay to support the current, largely manual, state of software work...80% of our programming resources go to the adapting of software to meet constantly changing business needs.“ As more systems are developed, more dedicated maintenance programmers will be needed to keep up with changing demands. But by concentrating on maintenance, programmers are not free to create new systems. Automation of the maintenance, effort, or reverse engineering, is the most plausible solution to this dilemma. In theory, reverse engineering holds great promise: The 80 billion or so lines of code that demand so much of IT resources can finally be brought under control with the use of Case tools that can read, analyze, document and rework code into a set of structured and easily maintainable programs. Furthermore, in theory the programs can be converted into almost any other language, database, operating system, communications technology or hardware that is on the market today. Definitions for the most common "buzz words" in the field of reverse engineering: The definitions are as follows: * Forward Engineering--the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of the system. * Reverse Engineering--the process of analyzing a subject system to identify the system's components and their interrelationships, and to create representations of the system in another form or at a higher level of abstraction. * Re-documentation--the creation or revision of a semantically equivalent representation within the same relative abstraction level. The resulting forms of representation are usually considered alternate views intended for a human audience. * Design Recovery--a subset of reverse engineering in which domain knowledge, external information and deduction or "fuzzy" reasoning are added to the observations of the subject system to identify meaningful higher-level abstractions beyond those obtained directly by examining the system itself. * Restructuring--the transformation from one representation form to another at the same relative abstraction level, while preserving the subject system's external behavior (functionality and semantics). * Reengineering (also Renovation and Reclamation--the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form.

6

Introduction

(3)

This session is about “Restructuring”: • Software Restructuring: • transforms a program’s source code into a more ‘‘structured’’ form, thereby improving its maintainability and prolonging its life. • Motivation: • Software Maintenance • Structure of a program refers to: • structure of the code, • structure of the system. We only look at the structure of code. Date: 21.06.2007

Code Restructuring

Page: 7

Restructuring: Software restructuring is a form of perfective maintenance that modifies the structure of a program’s source code. Its goal is increased maintainability to better facilitate other maintenance activities, such as adding new functionality to, or correcting previously undetected errors within a software system. Software restructuring transforms a program’s source code into a more ‘‘structured’’ form, thereby improving its maintainability and prolonging its life. Motivation: Software maintenance involves correcting (removing functional errors), adapting (enhancing), or perfecting (improving efficiency or performance) of software after its release for production use . It can count for more than 50% of the costs in the lifetime of a software system. Any technique that could reduce its cost is obviously valuable. Maintenance is difficult because a maintainer must first understand the system before making changes; this currently accounts for about half of a maintenance programmer’s time. The program is hard to understand if the original program was poorly written, or if previous maintenance degraded the program’s structure. The structure of a program refers to both the structure of the code (called structured programming or programming-in-the-small) and the structure of the system (called module structure or programming-in-thelarge. Structured programming is an ‘‘art of reasoning’’ about the task, being able to abstract different levels of understanding of a problem, and connect them together in a hierarchy. Good module structure can be achieved by applying information hiding, in which every module hides a design decision, allowing the modules to be understood independently. Although both these techniques were developed in the early 1970’s, some estimate that most programs in use today are unstructured. Good software structure can make the task of understanding the software much easier. This can reduce the cost of maintenance to as little as one third of the cost of maintaining unstructured programs. Rewriting the unstructured programs from scratch using structured programming and information hiding techniques is impractical because of high costs. Software restructuring is an alternative to software rewriting. However, this area has only recently begun to be studied, and further research is still required.

7

Introduction

(4)

This session is about “Code Restructuring”: • Software Restructuring: • Restructuring Stages:

We only look at a method for Code Level Restructuring.

• Code Level Restructuring, • Data Restructuring, • Procedural Restructuring, and • Re-modularization. Note: Before you start a Code Restructuring task, take a short Analysis about program understanding: Program understanding is the process of developing mental models of a software system, at various levels of abstraction (top-down, bottom-up, or opportunistic strategies). If you find a very bad design, a bad solution (which may address one of the other points mentioned above), Code Restructuring may not help to solve your problem! Date: 21.06.2007

Code Restructuring

Page: 8

Software Restructuring: Software restructuring creates an ‘‘equivalent structured replacement’’ from an unstructured source program. This can involve many types of transformations whose common goal is to make programs easier to understand and maintain. One way to make the study of restructuring easier is to divide it into smaller pieces, and view restructuring as a sequence of specialized restructuring stages: code level restructuring), data restructuring, procedural restructuring, and re-modularization. Code Level Restructuring: Code level restructuring transforms program code to adhere to structured programming principles. You may identify several forms of code unstructuredness (often called ‘‘spaghetti code’’): jump into a decision, jump out of a decision, jump into the forward path of a loop, jump out of the forward path of a loop, jump into the backward path of a loop, and jump out of the backward path of a loop. These problems makes it difficult, if not impossible, to understand and maintain the code. Code level restructuring is a logical first step in a complete restructuring since it greatly simplifies the following stages by allowing them to make additional assumptions about the source code. Data Restructuring: Data restructuring makes the data structures and variable usage of the program more sensible. Data structure analysis includes making sure that all components of the data structures are related, that closely related data are not in separate structures, and that the best type of data structure is used. The data is much easier to understand if it is in a representation that abstracts its relevant similarities. Variable analysis includes determining if variables are overloaded (that is, have two or more distinct roles), if a global variable should be local, and if variable parameters should be value parameters. Procedural Restructuring: Procedural restructuring divides a program up into a logical set of routines. While many programs are already divided into routines, they are not necessarily the best possible divisions. Each routine should have only one entry point and one exit point, it should do a single abstract function, and the routines should be organized into a hierarchy. Procedural restructuring may involve significant changes in the parameterization of routines, and may force further data restructuring. Remodularization: Remodularization is the restructuring of an existing system into a modular hierarchy; it involves moving routines into appropriate modules. There are two distinct methods. Full remodularization involves the complete redesign of the modular structure. A designer deduces the requirements of the new system from the functionality of the old, then defines a new modular structure, independent of the existing structure. Maintainers then reorganize the source code into the new design. This method requires a large amount of effort all at once. Incremental remodularization involves examining the source code for recognizable information hiding modules and extracting them one by one. As more modules are recognized and extracted, the unstructured portion becomes smaller, making it easier to recognize additional modules. This method amortizes the restructuring over a long time, but requires a larger total investment than for full remodularization, and the resulting module structure may not be as good.

8

Introduction

(5)

Example: (Convert Julian date into Gregorian date)

Bad Design/Solution Don’t try to restructure this code. The problem here is missing data structures to solve the problem!

It’s a problem of data restructuring, not a problem of code restructuring! Date: 21.06.2007

Code Restructuring

Page: 9

In the above example I show a really bad program design/solution for a simple problem: convert Julian dates into Gregorian dates. Don’t try to restructure this code. The problem here is missing data structures to solve the problem! It’s a problem of data restructuring, not code restructuring! A possible solution is shown on the next foil.

9

Introduction

(6)

Example: (Convert Julian date into Gregorian date)

A better solution:

Note: This coding may not be a perfect solution; but may be a good starting point for further investigations. Date: 21.06.2007

Code Restructuring

Page: 10

A better design/solution of the problem is shown in the above foil. Note that “Data Restructuring” is not part of this session! Note: This coding may not be a perfect solution; but may be a good starting point for further investigations.

10

Introduction

(7)

Previous Research: • Basic works: Dijkstra – debate over the use of GOTO statement. • Code and Procedural Restructuring: Böhm and Jacobi – transform arbitrary flow diagrams into structured flow diagrams. • Ashcroft and Manna extended this by introducing an algorithm for transforming arbitrary “goto programs” into equivalent “while programs”. • Peterson showed how to transform any program into “well-formed” program, that only use if, repeat, and multi-level exit statements. • Yourdon introduced a boolean flag approach to eliminate multi-exit loops. • Linger introduced a technique for parsing arbitrary flowgraphs into their prime components: sequence, if-then-else and while-do. • There are published several work available for a fully automatic FORTRAN “structure engine”. Additional several work where published to restructure COBOL programs.

Date: 21.06.2007

Code Restructuring

Page: 11

Previous Research: High-level programming languages were first developed in the mid 1950’s. Among the first of these were FORTRAN and COBOL, both of which are still widely used today. The main criteria for determining how good a program was were its speed and its size. This encouraged programmers to develop ‘‘tricks’’ and their own personal programming style. Throughout the 1960’s computers became faster, cheaper, and their memory capacity increased. Applications increased in difficulty and size, but programming styles remained the same. As programs grew larger, they became more and more difficult to understand. Dijkstra attributed this to a lack of structure in programs, and sparked a debate over the use of the goto statement that continued for years. Knuth outlines the history of this debate. With the introduction and gradual acceptance of structured programming, newly developed programs became easier to understand. It was natural to try to find a way to get the benefits of structured programming out of the many unstructured programs previously written, without having to rewrite them. Code and Procedural Restructuring: Bohm and Jacopini showed it is possible to transform arbitrary flow diagrams into structured flow diagrams, sometimes by adding boolean variables. Ashcroft and Manna extended this by introducing an algorithm for transforming arbitrary ‘‘goto programs’’ into equivalent ‘‘while programs.’’ Peterson et al. showed how to transform any program into a ‘‘well-formed’’ program that only used if, repeat, and multi-level exit statements. Yourdon introduced a boolean flag approach to eliminate multi-exit loops. Linger et al. introduced a technique for parsing arbitrary flowgraphs into their prime components: sequence, if-then-else, and while-do. De Balbine used these ideas in his fully automatic FORTRAN ‘‘structuring engine’’ developed for Caine, Farber, and Gordon, Inc. It does not do any data restructuring or remodularization, but does some procedural restructuring if blocks of code appear more than once. It translates each subprogram into a flowgraph, transforms these into structured flowgraphs using nodesplitting, then translates the result to S-FORTRAN, a superset of FORTRAN with structured constructs. Baker’s STRUCT program at Bell Laboratories translates FORTRAN into RATFOR (another extended FORTRAN). In the early 1980’s the amount of work done in software restructuring continued to increase, particularly in the area of COBOL code and procedural restructuring. Lyons and Miller developed Structured Retrofit for the Catalyst Corporation. It makes programs more readable by removing all ALTER statements, eliminating procedure overlap caused by PERFORM THRU statements, eliminating some GOTOs by introducing PERFORMs, converting NOTEs to comments, eliminating control flow falling through one paragraph to the next, and removing unreachable code. To improve structure it creates an isolated control hierarchy, highlights looping conditions, places bounds on action modules, groups and standardizes all I/O, and consolidates all program termination to a single goback. Also in 1981, Sage Software Products developed a COBOL restructurer to salvage a client’s unmaintainable (but properly working) software system. The restructurer generates a functionally equivalent version in structured pseudocode, which it then translates to COBOL. The total cost, including the restructurer, was less than 10% of the lowest estimate for rewriting the system. Group Operations Inc. introduced another COBOL restructurer in 1984, called Superstructure. This program evolved from SCAN/370, a COBOL static analyzer that helped maintainers understand unstructured COBOL programs. Superstructure placed all PROCEDURE DIVISION code in independent single entry/single exit procedures, eliminated GOTO statements except those to the beginning or exit point of the paragraph that contained them, removed all paragraph fall-throughs and ALTER statements, put unreachable code in comments, and eliminated PERFORM range violations. Harandi at the University of Illinois at Urbana-Champaign was more interested in the theoretical aspects of COBOL restructuring. His restructurer removes ALTER statements, replaces GOTO-DEPENDING-ON statements with IF-THEN-ELSE statements, transforms all procedures into single entry/single exit routines, transforms unstructured flows of control to structured equivalents, and simplifies complex control structures by simulating them with disciplined uses of GOTO statements. This work also provides experimental results showing the improved maintainability of restructured programs.

11

Introduction

(8)

• As noted previous this session is about code level restructuring:

• Code refactoring: • A code refactoring is any change to a computer program's code which improves its readability or simplifies its structure without changing its results. • Note that I do not want to create the impression that this is an easy job, though.

• I’m using flowcharts to show a manually driven method to transfer unstructured code into structured code. • The method don’t change data dependency! Used symbols:

1

p

A

• This method is completely independent from any computer language. To be independent , I will show Code only as Pseudo Code. Date: 21.06.2007

Code Restructuring

Page: 12

As noted previous this session is about code level restructuring. The meaning of Code Refactoring is: A code refactoring is any change to a computer program's code which improves its readability or simplifies its structure without changing its results. I’m using flowcharts to show a manually driven method to transfer unstructured code into structured code. Only four symbols of the flowchart technique are used: Arrow, node, block (a sequence of sequential processed statements), decision (with a T-true and a F-false path). The used method don’t change any data dependency; therefore an input/output analysis is not needed. This method is completely independent from any computer language.

12

Introduction

(9)

Refactoring dos and don'ts Do: • Refactor in stages. Thoroughly test at each stage of the refactoring process. • Apply refactorings that will make adding new function easier before adding those new functions. This may seem obvious, but it's often tempting to get new functionality working before cleaning up the code. • Accept that some refactorings will look good on paper but may add more complexity to your code. Be prepared to back them out.

Don't: • Try not to refactor based on what you think future requirements will be. Refactoring is based on the state of things today.

Date: 21.06.2007

Code Restructuring

Page: 13

What is Refactoring? Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring. For refactoring dos and don’ts see above foil…

13

Introduction

(10)

An Example: “Spaghetti-Code”, Unstructured Flowchart.

…copied from IBM Independent Study Program, Structured Programming.

Date: 21.06.2007

Code Restructuring

Page: 14

This is an example of “Spaghetti Code” I copied from IBM Independent Study Program, Structured Programming.

14

Introduction

(11)

An Example: Our goal:

Structured Flowchart, Structured Pseudo-Code.

Levels of Indentation 1-4

w

…copied from IBM Independent Study Program, Structured Programming.

Date: 21.06.2007

Code Restructuring

Page: 15

This is an example of a wanted structured flowchart/Structured Pseudo-Code. In the next chapter I like to review the basic code control elements in structured programming. Thereafter I like to explain, how we can restructure the unstructured code with some basic formal methods to get our wanted structured flowchart or Pseudo Code.

15

Agenda

1. Introduction

2. Review: Structured Programming 3. Basic Code Restructuring Methods 4. The Spaghetti Bowl Approach 5. Indecomposable program figures 6. Conclusion

"Great thinkers have always encountered opposition from mediocre minds." Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 16

16

Review: Structured Programming

(1)

I like to look at following main points: 1. Basic Control Logic Structures 2. Equivalent Control Logic Structures 3. Proper Programs “Intellectuals solve problems. Geniuses prevent them.” Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 17

… see above.

17

Review: Structured Programming

(1)

1) Basic Control Logic Structures: 1. Single Block: A

2. IF THEN ELSE Block: A

T p F

1 B

3. DO WHILE Block: A 1 Date: 21.06.2007

T p

F

Code Restructuring

Page: 18

1) Basic Control Logic Structures: The theoretical results deal with converting arbitrarily large and complex flowcharts into standard forms so that they can be presented by iterating and nesting a small number of basic and standard control logic structures. A sufficient set of basic control logic structures consist of three members: 1. A sequence of sequential executed operations (BLOCK), 2. A conditional branch to one of two operations and rejoined (an IF_THEN_ELSE structure), 3. Repeating an operation or block of operations while some condition is true. (a DO_WHILE structure). Note that each structure has one input and one output and can be substituted for any box in a structure, so that complex flowcharts can result. A major characteristic of programs written in these structures is that they can be literally read from top to bottom typographically; there is never any “jumping around” as is so typical in trying to read code that contains general GOTO’s. This property of readability is a major advantage in debugging, maintaining, or otherwise referencing code at later times. Another advantage of possibly even greater benefit is the additional program design work that is required to produce such structured code.

18

Review: Structured Programming

(2)

2) Control Logic Structure Equivalences: Example 1: REPEAT UNTIL Block: Basic Control Logic Structure:

Pseudo-Code:

A

T

1

A

p

F

A DOWHILE (p) A ENDWHILE

Equivalent Control Logic Structure: Pseudo-Code:

F 1

A

q

T

where q = ¬p

REPEAT A UNTIL (q)

REPEAT_UNTIL (q) Date: 21.06.2007

Code Restructuring

Page: 19

2) Control Logic Structure Equivalences: We will say that two proper programs (control logic structures) are equivalent when they define the same program function, whether or not they have identical control graphs, require the same number of operations, and so on. Example 1 shows an equivalent control logic structure; first the basic control logic structure is shown. After that I show the equivalent control structure (REPEAT_UNTIL).

19

Review: Structured Programming 2) Control Logic Structure Equivalences: Example 2: CASE Block:

Basic Control Logic Structure: F1

T p1 F

T p2 F

1

F2 T …

n

pn F

Date: 21.06.2007

2

Fn

Fotherwise

Code Restructuring

(3)

Pseudo-Code: IF p1 THEN F1 ELSE IF p2 THEN F2 ELSE … … IF pn THEN Fn ELSE Fotherwise ENDIF … ENDIF ENDIF Pseudo-Code: CASE_ENTRY CASE (p1) F1 CASE (p2) F2 … CASE (pn) Fn OTHERWISE Fotherwise END_CASE Page: 20

2) Control Logic Structure Equivalences: Example 2 shows an equivalent control logic structure; first the basic control logic structure is shown. On the right side I show the Pseudo code using only basic control logic structure and at the bottom the equivalent program logic using a new defined Control Logic Structure called CASE block.

20

Review: Structured Programming

(4)

2) Control Logic Structure Equivalences: -

You can use/define additional equivalent program structures: -

Pseudo-Code:

For example -

Iterative DO

-

LOOP’s

-

CASE block’s

-

SEARCH block’s

-

etc.

DO v = exp1 TO exp2 BY exp3 F1 ENDDO LOOP F1 EXITIF (p1) … Fn ENDLOOP SELECT (exp) CASE (1) F1 CASE (2) F2 … OTHERWISE Fotherwise ENDSELECT etc.

Date: 21.06.2007

Code Restructuring

Page: 21

2) Control Logic Structure Equivalences: You can use/define additional equivalent program structures. The only request is that they have to follow the structured programming theorem: one entry point and one exit point and the meaning of the control logic structure is well defined.

21

Review: Structured Programming

(3)

3) Proper Program (example) : 1

Levels of Indentation 1-3

3

F p3

Pseudo-Code:

T

DOWHILE (p1) IF (p2) THEN DOWHILE (p3) B ENDWHILE ELSE A ENDIF ENDWHILE C

B A

2 p2 F

p1

T

T F

The goal is to construct a well defined hierarchy for the solution.

C

Date: 21.06.2007

Code Restructuring

Page: 22

3) Proper Program: A Proper Program is a program that is constructed in such a way that the program, each of its modules, and each of its control structures has the following characteristics: No dead code; no infinite loops; one entry point and one exit point.

22

Agenda

1. Introduction 2. Review: Structured Programming

3. Basic Code Restructuring Methods 4. The Spaghetti Bowl Approach 5. Indecomposable program figures 6. Conclusion "I have no special talents. I am only passionately curious." Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 23

23

Basic Code Restructuring Methods “Imagination is more important than knowledge. Knowledge is limited, imagination circles the world...” Albert Einstein.

• For the code restructuring process I use a flowchart of the unstructured program. • In the following foils I explain basic transformation methods. • The goal of the transformation is to get basic structured control logic figures (BLOCK, IF_THEN_ELSE, and DO_WHILE). Date: 21.06.2007

Code Restructuring

Page: 24

For the code restructuring process I use a flowchart of the unstructured program. In the following foils I explain basic transformation methods. The goal of the transformation is to get basic structured control logic figures (BLOCK, IF_THEN_ELSE, and DO_WHILE).

24

Interchange

“Example isn't another way to teach; it's the only way.”

(2)

Albert Einstein.

1) Interchange - Example: T T

p

p

F

F A

A

B

B 1

1

Interchange

1/2

2

2

q

T

C

q

F

T C

F Structured Code: IF_THEN_ELSE, DO_WHILE

Unstructured Code Date: 21.06.2007

Code Restructuring

Page: 25

Interchange Method: The “Interchange method” permits exchanging initial lines and exit lines at two or more adjacent crossing points. The unstructured code is shown on the left side. Using the “Interchange Method” pointing to Connector ½ you can establish two basic control structures as shown on the right side: A IF_THEN_ELSE structure followed by a DO_WHILE structure.

25

Transposition

(1)

2) Transposition: A 1

A

=

1 A

A 1

=

1

A

A

Date: 21.06.2007

Code Restructuring

Page: 26

Transposition Method: Two rules have to be taken into account: 1) With the “Transposition Method” a functional block A which hangs on an exit line of a node is moved to the two initial lines of the node. 2) Two equal functions (A, A) which leads to the same node can be pulled out and be put after the node once. The above shown examples and the examples on the next foil illustrate all combination possibilities of the “Transposition Method”.

26

Transposition

(2)

2) Transposition (continued) :

A

A

T

T p

=

p F

F

A

A

T

=

p F

Date: 21.06.2007

T A

p F

A

Code Restructuring

Page: 27

Transposition Method (continued): Instead of a connector (node) a predicate is used in the above example.

27

Transposition

(3)

2) Transposition - Example: T T

p

p

F

A

B

A

D

B

1

1

Interchange

D

1/2

T

Transposition

2

2

q

F

D C q

F

T C

F Structured Code: IF_THEN_ELSE, DO_WHILE

Unstructured Code Date: 21.06.2007

Code Restructuring

Page: 28

Transposition Method: The “Transposition Method” permits exchanging blocks across nodes or predicates as described earlier. The unstructured code is shown on the left side. Using the “Transposition Method” for block D into the preceding paths you get basic standard structures as shown on the right side: A IF_THEN_ELSE structure followed by a DO_WHILE structure. The False-Path if the IF_THEN_ELSE structure contains now block B,D and the True-Path of the DO_WHILE structure contains now block C,D.

28

Combination

(1)

3) Combination:

A

F1

B

F2

F3

Date: 21.06.2007

=

A,B

=

F3,F2,F1

Code Restructuring

Page: 29

Combination Method: The rule of the “Composition Method” says that two or more successive functions (code blocks) can be summarized to a common function. This is called composite function too. The order of the sub-functions is not changed. The above examples illustrate this technique.

29

Combination

(2)

T p

F

A

B

A

1

1

Interchange

D

2

2

q

T

D C q

F Step 1: Unstructured Code Date: 21.06.2007

T

p

F

B,D

A

D

B

1/2

F

T

F

Transposition Combination

T

p

Combination

3) Combination - Example:

1 2 C,D q

C Step 2:

T

F

Structured Code: IF_THEN_ELSE, DO_WHILE Code Restructuring

Page: 30

Combination Method: To show the method I’m using the previous example. The unstructured code is shown on the left side. In the first step we used the interchange and transposition methods to get the structured code as shown in the middle of the foil. We now can use the “Combination Method” for the False-Path of the IF_THEN_ELSE structure and for the True-Path of the DO_WHILE structure. Through this transformation the representation of the control structure is simplified.

30

Resolution

(1)

4) Resolution: c a

1

c A

2

m

b

Date: 21.06.2007

a

1

A

2

b

4

A

3

=

Code Restructuring

m

Page: 31

Resolution Method: The rule of the “Resolution Method” says that you can duplicate program figures (code blocks) to a given point, by importing further nodes. The above example illustrate this technique.

31

Resolution

(2)

4) Resolution - Example:

T

2

1

T

p

F

F

p

B

A

2 A

1

B 1,2

D

1

q

T

2

q

C

Unstructured Code

Date: 21.06.2007

D

2

1

C

q

T

F

F

D

T

3

C

F

Structured Code: (first step) Code Restructuring

Resolution

Page: 32

Resolution Method: This example shows how to use the “Resolution Method” by following each coding path 1,2 and adding additional nodes. As a result of this method we get in this example an IF_THEN_ELSE structure. This is a first step to translate the unstructured code into a structured one. Block D on the False-Path of the IF_THEN_ELSE structure needs additional steps: A “Transposition Method” as shown earlier. Additional a “Combination Method” can be used for code blocks C,D , B,D and C,D to get a structured code with basic elements. After that transposition a DO_WHILE structure is embedded on each path of the IF_THEN_ELSE structure.

32

Substitution

(1)

5) Substitution: A 1

T F

p

=

DoW (p) A Means: DO_WHILE

F A

1

q

T

=

Rep A U(q) Means: REPEAT_UNTIL

Entry

A “proper program” x

=

PGM x

Exit Date: 21.06.2007

Code Restructuring

Page: 33

Substitution Method: The rule of the "Substitution Method" says, that a function can be replaced by a "proper program" or subprogram or function-routine or code segment. Note: There is only one entry and one exit to this peace of code. The above examples illustrates this technique.

33

Combination

(2)

5) Substitution - Example: T

p

F

B,D

A

1

Substitution S1

2

SPGM S1

C,D q

T

F Structured Code Date: 21.06.2007

Code Restructuring

Page: 34

Substitution Method: To show the method I’m using a previous example. The structured code is shown on the left side. If this code represent a complete function, we can say that this code is a “proper program”-part (S1). This can be a codesegment, a new sub-program or function. Note: If you move this code to an external sub-program or function you have to look at data-dependencies too.

34

Inverse Notation

(1)

6) Inverse Notation: F

T

=

p

¬p

T

F A

1

A

F T

p

=

1

T F

¬p Means: DO_WHILE F

T 1

A

q

F

=

1

A

¬q

T

Means: REPEAT_UNTIL Date: 21.06.2007

Code Restructuring

Page: 35

Inverse Notation: Adding the NOT expression (or: ¬ symbol) in the front of the predicate will change the meaning of the outcoming paths. The “TRUE-Path” becomes the “FALSE-Path” and the “FALSE-Path” becomes the “TRUE-Path”. The above examples illustrates this technique.

35

Agenda

1. Introduction 2. Review: Structured Programming 3. Basic Code Restructuring Methods

4. The Spaghetti Bowl Approach 5. Indecomposable program figures 6. Conclusion "Today's problems cannot be solved with the level of thinking that created them.” Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 36

36

The Spaghetti Bowl Approach

(1)

Method: Draw a flowchart of the unstructured program logic. DO WHILE Spaghetti Bowl 1) FOR each Spaghetti Bowl DO Find an input line and an output line. 2) Pull at the initial line and observe what comes out. Proceed with following rules: 3) T Rule 1: You watch a condition: p Assume a IF_THEN_ELSE construct; F Use the “Resolution method” following both paths. Rule 2: You watch a node with 2 input lines: Assume a DO_WHILE construct; 2 Use restructure methods as described earlier A to get a DO_WHILE construct. 2 Rule 3: You watch an indecomposable program structure; T T Special action is needed (see next section) . q 1 p B F Check and Cleanup flowchart. 4) F Use restructure methods as described earlier. END Note: This technique can be used END for every problem; no matter how Rebuild complete source code using the structured Flowcomplex this problem may be. Chart or Pseudo-Code. Optionally redesign additional equivalent program structures. 5) B

2

C

T

Input line

D

p

F

T

A

q

1

output line

F

SB

Date: 21.06.2007

Code Restructuring

Page: 37

If we try to structure a traditional Flowchart, then it is not always ensured, that we succeed off-hand due to the detail methods described before. In such cases we can try to follow the “Spaghetti Bowl Approach" to solve the problem. The above procedure is a general description how to structure an unstructured program. Note: This technique can be used for every problem; no matter how complex this problem may be. Remarks: 1) “Spaghetti Bowl” means unstructured code or code parts. 2) All code between an input line and an output line is initially hidden code and may be unstructured completely or in parts. 3) The restructuring method is based on the basic figures of “Structured Programming”, which means BLOCK, IF_THEN_ELSE and DO_WHILE. 4) If you detect an equivalent “Structured Programming” construct, like REPEAT_UNTIL, DO_LOOP, CASE_Control_Structure, SEARCH_Structure etc. you may use this figure instead of the basic figures. 5) The basic transfer methods produce only the three elements BLOCK, IF_THEN_ELSE, DO_WHILE. For using some of equivalent program figures you need detailed information about each instruction. At least you only can do this transformation after you have rebuild the source code. Examples are iterative loops, implementing search algorithm with macros etc. Normally this task can be done easier if you have the source code in a structured form. I like to explain the method starting on the next foil.

37

The Spaghetti Bowl Approach

(2)

Step 1: Draw a flowchart of the unstructured code.

B

2

C

T Input line

D

p F

T A

Date: 21.06.2007

1

q

Code Restructuring

output line

F

Page: 38

If you only have a source list of the unstructured code, start with step 1: Draw a flowchart of the unstructured code. To explain the “Spaghetti Bowl Approach” I ‘ll use the flowchart shown in the above foil.

38

The Spaghetti Bowl Approach

(3)

Step 2.1: Conceal the complete program logic except for an initial line and an exit line.

B

2

C

T Input line

D

p F

T A

1

q

output line

F

SB

Date: 21.06.2007

Code Restructuring

Page: 39

The problem is orbited. The initial lines and exit lines are examined. The idea is pulling at an initial line to see what gets out of the “Spaghetti Bowl”.

39

The Spaghetti Bowl Approach

(4)

Step 2.2: Conceal the complete program logic except for an initial line and an exit line.

B

2

C

T Input line

D

p F

T A

1

q

output line

F

SB

Rule 1 : There is a condition, we assume a IF_THEN_ELSE construct.

Date: 21.06.2007

Code Restructuring

Page: 40

Following our procedure we now can detect a rule: As described earlier we assume a IF_THEN_ELSE structure. As described for the RULE 1 we now use the “Resolution method” to restructure both paths of the IF_THEN_ELSE figure.

40

The Spaghetti Bowl Approach

(5)

Step 2.3: Result B

2

C

D T T Input line

q

1

F

p F

2

output line

C

3

D T A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 41

The above figure shows the result of the “Resolution Method”.

41

The Spaghetti Bowl Approach

(7)

Step 3: Cleanup each SB. B

2

C

D T T Input line

SB1

q

1

F

p F

SB2

2

output line

C

3

D T A

1

q

F

IF_THEN_ELSE Date: 21.06.2007

Code Restructuring

Page: 42

After using the “Resolution method” we can define a IF_TEHN_ELSE structure. Looking at each path we now detect two smaller “Spaghetti Bowl”s: SB1 and SB2. For each SB we now try check what’s inside the bowl and we try to cleanup the flowchart.

42

The Spaghetti Bowl Approach

(8)

Step 3.1: Cleanup SB1 - Result. C

SB1

T B T

Input line

2

q

D

F

p F

SB2

2

output line

C

3

D T A

Date: 21.06.2007

1

q

F

Code Restructuring

Page: 43

The above foil shows the control flow for SB1 after cleanup. At least we only removed node 1.

43

The Spaghetti Bowl Approach

(6)

Step 3.2: Cleanup SB2 - Result. C

SB1

T B T

Input line

2

D

q

F

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 44

We now do the same for SB2. The above foil shows the result. We could use the “Combination method” for block C and block D. Additional we could remove node 2.

44

The Spaghetti Bowl Approach

(8)

Step 3.3: Result after cleanup SB1 and SB2. C SB1

T B

T

Input line

2

D

q

F

p output line

F

3

SB2 C,D T A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 45

The above foil shows the flowchart after the “Check and Cleanup” step.

45

The Spaghetti Bowl Approach

(9)

Step 4: Repeat SB Approach for SB1 and SB2. C SB1

T B

T

Input line

2

D

q

F

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 46

We now have to repeat the “Spaghetti Bowl Approach” for SB1 and SB2.

46

The Spaghetti Bowl Approach

(10)

Step 4.1: Repeat SB Approach for SB1. C SB1

T B

T

Input line

2

D

q

F

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 47

First we repeat the SB Approach for SB1.

47

The Spaghetti Bowl Approach

(11)

Step 4.1.1: Repeat SB Approach for SB1. C SB1 B T

Input line

T 2

D

q

F

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 48

Until yet nothing happened. We only see a BLOCK which is coming out. That’s ok.

48

The Spaghetti Bowl Approach

(12)

Step 4.1.2: Repeat SB Approach for SB1. C

Rule 2 : There is a node with 2 input lines, we assume a DO_WHILE construct.

B T

T 2

D

q

F

SB1 Input line

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 49

We now detect a node, which point to rule 2: We assume a DO_WHILE construct.

49

The Spaghetti Bowl Approach

(13)

Step 4.1.2: Repeat SB Approach for SB1. A DO_WHILE construct does not have a code block on the input line; we need to transport block D using the Transposition method.

B T

C T 2

q

D

F

SB1 Input line

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 50

Following the SB approach we now see a code block on the input line of a DO_WHILE construct. A DO_WHILE construct does not have a code block on the input line; therefore we need to transport block D outside the DO_WHILE construct. We can do this using the “Transposition Method.

50

The Spaghetti Bowl Approach

(14)

Step 4.1.3: Repeat SB Approach for SB1. 1) A DO_WHILE construct does not have a code block on the input line; we need to transport block D using the Transposition method.

B,D T

C,D T q

2

2) Additional we use the Combination method to cleanup the flowchart. Input line

F

SB1

3)

p

F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 51

After the transposition we can use the “Combination Method” to simplify the flowchart. The result is shown in the above foil.

51

The Spaghetti Bowl Approach

(15)

Step 4.1.4: Repeat SB Approach for SB1. C,D T B,D T

q

2

F SB1

Input line

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 52

We follow the SB Approach. Seeing the condition we now know, that the assumed DO_WHILE is a real DO_WHILE construct (the TRUE path is the repeating path). The remaining SB1 doesn’t contain any additional block or condition, so we finished.

52

The Spaghetti Bowl Approach

(16)

Step 4.1.5: Result for SB1. C,D T B,D T

F

DO_WHILE

block

Input line

q

2

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 53

The above foil shows the result for SB1. We got a BLOCK, DO_WHILE Structure inside the TRUE path of the IF_THEN_ELSE structure.

53

The Spaghetti Bowl Approach

(17)

Step 4.2.1: Repeat SB Approach for SB2. C,D T B,D T

F

DO_WHILE

block

Input line

q

2

p F

output line

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 54

We now repeat the SB Approach for SB2.

54

The Spaghetti Bowl Approach

(18)

Step 4.2.2: Repeat SB Approach for SB2. C,D T B,D T

F

DO_WHILE

block

Input line

q

2

p output line

F Rule 2 : There is a node with 2 input lines, we assume a DO_WHILE construct.

SB2

3 C,D T

A

Date: 21.06.2007

1

Code Restructuring

q

F

Page: 55

First we detect a BLOCK, which is ok. After that we detect a node and we can assume a DO_WHILE construct as described in Rule 2 of our general procedure.

55

The Spaghetti Bowl Approach

(19)

Step 4.2.3: Result for SB2. C,D T B,D T

F

DO_WHILE

block

Input line

q

2

p output line

F

SB2

3 C,D T

A

Date: 21.06.2007

block

q

1

Code Restructuring

DO_WHILE

F

Page: 56

We can follow the SB approach. In this case we have to nothing else. During the “Check and Cleanup” step we define a BLOCK figure followed by a DO_WHILE figure for the FALSE path of the IF_THEN_ELSE structure.

56

The Spaghetti Bowl Approach

(20)

Step 5, 5.1: Check flowchart. C,D T B,D T

p F

F

DO_WHILE

block

Input line

q

2

Same Code, we can use the transportation method to simplify the control structure.

3 output line

C,D T A

Date: 21.06.2007

block

q

1

Code Restructuring

DO_WHILE

F

Page: 57

Looking at the complete flowchart we now see that we have the same DO_WHILE figure at the end of each path of the IF_THEN_ELSE Structure. We can use “the Transposition Method” for this part to simplify the control flow.

57

The Spaghetti Bowl Approach

(21)

Step 5.2: Result.

Input line

C,D

B,D

T

T p

F

1

q

2

F

output line

A

IF_THEN_ELSE

Pseudo-Code:

Date: 21.06.2007

DO_WHILE

IF p THEN {B,D} ELSE A ENDIF DOWHILE q {C,D} ENDWHILE Code Restructuring

Page: 58

The above foil shows the final result of the restructuring method. In this case we have a IF_THEN_ELSE Structure followed by a DO_WHILE structure. At the bottom of the foil I show the corresponding pseudo code.

58

The Spaghetti Bowl Approach

(22)

Step 6: Rebuild source code . using the final structured flowchart, or . the structured Pseudo Code. Step 7: Optionally check whether additional equivalent program figures like iterative loops, search-blocks etc. may improve the reading/maintenance of the program. • If this is the case, analyze the code and rewrite the logic using predefined equivalent program elements.

Note: Do not forget to test the new code !!! Code Restructuring

Date: 21.06.2007

Page: 59

Step 6: Rebuild source code . using the final structured flowchart, or . the structured Pseudo Code. Step 7: Optionally check whether additional equivalent program figures like iterative loops, search-blocks etc. may improve the reading/maintenance of the program. If this is the case, analyze the code and rewrite the logic using predefined equivalent program elements.

59

Agenda

1. Introduction 2. Review: Structured Programming 3. Basic Code Restructuring Methods 4. The Spaghetti Bowl Approach

5. Indecomposable program figures 6. Conclusion "The secret to creativity is to know how to hide your sources.” Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 60

60

Indecomposable program figures

(1)

Indecomposable program figures can be restructured by adding a special flag construct to the program figure: Terms: TRUE FALSE POP TOP

Date: 21.06.2007

- allocate flag and set value to TRUE. - allocate flag and set value to FALSE. - deallocate flag. - Test Flag.

Code Restructuring

Page: 61

Having noted, that program figures may be indecomposable, we need to add the possibility of operations and tests to be able to restructure the flowchart. The additional operations and tests correspond to “flag” setting and testing. But we can coach these operations in the concept of a push down stack to show their economy. In addition to the functions and predicates original to a given program we introduce three new functions and one predicate as shown above. More specifically, we define process nodes with functions named TRUE, FALSE, and POP, and a predicate node with function named TOP, which add truth values TRUE and FALSE, remove and test such truth values, respectively.

61

Indecomposable program figures

(2)

Example: Unstructured control flow. A 2 T

T 1

p

q

B

F

F

A

Structured control flow:

TRUE

T T TRUE

1

POP

T p

F

B

3

TRUE

2

q

POP

TOP

F

F FALSE

Date: 21.06.2007

Code Restructuring

Page: 62

The above example of an indecomposable control flow is used to show how we can use the previous defined new function to restructure this control flow getting a structured program flow. Theorem: Any indecomposable program is equivalent to a program whose formula contains at most the graph labels BLOCK, IF_THEN_ESLE, and REPEAT_UNTIL, and additional functions TRUE, FALSE. And POP, and predicate function TOP. For more detail see book: “Software Productivity”, Harlan d. Mills, 1988.

62

Indecomposable program figures

(3)

Example: Structured control flow. A

TRUE

T T TRUE

1

POP

T p

F

B

3

TRUE

2

q

POP

TOP

F

F FALSE

Pseudo-Code:

Date: 21.06.2007

TRUE REPEAT POP IF p THEN {A,TRUE} ELSE {B, IF q THEN TRUE ELSE FALSE ENDIF} ENDIF UNTIL TOP Code Restructuring

Page: 63

The equivalent structured control flow is shown in the above foil.

63

Agenda

1. Introduction 2. Review: Structured Programming 3. Basic Code Restructuring Methods 4. The Spaghetti Bowl Approach 5. Indecomposable program figures

6. Conclusion "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will spend its whole life thinking its stupid." Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 64

64

Conclusion

(1)

Exercise: Describe methods/rules to restructure this code !

w

Date: 21.06.2007

Code Restructuring

Page: 65

You should now be able to restructure the “spaghetti code”. Try it.

65

Conclusion

(2)

Benefits: • What benefit’s do we expect? • We can identify: • deleting ‘dead’ code, • deleting unnecessary branches, • recognizing loop structures, • improving loop bodies.

What we cannot expect:

“A simple design is an outline for a small software component. It has the smallest number of features that meet the requirements of the current phase. As simple as possible, but not simpler.” Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 66

It is our goal to restructure programs (control logic). We can identify the following subgoals for the shown restructuring methods: · deleting ‘dead’ code, · deleting unnecessary branches, · recognizing loop structures, · improving loop bodies. We look at each sub goal and we describe the kind of results we can expect from the ‘optimal restructuring method’. We use these expectations to verify that our method works. Deleting ‘dead’ code: Sometimes an assembler program includes program instructions that are never executed. This code is completely unnecessary and can be deleted. We expect that restructuring has the side-effect of detecting all unnecessary code. Deleting unnecessary branches: We want to optimize the control flow in such a way that no unnecessary branches increase the complexity. We expect that restructuring has the side-effect of deleting all unnecessary branches. Recognizing loop structures: We want to recognize the loop structure and make it directly visible. The unstructured program does not explicitly show us where the loop starts and where it ends. The control flow graph provides a better visualization of the loop. We expect that loops in a restructured program can be recognized as easy as in a control flow graph. One way of achieving this is by translating the loop into a eg. DO_WHILE construction that explicitly shows us the beginning and the end of the loop. Improving loop bodies: When we look at the control flow graph we sometimes see that the loop has multiple exits. This is not the optimal structure for a loop. We want only one exit allowing us to abstract from it more easily. Let us imagine a complex program with several complex loops inside. Suppose that each loop has only one exit. Then we can treat each loop as one closed block and abstract from the control flow inside. In this way we can handle a loop as a single instruction. The resulting control flow becomes less complex because of this abstraction.

66

Conclusion

(3)

PROGRAMMING AS A PROCESS: • A Revolution in Programming?

“Of course! Why didn't I ever think of that?” D.E. Knuth.

• Programming starts with a problem and ends with an efficient solution.. • … what is more difficult: finding a solution or refining it. • Programming is program development, • Development goes in small steps, • Programming goes stepwise, • thus, programming means structuring, • it may also mean: sub-structuring the objects, • introducing “data structures”. Date: 21.06.2007

Code Restructuring

Page: 67

PROGRAMMING AS A PROCESS: “Of course! Why didn't I ever think of that?” D.E. Knuth A Revolution in Programming? •Programming starts with a problem and ends with an efficient solution. 'To have an idea' frequently amounts to finding a solution irrespective of how inefficient it is, and it is hard to say what is more difficult: finding a solution or refining it. •Programming is program development. Development goes in small steps: Programming goes stepwise. Independent of the architecture of the storage-controlled machine, program development is refinement. Thus, programming is done by stepwise refinement. Refinement may mean: sub-structuring the operations. It may also mean: sub-structuring the objects, introducing 'data structures'. Frequently, it is done by joint refinement. Thus, programming means structuring.

67

Conclusion

(4)

Closing remarks: • After this session you should know how to restructure a unstructured flowchart into a structured form by using a manually procedure which includes 6 basic transformation methods and 3 additional rules to deal with more complex programs. • The resulting flowchart /pseudo-code can be used to rebuild the source code into a structured format. • The final result may be a starting point for further work, • like “bug” fixing, • performance optimization, • maintenance tasks, • other reverse engineering tasks. Date: 21.06.2007

Code Restructuring

Page: 68

My main goal was to rebuild unstructured program logic into structured logic using basic structured programming figures. I tried to achieve this goal by applying a language independent method. Using a flowchart of the unstructured code the method is based on formal transformations and rules. Additionally I explained side effects to achieve our goal. In the first part of my presentation I gave a short review about basic control elements of the structure theorem. In the second part I defined 6 basic methods to restructure flowchart parts into structured forms. For more complex programs I explained a general procedure including 3 additional rules which helps to restructure the control logic step by step. After finish the restructuring work you can rebuild the source code into a structure form. This final result may be the start for further work. branch instructions.

68

Conclusion

(5)

… ! ? GOTO…

“Not everything that can be counted counts, and not everything that counts can be counted.” Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 69

… without any comment.

69

Source See:

Web page

http://www.refactoring.com/ http://istpub.berkeley.edu:4201/bcc/Fall2004/refactoring.html Discussion site on code smells: http://c2.com/cgi/wiki?CodeSmell

Books:

• Software Productivity, Harlan D. Mills, 1988 • General Principles of System Design, Gerald M. Weinberg & Daniela Weinberg • Rethinking System Analysis & Design, Gerald M. Weinberg • Program Development by stepwise transformation, F.L. Bauer, Springer Berlin • Refactoring: Improving the Design of Existing Code, by Martin Fowler (et al.),1999, Addison-Wesley

• Additional publications:

• Using Hammock Graphs to Structure Programs, Fubo Zhang and Erik H. D’Hollander, Member, IEEE • An Algorithm for Structuring Flow graphs, Brenda S. Baker • Restructuring Control Flow of IBM/370 Assembler Programs, Michael Ricking • A Non-Deterministic Approach to Restructuring Flow Graphs, Toni A. Bünter, TR CUCS-019-93 Columbia University • Code Cleanup Idioms, Ninad Jog • Aggressive Function Inlining with Global Code Reordering, IBM, H-0247, 2006 • Software: a fine art, Anthony A. Aaby, 2007

Date: 21.06.2007

Code Restructuring

Page: 70

In all sessions I like to motivate you to study additional books and publications about Reverse Engineering/Code Restructuring.

70

Discussion

(1)

Now let’s start discussion… Reverse Engineering Code Restructuring © 2007

“Computers are incredibly fast, accurate, and stupid; humans are incredibly slow, inaccurate and brilliant; together they are powerful beyond imagination.” Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 71

Enjoy the following discussion!

71

Discussion

(2)

Q/A: Not just prepared… -You’ll get a final paper until next session.

Requests: 1) Exercises – ok. I prepare some examples …

Date: 21.06.2007

Code Restructuring

Page: 72

72

Questions / Comments… ??? Questions, comments, further information? Please feel free to e-mail me!

Dipl.Ing. Werner Hoffmann EMAIL: [email protected] or [email protected] Date: 27.10.2007

SE_CodeRestructuring.ppt

Page: 73

The time for this session is over. If you have additional questions or comments or like to get further information please feel free to e mail me at [email protected] or [email protected].

73

The End…

Code Restructuring

I tha n your k you for atten tion !

“The most beautiful thing we can experience is the mysterious.” Albert Einstein.

Date: 21.06.2007

Code Restructuring

Page: 74

I hope this presentation was right for you! Thank you for your attention!

74