1 / 39

2IS95 Seminar Software Engineering and Technology

2IS95 Seminar Software Engineering and Technology. Software Evolution. Software Evolution. In the beginning. . Royce 1970, “Waterfall model”. Maintenance = bug fixes and minor adjustments. What are the main shortcomings of this model, in your opinion?. NB: Still in use anno 2009!.

tovi
Download Presentation

2IS95 Seminar Software Engineering and Technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2IS95 Seminar Software Engineering and Technology Software Evolution

  2. Software Evolution. In the beginning. • Royce 1970, “Waterfall model”. Maintenance = bug fixes and minor adjustments What are the main shortcomings of this model, in your opinion? NB: Still in use anno 2009! 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  3. 1974. Lehman’s laws. • E-type system: • Systems operate in the real world (or address it) • They should be evolved since the real world evolves! • Evolution laws: • E-type systems must be continually adapted else they become progressively less satisfactory. • As an E-type system evolves its complexity increases unless work is done to maintain or reduce it. • The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes. • There are more… 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  4. Macro look: Bennett and Rajlich (2000) • Legacy system = the system that is still valuable despite its degraded quality. • Migration = keep functionality, improve quality! • At what stage would you like to plan migration? architecture decay Loss of architectural integrity Patches too costly? 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  5. Micro look: Yau et al. (1978) • “Evolution” stage of the Bennett-Rajlich model • Refactoring = keep functionality, improve structure! • What is the difference between refactoring and restructuring as defined in the Yau model? 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  6. Going extreme • Software evolution (iterative, incremental) + short time periods + high degree of collaboration + explicit accommodation of changing needs agile software development Extreme programming is an example of agile. 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  7. Software Evolution: Definition • Look at the discussion so far. • How would you define “software evolution”? • Software evolution is the set of activities, both technical and managerial, that ensures that software continues to meet organisational and business objectives in a cost effective way. 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  8. Where do we start? • Versioning repositories (CVS, SVN, …) • Software but what about models, requirements, etc? • Bug tracking systems • Change logs • Documentation • Mailing list archives • Huge amount of information • Tooling is essential! 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  9. Research Themes in Software Evolution: Science • What is the nature of software evolution? • Lehman’s law: • Evolution = a multi-loop, multi-level and multi-agent feedback system • Understanding the evolution requires understanding • Human psychology • Social interaction • Organizational aspects • Economics and management • Legislation 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  10. Social interaction? Linchpin developers create a social network! Madey, Freeh and Tynan 2002 / SET / W&I

  11. Research Themes in Software Evolution: Engineering • Technology, means and tools to direct, implement and control software evolution. • Some relevant questions: • What artefacts evolve? • Requirements, design, code, tests, … • What can we learn from evolution so far? • Quality change, software analysis • How evolvable are our artefacts? • How can we make them more evolvable? • Migration, reverse engineering and reengineering • How is the evaluation implemented? • Refactoring, architecture transformations • … 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  12. What does evolve? Requirements evolution Design (architecture) evolution. Data, code, documents, technology evolution Evolution of different artefacts should be consistent. This is called the co-evolutionproblem. Tests and proofs evolution 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  13. Consistency and co-evolution: Points of discussion • What should co-evolve? • Code and database table definitions • Code and design documentation • Code and tests • Different code elements (packages, modules, files…) • … • What constitutes inconsistency? • How to detect inconsistencies? • How to ensure absence of inconsistencies? 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  14. Co-evolution is time-dependent! D’Ambros, Gall, Lanza, and Pinzger. “Analysing Software Repositories to Understand Software Evolution” Assumption: files committed together are co-evolving. / SET / W&I

  15. Source/Test Files Co-evolution Andy Zaidman, Bart Van Rompaey, Serge Demeyer and Arie van Deursen. “Mining Software Repositories to Study Co-Evolution of Production & Test Code” Added Source Modified Source Added Test Modified Test / SET / W&I

  16. What can we learn from the evolution so far? • What modules are stable? • How to predict bugs from history? • How to detect the architecture decay? • What can we say about the project organisation? • Is there a major developer? (risk if she leaves) • Is there correlation between #bugs, productivity and certain developers/teams? 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  17. Is there a major developer? Fractal Figures! Area D’Ambros, M., Lanza, M., Gall, H.: Fractal figures: Visualizing development effort for CVS entities. Fractal value (between 0 and 1) / Mathematics and Computer Science

  18. Work assignment in an industrial project File Module Package Number of Modification Requests (MRs) per file 1 30 Some modules have many red(dish) files / SET / W&I Courtesy of AlexandruTelea

  19. The “reddish” modules: Team assignment Team A Team B 7 of the 11 red(ish) modules are assigned to the red team Team C / SET / W&I Courtesy of AlexandruTelea

  20. Problems in the development? Time MR id range (4000 – 5000; grouped on hundreds) Ex: Number of file commits referring to MRs with IDs in the range [4700 - 4800) In mid 2008, activity related to MRs addressed in 2006-2008 still takes place / SET / W&I Courtesy of AlexandruTelea

  21. How do systems evolve? Evolution patterns! Nakakojiet al. 2002 / SET / W&I

  22. How evolvable are our artefacts? Analysis! • Resilience to change caused by • Bad readability • Bad structure • Code clones (see next slide) • High complexity • Insufficient abstractness (OO) • … • How to detect these situations? • Metrics (discussed earlier) • Dependencies 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  23. Special technique: Code clones elimination • Presence of code clones impedes evolution. • Why? • Points of discussion: • When A and B can be considered clones? • Identical • Up to variable/constant/number renaming • Allowing gaps/repetitions • How to detect clones? • When is it beneficial to remove the clones? • Why do people clone code? 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  24. Code duplication / SET / W&I • Why? [Kim et al. 2004] • Limitations of the programming language • Inability to predict future variability • Reuse of the existing code • Struggle against bad(?) modularization • Cross-cutting concerns and aspects • How? [Kapser, Godfrey 2006] • Forking • Templating • Customization

  25. How to make artifacts more evolvable? Evolution strategies • Refactor • Reengineer • E.g., using models (see next slides) • Re-implement How can one decide which strategy to follow? • Aversano, Esposito, Mallardo, Tortorella • Ransom, Somerville, Warren • … / SET / W&I

  26. Reengineering Analysis 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  27. How to make the artefacts more evolvable? Analysis Reverse engineering 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  28. How to make the artefacts more evolvable? Analysis Reverse engineering Restructuring, model evolution 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  29. How to make the artefacts more evolvable? Analysis Reverse engineering Restructuring, model evolution Forward engineering 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  30. How to make the artefacts more evolvable? Analysis Reverse engineering Restructuring, model evolution Forward engineering 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  31. How to make the artefacts more evolvable? Analysis Reverse engineering Restructuring, model evolution Forward engineering 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  32. Reverse Engineering: From Code to Models No silver bullets! / SET / W&I • Depends on • What kind of model would we like? • structure / behaviour • precise / approximate • What kind of code do we have? • complete / incomplete • compilable / executable / neither • programming languages: heterogeneous / homogeneous • “special cases”: • process models • business rules • We need tools!

  33. Example: Reverse Engineering Class Diagram Bellflower (C++) CPP2XMI • Inferred class diagram contains more details than the original one: • Additional fields and methods in certain classes • Additional relationship: aggregation / LaQuSo / Mathematics & Computer Science

  34. Example: Reverse Engineering State Machines Flow System Controller (C), module SPUR CPP2XMI / SET / W&I

  35. Example: Reverse Engineering Sequence Chart Artificial (Java, EJB 3.0) ctx:Invocation Context :Login :Profiler :Auditor :ProductFacade em: EntityManager :Product productInfo(id) access(ctx) proceed() measureDuration(ctx) proceed() doAudit(ctx) proceed() logMethods(ctx) proceed() productInfo(id) find() getDescription() / SET / W&I

  36. How to make the artefacts more evolvable? Analysis Reverse engineering Restructuring, model evolution See talk about MDE! Forward engineering 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  37. Summarizing… Software Evolution • A “hot” topic • Challenges: • Science and engineering • Different evolving artifacts • Different evolution patterns and strategies • Co-evolution • Analysis and visualization / SET / W&I

  38. Software Evolution @ TU/e • What does evolve? • Repositories for models – Zvezdan Protic, MvdB • What can we learn from evolution so far? • Statistical approaches – Serguei Roubtsov, AS, MvdB • How evolvable are our systems? • SQuAVisiT – Serguei Roubtsov, Martin vd Vlist, Peter Schachtschabel • How to make the artefacts more evolvable? • Reverse engineering – Dennie van Zeeland, MvdB, AS • How is the evolution implemented? • Model transformations – Marcel van Amstel, Luc Engelen, MvdB • Migration coordination – Erik de Vink, Suzana Andova and also YOU! 2IS99 – Software evolution – Research topics in software evolution / SET / W&I

  39. Questions? / SET / W&I

More Related