1. Tempus Software Maintenance and Evolution JMSE-SM&E Unit 2: Selected Topics in Analysis of Software Artifacts Prof. Mohammad A. Mikki Gaza, Palestine

2. Joint Master in Software Engineering “Software Maintenance and Evolution” Course Unit 2 Selected Topics in Analysis of Software Artifacts Software Maintenance and Evolution 2

3. Joint Master in Software Engineering Introduction  This unit describes briefly some selected topics in analysis of software artifacts  These topics are related to software evolution and maintenance Course Title 3

4. Joint Master in Software Engineering Course Title Objectives  Understand program slicing  Understand change impact analysis  Understand refactoring  Understand code clone detection  Understand round trip engineering (from design to code and back)  Understand developing for multiple platforms 4

5. Joint Master in Software Engineering Course Title List of Topics  Program Slicing  Change Impact Analysis  Refactoring  Code Clone Detection  Round Trip Engineering (from design to code and back)  Developing Software for Multiple Platforms 5

6. Joint Master in Software Engineering Course Title Program Slicing  The size and complexity of a software today gets harder to understand, maintain and test.  We need to answer questions like −If a program statement is changed, what pieces of the program are going to be affected? −Where are the values that flow into a program statement coming from? −How can we limit the functionality to only what we need?  To address the above questions, we need program slicing 6

7. Joint Master in Software Engineering Course Title Program Slicing Definition  Program slicing is a decomposition technique that extracts statements relevant to a particular computation from a program. It is the task of computing program slices automatically.  A program slice consists of the parts of a program that could affect the values computed at some point of interest, referred to as a slicing criterion 7

8. Joint Master in Software Engineering Course Title Goal of Program Slicing  Program debugging: by reducing the complexity of the program, debugging lines of code of the program becomes easy. - Program slicing visualizes control and data dependencies through PDG (Program Dependency Graph). -Program slicing highlights statements that influence the slice.  Write a robust program before testing its code due to effectiveness of program debugging. 8

9. Joint Master in Software Engineering  Testing: When running only needed tests, we reduce cost of regression testing after modifications. - Save the regression testing time by limiting the tests to only test that exercise the changed code.  Program understanding: where we could use slices to trace variables change in programs.  Reverse engineering: We can understand the program design by abstracting out of the source code.  Software quality assurance: validate interactions between safety-critical program components. Goal of Program Slicing (Cont.)

10. Joint Master in Software Engineering  Software maintenance: changing source code without unwanted side effects  through focusing only on statement that effect specific variables.  slicing is usually applied to programs after they are written  Program slicing is useful in maintenance rather than design Goal of Program Slicing (Cont.)

11. Joint Master in Software Engineering Types of program slicing  Static slicing  Dynamic slicing

12. Joint Master in Software Engineering Course Title  Often a slicing criterion consists of a pair: (line-number, var-list) where line-number specifies a location (statement) in the program and var-list specifies a subset of program variables  All statements affecting or affected by the variables mentioned in the slicing criterion become part of the slice.  Static slices are computed by finding consecutive sets of indirectly relevant statements, according to data and control dependencies. 12 Static Slicing Criterion

13. Joint Master in Software Engineering Course Title Program slice S must satisfy the following conditions:  Slice S(line-number, var-list) must be derived from program P by deleting statements from program P.  A static program slice S consists of all statements in program P that may affect the values of variables in var-list at some point p.  Slice S contains all statements that may affect a variable for every possible execution.  A static slice includes all the statements that affect variables in var-list for a set of all possible inputs at the point of interest (i.e., at the statement x). 13 Properties of a Static Slice

14. Joint Master in Software Engineering Course Title  No assumptions are made about input values  Slice S(line-number, var-list) must be syntactically correct.  For all executions of P, the values of variables in var-list in the execution of S(line-number, variable) just before the location line-number must be the same values of variables in var-list in the execution of the program P just before location line- number.  Behavior of slice as observed through the slice criterion must correspond to original program behavior. 14 Properties of a Static Slice (Cont.)

