1 / 36

The Story of Moose — an Agile Reengineering Environment

The Story of Moose — an Agile Reengineering Environment. Oscar Nierstrasz www.iam.unibe.ch/~scg/. Is Dilbert really, really smart , or just really, really dumb ? . Premise of this presentation …. Like death and taxes, Software Evolution is inevitable

medwin
Télécharger la présentation

The Story of Moose — an Agile Reengineering Environment

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. The Story of Moose— an Agile Reengineering Environment Oscar Nierstrasz www.iam.unibe.ch/~scg/

  2. Is Dilbert really, really smart, or just really, really dumb?

  3. The Story of Moose — ESEC/FSE 2005 Premise of this presentation … • Like death and taxes, Software Evolution is inevitable • Unfortunately, Software Evolution is still poorly understood and supported • We need techniques and tools to facilitate graceful software evolution

  4. The Story of Moose — ESEC/FSE 2005 Roadmap • The Challenge of Software Evolution • The Reengineering Lifecycle • Reengineering with Moose • The Future of Software Evolution

  5. The Story of Moose — ESEC/FSE 2005 Roadmap • The Challenge of Software Evolution • The Myth of “Software Maintenance” • The Dilemma of Legacy Software • Coping with the Cost of Change • The Reengineering Lifecycle • Reengineering with Moose • The Future of Software Evolution

  6. The Story of Moose — ESEC/FSE 2005 The Myth of “Software Maintenance” • 60% of “maintenance” is new functionality • 50-75% of development effort is “maintenance”, i.e., continuous development • Modern methods lead to longer-lived systems, hence more maintenance 18% Adaptive (new platforms or OS) 4% Other There is no “software maintenance”, just continuous software evolution. 18% Corrective (fixing reported errors) 60% Perfective (new functionality)

  7. The Story of Moose — ESEC/FSE 2005 Lehman’s Laws Continuing change • A program that is used in a real-world environment must change, or become progressively less useful in that environment. Increasing complexity • As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure. — Lehman and Belady, 1985

  8. The Story of Moose — ESEC/FSE 2005 The Dilemma of Legacy Software A legacy system is a piece of software that: • you have inherited, and • is valuable to you. Symptoms • Loss of knowledge • Architecture & design drift • Hard to make changes • … You can’t afford to throw it out, but it is too expensive to change

  9. The Story of Moose — ESEC/FSE 2005 Trends Hardware innovations increasingly foster new and unexpected software applications The rate of change (new features) for new application domains is increasing How can we deal with the spiraling need to cope with change?

  10. x 200 cost time cost The Story of Moose — ESEC/FSE 2005 The cost of change We need to reduce the cost of change over time … — cf., XP Explained time

  11. The Story of Moose — ESEC/FSE 2005 Roadmap • The Challenge of Software Evolution • The Reengineering Lifecycle • FAMOOS Case Studies • Reverse and Reengineering Patterns • Tool support • Reengineering with Moose • The Future of Software Evolution

  12. The Story of Moose — ESEC/FSE 2005 FAMOOS Case Studies Different reengineering goals … but common themes and problems !

  13. The Story of Moose — ESEC/FSE 2005 The Reengineering Life-Cycle Requirements Designs Need appropriate tools and methods Code

  14. Tests: Your Life Insurance Migration Strategies Detailed Model Capture Detecting Duplicated Code Initial Understanding Redistribute Responsibilities First Contact Transform Conditionals to Polymorphism Setting Direction The Story of Moose — ESEC/FSE 2005 A Map of Reengineering Patterns Visualize Code as Dotplots Study the Exceptional Entities

  15. The Story of Moose — ESEC/FSE 2005 Pattern: Study the Exceptional Entities Problem • How can you quickly gain insight into complex software? Solution • Measure software entities and study the anomalous ones Steps • Use simple metrics • Visualize metrics to get an overview • Browse the code to get insight into the anomalies

  16. The Story of Moose — ESEC/FSE 2005 System Complexity View System Complexity View Nodes = Classes Edges = Inheritance Relationships Width = Number of Attributes Height = Number of Methods Color = Number of Lines of Code

  17. The Story of Moose — ESEC/FSE 2005 Pattern: Visualize Code as Dotplots Problem • How can you effectively identify significant duplication in a complex software system? Solution • Visualize the code as a dotplot, where dots represent duplication. Steps • Normalize the source files • Compare files line-by-line • Visualize and interpret the dotplots

  18. The Story of Moose — ESEC/FSE 2005 Clone detection by string-matching Solid diagonals indicate significant duplication between or within source files.

  19. The Story of Moose — ESEC/FSE 2005 Challenges Difficulties and challenges… • Importing models and scaling to large data sets • Exchanging information between tools and combining techniques • Querying and navigating within models The FAMOOS tools were highly successful, but largely ad hoc

  20. The Story of Moose — ESEC/FSE 2005 Roadmap • The Challenge of Software Evolution • The Reengineering Lifecycle • Reengineering with Moose • The evolution of Moose • Leveraging tools • Exploiting historical data • The Future of Software Evolution

  21. ConAn Van Hapax ... CodeCrawler Smalltalk Java External Parser CDIF COBOL Navigation C++ Metrics … Querying XMI Grouping The Story of Moose — ESEC/FSE 2005 The Components of Moose Extensible meta model Model repository Smalltalk (VW)

  22. ConAn Van Hapax ... … Namespace Package Smalltalk Attribute Class Inheritance Java COBOL Access Method Invocation FAMIX C++ … The Story of Moose — ESEC/FSE 2005 The Evolution of Moose 1. At first, CodeCrawler directly reflected on Smalltalk classes 3. Each tool needs its own information, so we need multiple meta-models 2. Modeling multiple languages requires a neutral meta-model

  23. The Story of Moose — ESEC/FSE 2005 “Everything is an Entity” Offers uniform approach to: • Selection • Navigation • Introspection • Presentation Individual classes or groups of classes are entities

  24. Width Metric Height Metric Position Metrics Color Metric The Story of Moose — ESEC/FSE 2005 Polymetric Views Polymetric views are useful for exploring whole systems, individual classes, or the evolution of entities

  25. The Story of Moose — ESEC/FSE 2005 Class Blueprint — Example • Root Class: • Template • Inconsistent accessor definition • Unused accessors • Direct attribute access • Template Method (DP) • Subclasses: • Siamese twins • Pure overriders

  26. First Version Version 2 .. Version (n - 1) Last Version Removed Classes Added Classes Growth Phase Stagnation Phase Time (Versions) The Story of Moose — ESEC/FSE 2005 The Evolution Matrix — Principles

  27. The Story of Moose — ESEC/FSE 2005 The Evolution Matrix — Example

  28. History A B C D The Story of Moose — ESEC/FSE 2005 History as a first class entity encapsulates the evolution Vers.1 Vers.2 Vers.3 Vers.4 Vers.5

  29. The Story of Moose — ESEC/FSE 2005 CC System Complexity View

  30. The Story of Moose — ESEC/FSE 2005 CC History View

  31. The Story of Moose — ESEC/FSE 2005 Other activities around Moose • Refactoring engine • Static and dynamic architecture recovery • Trace-based feature recovery • Concept mining • …

  32. The Story of Moose — ESEC/FSE 2005 Lessons learned • Make your meta-model explicit • Enables rapid development of new tools • Enables tool integration • Leverage tools that combine techniques • Enables tool “reuse” • Accelerates development and research • Use a dynamic programming environment • No run-time/compile-time dichotomy • Object inspector as default GUI & QL • …

  33. The Story of Moose — ESEC/FSE 2005 The Future of Moose • Correlating evolution with developers • Recovering domain concepts from source code • Modeling other kinds of artifacts • …

  34. The Story of Moose — ESEC/FSE 2005 Roadmap • The Challenge of Software Evolution • The Reengineering Lifecycle • Reengineering with Moose • The Future of Software Evolution • Concluding remarks

  35. The Story of Moose — ESEC/FSE 2005 Trends • Software is evolving ever more rapidly • Faster, smaller hardware • leads to new application domains • Globalization • leads to new opportunities and requirements • The internet and mobile computing • raise the bar for interoperability • We cannot afford to continue to develop software in the same old way!

  36. The Story of Moose — ESEC/FSE 2005 Conclusion We need to place software evolution at the centre of our software processes and tools. • Methods • Empirical research into “best practices” to support change • Tie forward, reverse and re-engineering • Tools • Model, analyse and transform evolving systems • Co-evolution of requirements, design and code • Programming Languages • Software as living systems • Context-aware programs Questions? Comments?

More Related