15. Joint Master in Software Engineering Course Title Static Program Slicing Example 1 [1] 15 Original program: 1. begin 2. read(x,y) 3. total := 0.0 4. sum := 0.0 5. if x <= 1 6. then sum := y 7. else begin 8.read(z) 9.total := x*y 10. end 11. write(total, sum) 12. end. Slice criterion Slice for “z” at last statement This new program is a valid slicing of the original program with respect to the criterion begin read(x,y) if x <= 1 then else read(z) end. Slice criterion Slice for “x” at statement at location 9 This new program is a valid slicing of the original program with respect to the criterion begin read(x,y) end. Slice criterion Slice for “total” at last statement This new program is a valid slicing of the original program with respect to the criterion begin read(x,y) total := 0 if x <= 1 then else total := x*y end.

16. Joint Master in Software Engineering Course Title Original program: 1. Read(n) 2. I = 1 3. Sum = 0 4. Product = 1 5. While I<=n do 6. sum = sum + I 7. product = product + I 8. I = I + 1 9. Endwhile 10. Write(sum) 11. Write(product) 16 Slice criterion Slice for “product” at last statement This new program is a valid slicing of the original program with respect to the criterion Read(n) I = 1 Product = 1 While I<=n do product = product + I I = I + 1 Endwhile Write(product) Static Program Slicing Example 2 [2]

17. Joint Master in Software Engineering Course Title Original program: 1.int i; 2.int sum = 0; 3.int product = 1; 4.for(i = 0; i < N; ++i) { 5.sum = sum + i; 6.product = product *i; } 7.write(sum); 8.write(product); 17 Slice criterion Slice for “sum” at last statement This new program is a valid slicing of the original program with respect to the criterion int i; int sum = 0; for(i = 0; i < N; ++i) { sum = sum + i; } write(sum); Static Program Slicing Example 3 [2]

18. Course Title18 Original program: 1. read (n) 2. i := 1 3. sum := 0 4. product := 1 5. while i <= n do 6. sum := sum + i 7. product := product * i 8. i := i + 1 9. write (sum) 10. write (product) Criterion Slice for “product” at statement 9 This new program is a valid slicing of the original program with respect to the criterion read (n) i := 1 product := 1 while i <= n do product := product * i i := i + 1 write (product) Static Program Slicing Example 4 [2]

19. Joint Master in Software Engineering Course Title  Break larger code into smaller pieces 19 How do we do program slicing?

20. Joint Master in Software Engineering Course Title  The following are some program decomposition techniques - Information hiding - data abstraction  These techniques are applied during program design 20 Program Decomposition Techniques

21. Joint Master in Software Engineering Course Title  Control Flow Graph (CFG) - Data Flow equations are solved  Program Dependence Graph (PDG) - Slice is computed as graph reachability problem 21 Intermediate representation of programs for slicing

22. Joint Master in Software Engineering Course Title 22 Example using PDG [3] Original program: 1 main( ) 2 { 3 int i, sum; 4 sum = 0; 5 i = 1; 6 while(i <= 10) 7 { 8sum = sum + 1; 9++ i; 10 } 11Cout<< sum; 12Cout<< i; 13} 1 3 456 11 12 89 Slice Point Control Dep. Edge Data Dep. Edge PDG representation of program

23. Static slice using the PDG in previous slide Slice criterion (12,i) Slice for “i” at last statement This new program is a valid slicing of the original program with respect to the criterion main( ) i = 1; while(i <= 10) ++ i; Cout<< i; Example using PDG (Cont.) [3]

24. Joint Master in Software Engineering Course Title Dynamic Slicing Definition  Dynamic slice is a set of program statements that affect the value of a variable for one specific input.  Dynamic slice preserves the meaning of the variables in the slicing criterion for a single input to the program.  To compute the slices, dynamic data dependence information is traversed.  This information is constructed using an execution trace of the program. 24

25. Joint Master in Software Engineering Dynamic Slicing Criterion Where I is program input L is a set of some statement instances during execution of program P with input I V is a set of variables referenced by L

26. Joint Master in Software Engineering Advantages of Dynamic Slicing Over Static Slicing  Deterministic instead of probabilistic  Allow an easier localization of the bugs  Run-time handling of arrays and pointer variables

27. Joint Master in Software Engineering Course Title  Find out statements in P which affect the values of V at L during execution,  This is achieved using dynamic control or data dependencies.  This is needed for program debugging  For example, if during program execution, the values of V at L were "unexpected", the corresponding slice can be inspected to explain the reason for the unexpected values. 27 Purpose of Dynamic Slicing

28. Joint Master in Software Engineering Course Title Change Impact Analysis  Impact analysis is also known as change impact analysis, impact change analysis and solution effect analysis.  The concepts behind impact analysis are not limited to computer software.  These concepts are based on that every action has a consequence, negative or positive. 28

29. Joint Master in Software Engineering Course Title Change Impact Analysis Definition  Change impact analysis is:  identifying the full consequences of change  estimating what needs to be modified to accomplish a change  evaluation of the many risks associated with the change, including estimate of the effects on resources, effort, and schedule 29

30. Joint Master in Software Engineering Course Title Software Change Impact Analysis  In regards to software, change impact analysis is:  the assessment of a change to the source code of a program module on the other modules of the program.  prediction and determination of the parts of a software system that can be affected by changes to the system  Estimation of what will be affected in software and related documentation if a proposed software change is made  a systematic approach to understanding impacts of software changes 30

31. Joint Master in Software Engineering Course Title Change Impact Analysis Motivation  Every software change has a consequence, negative or positive, e.g., what will be the effect if a program variable is redefined  Helps programmers think of the full impacts of a proposed change.  Change impact analysis is an essential part of the evaluation process for major decisions.  it assists programmers to spot program problems before they arise,  Developing contingency plans to handle program problems before they arise.  31

32. Joint Master in Software Engineering  Identifying the unexpected negative effects of software change on software.  Identifying as many of the negative impacts or consequences of the change as possible.  Providing a structured approach for looking at a proposed change  Evaluating whether a programmer wants to make the proposed software change Course Title 32 Change Impact Analysis Motivation (Cont.)

33. Change impact analysis takes “change set” as an input and produces “impact set” as an output where:  change Set is the parts of the software system that are to be changed, and  Impact Set is the parts of the software system that are affected by the changes Change Impact Analysis Concepts Change set Impact setChange Impact analysis

34. Change Impact Analysis Procedure Identify resources to be modified if change is taken Understand change impact Identify tasks to be implemented if change is taken

35. Joint Master in Software Engineering Change Impact Analysis Types  Static change impact analysis  Dynamic change impact analysis

36. Joint Master in Software Engineering Static Impact Analysis  Based on analysis of source code  Based on assumptions of all possible software runtime behaviors  Results can include most of the software system in the impact set Changes requested Inspect source code Document possible system behaviors Impact Set Analyze program entity dependency relationships

37. Joint Master in Software Engineering Dynamic Impact Analysis  Based on software runtime data and dynamic interactive behavior of the software system  Depends on a set of executions of the system  Tends to produce more precise results than static approaches Changes requested Execute software system Collect system runtime data Impact Set Analyze runtime relationships of program entities

38. Joint Master in Software Engineering Course Title Refactoring  Refactoring is the process of changing a software system in such a way to improve its internal structure while not altering its external behavior.  It is restructuring, reorganizing, and rearranging program code in a series of small transformations in order to make the code easier to maintain and modify  Refactoring is changing the factoring of the program code 38

39. Joint Master in Software Engineering Course Title Refactoring Example  Technically, refactoring comes from mathematics where factoring is the decomposition of an object into an expression of smaller objects, or factors, which multiplied together give the original  For example, the number 15 factors into primes as 3X5; and the polynomial x 2 - 4 factors as (x-2)(x+ 2) 39

40. Joint Master in Software Engineering Course Title Refactoring Motivation  Refactoring is usually motivated by presence of code smell.  Code size is often reduced  Confusing code is restructured into simpler code  Understand existing code  It is difficult to get the design right the first time  Original design is often inadequate 40

41. Joint Master in Software Engineering Course Title Refactoring Motivation (Cont.)  Maintainability: Smaller methods are less complex, more readable, and hence easier to maintain.  Debugging: the source code is easy to read  Extensibility. It is easier to extend the capabilities of the application if: -it uses recognizable design patterns -It provides some flexibility -create a more expressive internal architecture or object model 41

42. Joint Master in Software Engineering Course Title Code Smell  A code smell is a code that can make the design harder to change  Code smell can be addressed by refactoring the source code, or transforming it into a new form that behaves the same as before but that no longer "smells". 42

43. Joint Master in Software Engineering Course Title Examples of Code Smell  Duplicate code  Long methods  Big classes  Big switch statements  Long navigations  Lots of checking for null objects  Data classes (classes that have mainly fields/properties and little or no methods)  Un-encapsulated fields (public member variables) 43

44. Joint Master in Software Engineering  Refactoring implies equivalence. The original and re-factored code must be functionally identical.  Code must still work  The code preserves the semantics of the original software  Small steps only so the semantics are preserved  Refactoring does not make a major re-write of the code  Unit tests to prove the code still works Refactoring Properties

45. Joint Master in Software Engineering Course Title  Refactoring makes code clearer, cleaner, simpler, and elegant.  Refactoring, doesn't change the functionality of the software that is re-factored  Refactoring either exposes simpler components or reduces them to the more efficient complex expression  Each transformation or refactoring does a sequence of transformations that can produce a significant restructuring.  Since each refactoring is small, it’s less likely to go wrong. 45 Refactoring Properties (Cont.)

46. Joint Master in Software Engineering Course Title  Refactoring improves nonfunctional attributes of the software.  Code becomes more readable and less complex  Refactoring improves software's design  By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to functions. 46 Refactoring Properties (Cont.)

47. Joint Master in Software Engineering Course Title  Make a small change i.e., a standard basic micro-refactoring step (a single refactoring) -Each micro-re-factorings step is a tiny change in a computer program's source code that preserves the external behavior of the software, preserves functional requirements.  Run tests to ensure everything still works  If everything works, move on to the next refactoring  If not, fix the problem, or undo the change, so you still have a working system 47 Refactoring Process

48. Joint Master in Software Engineering  Refactoring to design patterns  Renaming (methods, variables): Rename method or field into a new one that better reveals its purpose  Extracting code into a method  Changing method signatures  Performance optimization  Naming (extracting) "magic" constants  Encapsulate Field: force code to access the field through methods  Generalize Type: create more general types to allow for more code sharing Course Title 48 Example Types of Refactoring

49. Joint Master in Software Engineering  Extracting common functionality (including duplicate code) into a module/method/etc.  Splitting one method into several to improve cohesion and readability (by reducing its size)  Putting statements that semantically belong together near each other  Exchanging risky language idioms with safer alternatives  Clarifying a statement that has evolved over time or is unclear  Move Methods: move to a more appropriate class  Move field: move to a more appropriate class  Replace conditionals with polymorphism Course Title 49 Example Types of Refactoring (Cont.)

50. Joint Master in Software Engineering Course Title  Extract Class: move part of the code from an existing class into a new class.  Extract Method: turn part of a larger method into a new method. 50 Example Types of Refactoring (Cont.)

51. Joint Master in Software Engineering Refactoring Example: Switch Statements [4]  A switch statements are very rare in properly designed object- oriented code  A switch statement is easily detected as bad code smell  not all uses of switch are bad code smell A switch statement should not be used to distinguish between various kinds of object  There are several well-defined refactorings for this case, The simplest is the creation of subclasses

52. Joint Master in Software Engineering Original code: class Animal { final int MAMMAL = 0, BIRD = 1, REPTILE = 2; int myKind; // set in constructor... String getSkin() { switch (myKind) { case MAMMAL: return "hair"; case BIRD: return "feathers"; case REPTILE: return "scales"; default: return “skin"; } } } Refactoring Example: Switch Statements [4] //Refactored code, Improved code //Program behavior does not change but //the resulting code is easier to read and //understand class Animal { String getSkin() { return “skin"; } } class Mammal extends Animal { String getSkin() { return "hair"; } } class Bird extends Animal { String getSkin() { return "feathers"; } } class Reptile extends Animal { String getSkin() { return "scales"; } }

53. Joint Master in Software Engineering //Original code... if (i != min) { int temp = num[i]; num[i] = num[min]; num[min] = temp; }... //Refactored code, improved code //Program behavior does not change but //the resulting code is easier to read and //understand.... if (i != min) { swap(ref num[i], ref num[min]); }... void swap(ref int a, ref int b) { int temp = a; a = b; b = temp; } Refactoring Example: Extract method [5]

54. Joint Master in Software Engineering Motivation: A method is, or will be, using or used by more features of another class than the class on which it is defined. Technique: Create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether. Coming up: Danger! Refactoring Example: Move a method [5]

55. Joint Master in Software Engineering Course Title Code Clone Detection  Intentional copy/paste is a common reuse technique in software development  Reusing code fragments by copying and pasting with or without minor adaptation is a common activity in software development.  As a result, software systems often contain sections of code that are very similar.  These sections are called code clones. 55

56. Joint Master in Software Engineering Course Title Code Clone Detection Definition  Code clones are separate fragments of code that are very similar. They are a common phenomenon in an application that has been under development for some time.  A code clone is a copy of source code in a program. 56

57. Joint Master in Software Engineering Course Title Code Clone Detection Example 57 //original code for(int i=0; i<5; i++) for(j=0; j<=i; j++) cout << i+j; //Code clone for(int k=0; k<6; k++) for(m=0; m<=k; m++) cout << k+m;

58. Joint Master in Software Engineering Course Title  Clones make it hard to change your application because you have to find and update more than one fragment.  Errors in the original must be fixed in every clone  further development may become prohibitively expensive  Code clones have negative effects on software maintenance -Copied Defects -Changes take double, triple, quadruple,... Work -Dead code -Add to the cognitive load of future maintainers  Copying is an additional source of bugs -Errors in the systematic renaming produce unintended aliasing 58 Why Code Clones Are Harmful

59. Joint Master in Software Engineering Course Title  Code Clones have the effect of increasing source code size and duplication of errors.  clones are harmful in software maintenance and evolution -if a bug is detected in a code fragment, all fragments similar to it should be checked for the same bug -Code clones can increase work needed to be done to enhance code 59 Why Code Clones Are harmful (Cont.)

60. Joint Master in Software Engineering Course Title Code Clone Detection Motivation  Studying code evolution  Performing plagiarism detection  Enabling refactoring such as procedure extraction  Performing defect tracking and repair 60

61. Joint Master in Software Engineering Course Title Code clone analysis is needed when there is a need to:  update existing code.  Debug a program  respond to changes in requirements 61 When to Do Code Clone Analysis

62. Joint Master in Software Engineering Course Title  Finding the location in the code that you need to change  Before making the change, search for clones of that code segment. If clones are discovered: -Consider whether you need to make the same change to each clone. 62 Code Clone Analysis Process

63. Joint Master in Software Engineering Code Clones Detection Techniques  String Matching: Find cones through string matching and comparison  Token Parsing: Transfer code into tokens, then apply token parsing  Graph Matching: Convert code into Program Dependence Graph (PDG), then apply pattern matching  Code refactoring: -Extract method which extracts portions of duplicated code in a separate method, is an example of a typical refactoring to remove duplicated code. -Transform conditionals into Polymorphism where duplicated conditional logic is refactored over the class hierarchy using polymorphism -Other refactoring techniques are used

64. Joint Master in Software Engineering Course Title  Round trip engineering is used to synchronize source code, models and other information as development progress.  It is a functionality of software development tools that: -provides generation of models from source code (reverse engineering) and generation of source code from models -synchronizes two or more related software artifacts, such as, source code, models, configuration files, and other documents.  It combines code generation and reverse engineering.  It allows the model to be directly modified at code level.  The code is then fully reversed, in order to update the model.  64 Round Trip Engineering

65. Joint Master in Software Engineering Course Title  Round trip engineering supports an iterative development process.  After developers synchronize the model with revised code, they are free to choose the best way to work: -make further modifications to the code or -make changes to your model.  Developers can synchronize in either direction at any time and they can repeat the cycle as many times as necessary.  65 Round Trip Engineering Properties

66. Joint Master in Software Engineering Course Title  One characteristic of round-trip engineering is its automatic update of the artifacts in response to automatically detected inconsistencies.  The automatic update can be either instantaneous or on- demand. -In instantaneous update all related artifacts are immediately updated after each change is made to one of them. -In on-demand update, the artifacts may concurrently evolve -At some point inconsistencies between these artifacts may occur -At this point, software developers may propagate some of these evolutions to preserve consistency  66 Round Trip Engineering Properties (Cont.)

67. Joint Master in Software Engineering Course Title  Build the initial model from the code  Update the model from the code  Update the code from the mode 67 Round Trip Engineering Usage

68. Joint Master in Software Engineering Course Title  Same information is present in multiple artifacts. Hence, an inconsistency may occur if not all artifacts are consistently updated to reflect a given change.  Some information is added to or modified in one artifact and, as a result, it became missing in or inconsistent with the other artifacts. 68 Round Trip Engineering Motivation

69. Joint Master in Software Engineering Course Title Round-trip engineering is closely related to:  Forward engineering: creating software from specifications  Reverse engineering: creating specifications from existing software  Reengineering: understanding existing software and modifying it 69 Round Trip Engineering Relation With Other Disciplines

70. Forward Engineering [6]  Forward engineering means the generation of code from UML diagrams  Many of the tools can only do the static models:  They can generate class diagrams from code, but can't generate intDemoeraction diagrams. -For forward engineering, they can generate the basic (e.g., Java) class definition from a class diagram, but not the method bodies from interaction diagrams.  Demo Generate

71. Reverse Engineering [6]  Reverse engineering means generation of UML diagrams from code  Demo Re-Engineer

72.  closes the loop -the tool supports generation in either direction and can synchronize between UML diagrams and code, ideally automatically and immediately as either is changed.  Demo Round Trip Engineering [6]

73. Joint Master in Software Engineering Course Title  Round-trip engineering does not only support forward and reverse engineering  round-trip engineering is able to synchronize existing artifacts that evolve concurrently by incrementally updating each artifact to reflect changes made to the other artifacts  Forward engineering can be seen as a special instance of round- trip engineering in which only the specification is present 73 Round Trip Engineering Difference From Forward and Reverse Engineering

74. Joint Master in Software Engineering Course Title  Reverse engineering can be seen as a special instance of round- trip engineering in which only the software is present.  Many reengineering activities can also be understood as round- trip engineering when the software is updated to reflect changes made to the previously reverse engineered specification.  Automatic update in round-trip engineering differentiates it from forward and reverse engineering which can be both manual and automatic 74 Round Trip Engineering Difference From Forward and Reverse Engineering (Cont.)

75. Joint Master in Software Engineering Course Title  A common form of round-trip engineering is synchronization between UML (Unified Modeling Language) models and the corresponding source code.  A form of round-trip engineering is implemented in the context of framework application programming interfaces (APIs), whereby a model describing the usage of a framework API by an application is synchronized with that application's code. -In this setting, the API prescribes all correct ways the framework can be used in applications, which allows precise and complete detection of API usages in the code as well as creation of useful code implementing correct API usages. 75 Examples of round-trip engineering [7]

76. 76  In computing, cross-platform, or multi-platform refers to computer software that is implemented and inter-operate on multiple computer platforms.  A cross-platform software must be able to function on more than one computer architecture or operating system.  Cross-platform programs may run on as many as all existing platforms, or on as few as two platforms. Developing Software for Multiple Platforms

77. 77 A platform refers to:  Processor and/or other hardware on which a given operating system or application runs  Operating system on a computer  A combination of hardware platform and operating system running on it What is a Platform [8]

78. 78 A hardware platform can refer to:  a computer’s architecture  processor architecture. Example include:  x86 architecture (e.g. IA-32 and x86)  An ARM architecture (e.g. smartphones)  tablet computers Hardware Platforms [8]

79. 79 Examples of software platforms include:  operating system  programming environment  a combination of both. Example of common platforms  Microsoft Windows running on the x86 architecture.  Other well-known include Linux/Unix running on desktop computer  platforms and Mac OS X running on desktop computer  Android for smartphones and tablet computers  AmigaOS 4 (PowerPC),  AROS (x86, PowerPC, m68k) Software Platforms [8]

80. 80  Developing such program can be a time-consuming task because different operating systems have different application programming interfaces (API).  Just because a particular operating system may run on different computer architectures, that does not mean that the software written for that operating system will automatically work on all architectures that the operating system supports.  This also means that just because a program is written in a popular programming language such as C or C++, it does not mean it will run on all operating systems that support that programming language—or even on the same operating system on a different architecture. Cross-Platform Software is Difficult to Build [8]

81. 81  Cross-platform software development is a complex and challenging activity.  Frequently, developers have to create portions of code that use platform-specific data  types and functions. Cross-Platform Software is Difficult to Build (Cont.) [8]

82. 82 Developing Software for Multiple Platforms Examples [8] A cross-platform software may run on  Microsoft Windows on the x86 architecture  Linux on the x86 architecture  Mac OS X on either the PowerPC or x86 based Apple Macintosh systems.

83. 83 Developing Software for Multiple Platforms Motivation Developing software for multiple different platforms is a necessity:  Allowing the end user to use their favoriteplatform,  Complying with the requirements oftheir employersIT environment

84. Joint Master in Software Engineering References [1] MARK WEISER, Program Slicing, 352 IEEE TRANSACTIONS On SOFTWARE ENGINEERING, VOL. SE-10, NO. 4, JULY 1984 [2] Frank Tip, Survey of Program Slicing Techniques, Journal of Programming Languages, Volume 3, Issue 3, pages 121–189, September 1995. [3] Purvi Patel, Program Slicing, Electrical Engineering and Computer Science Department, people.eecs.ku.edu/~saiedian/.../purvi-pgm-slicing.ppt [4] Omar Meqdadi, Chapter 7: Bad Code Smells, SE 3860, Lecture 7, Department of Computer Science and Software Engineering University of Wisconsin-Platteville. Course Title 84

85. Joint Master in Software Engineering References (Cont.) [5] http://sce2.umkc.edu/BIT/burrise/pl/evolution/Refactoring.ppt [6] Chapter 9 From Design to Implementation, http://perceval.gannon.edu/xu001/teaching/shared/applyUMLPa ttern/Chap%209%20- %20From%20Design%20to%20Implementation.ppt [7] Round-trip engineering, Wikipedia, the free encyclopedia, https://en.wikipedia.org/wiki/Round-trip_engineering [8] Cross-platform, Wikipedia, the free encyclopedia, https://en.wikipedia.org/wiki/Cross-platform Course Title 85

86. Tempus Thank you for your attention.