Comprensione del software - principi base e pratica reale 5

Transcription

1 Prologue C era una volta Comprensione del software - principi base e pratica reale Reverse engineer lines of C++ code in ca classes * 2 = seconds / 3600 = 667 hours 667 hours / 8 = 83 working days 83 days / 5 = 16 working weeks and 3 days ~ 4 months Michele Lanza Facoltà di scienze informatiche Università della Svizzera italiana Questions: What is the size and the overall structure of the system? What is the internal structure of the system and its elements? How did the software system become like that? Comprensione del software - principi base e pratica reale 1 The Life Cycle of Software Systems Object-Oriented Reverse Engineering Requirements Analysis Goal: take a (large legacy) software system and understand it, i.e., construct a mental model of the system? Issues Tool support Scalability Flexibility Time Design Implementation Problem: the software system in question is Unknown, very large, and complex Domain- and language-specific Seldom documented or commented In bad shape Comprensione del software - principi base e pratica reale 2 Comprensione del software - principi base e pratica reale 3 Object-Oriented Reverse Engineering (II) Reverse Engineering Approaches Constructing a mental model requires information about the system: Top-down approaches Bottom-up approaches Mixed Approaches There is no silver bullet methodology Every reverse engineering situation is unique Need for flexibility, customizability, scalability, and simplicity Reading (source code, documentation, UML diagrams, comments) Running the SW and analyze its execution trace Interview users and developers (if available) Clustering Concept Analysis Software Visualization Software Metrics Slicing and Dicing Querying (Database) Data Mining Logic Reasoning Comprensione del software - principi base e pratica reale 4 Comprensione del software - principi base e pratica reale 5 1

2 The Information Crystallization Problem Many approaches generate too much or not enough information The reverse engineer must make sense of this information by himself We need the right information at the right time..take a step back..block the ground..think about it.. The information needed to reverse engineer a legacy software system resides at various levels We need to obtain and combine Coarse-grained information about the whole system Fine-grained information about specific parts Evolutionary information about the past of the system Comprensione del software - principi base e pratica reale 6 Comprensione del software - principi base e pratica reale 7 A Solution - The Polymetric View The Polymetric View - Principles A lightweight combination of two approaches: Software visualization (reduction of complexity, intuitive) Software metrics (scalability, assessment) Interactivity (iterative process, silver bullet impossible) Does not replace other techniques, it complements them: Opportunistic code reading Visualize software: entities as rectangles relationships as edges Enrich these visualizations: Map up to 5 software metrics on a 2D figure Map other kinds of semantic information on nominal colors Entities Relationships width metric 2 position metrics color metric height metric Comprensione del software - principi base e pratica reale 8 Comprensione del software - principi base e pratica reale 9 The Polymetric View - Example The Polymetric View - Example (II) System Complexity View Nodes = Classes Edges = Inheritance Relationships Width = Number of Attributes Height = Number of Methods Color = Number of Lines of Code System Complexity View Nodes = Classes Edges = Inheritance Relationships Width = Height = Color = Reverse engineering goals # attributes # methods # lines of code Get an impression (build a first raw mental model) of the system, know the size, structure, and complexity of the system in terms of classes and inheritance hierarchies Locate important (domain model) hierarchies, see if there are any deep, nested hierarchies Locate large classes (standalone, within inheritance hierarchy), locate stateful classes and classes with behaviour View-supported tasks Count the classes, look at the displayed nodes, count the hierarchies Search for node hierarchies, look at the size and shape of hierarchies, examine the structure of hierarchies Search big nodes, note their position, look for tall nodes, look for wide nodes, look for dark nodes, compare their size and shape, read their name => opportunistic code reading Comprensione del software - principi base e pratica reale 10 Comprensione del software - principi base e pratica reale 11 2

3 Coarse-grained Software Visualization Coarse-grained Polymetric Views - Example Reverse engineering question: What is the size and the overall structure of the system? LOC Method Efficiency Correlation View Coarse-grained reverse engineering goals: Gain an overview in terms of size, complexity, and structure Asses the overall quality of the system Locate and understand important (domain model) hierarchies Identify large classes, exceptional methods, dead code, etc. NOS Nodes: Methods Edges: - Size: Number of method parameters Position X: Number of lines of code Position Y: Number of statements Goals: Detect overly long methods Detect dead code Detect badly formatted methods Get an impression of the system in terms of coding style Know the size of the system in # methods Comprensione del software - principi base e pratica reale 12 Comprensione del software - principi base e pratica reale 13 CodeCrawler Demo Coarse-grained SV - Conclusions Benefits Views are customizable (context ) ) and easily modifiable Simple approach, yet powerful Scalability Limits Visual language must be learned Comprensione del software - principi base e pratica reale 14 Comprensione del software - principi base e pratica reale 15 Fine-grained Software Visualization Reverse engineering question: What is the internal structure of the system and its elements? The Class Blueprint - Principles Initialization External Interface Internal Implementation Accessor Attribute Fine-grained reverse engineering goals: Understand the internal implementation of classes and class hierarchies Detect coding patterns and inconsistencies Understand class/subclass roles Identify key methods in a class The class is divided into 5 layers Nodes Methods, Attributes, Classes Edges Invocation, Access, Inheritance Invocation Sequence The method nodes are positioned according to Layer Invocation sequence Comprensione del software - principi base e pratica reale 16 Comprensione del software - principi base e pratica reale 17 3

4 The Class Blueprint - Principles (II) The Class Blueprint - Example # invocations Method # external accesses Attribute # lines # internal accesses Abstract Method Overriding Method Delegating Method Extending Method Constant Method Read Accessor Write Accessor Attribute Delegate: Delegates functionality to other classes May act as a Façade (DP) Large Implementation: Deep invocation structure Several methods High decomposition Wide Interface Direct Access Sharing Entries Method Invocation Direct Attribute Access Comprensione del software - principi base e pratica reale 18 Comprensione del software - principi base e pratica reale 19 The Class Blueprint - Example (II) The Class Blueprint - What do we see? Call-flow Double Single Entry (=> split class?) Inheritance Adder Interface overriders Semantics Direct Access State Usage Sharing Entries Comprensione del software - principi base e pratica reale 20 Comprensione del software - principi base e pratica reale 21 CodeCrawler Demo Fine-grained SV - Conclusions Benefits Complexity reduction Visual code inspection technique Complements the coarse-grained views Limits Visual language must be learned Good object-oriented knowledge required No information about actual functionality => opportunistic code reading necessary Comprensione del software - principi base e pratica reale 22 Comprensione del software - principi base e pratica reale 23 4

5 Messaggio Promozionale Object-Oriented Metrics in Practice M. Lanza, R. Marinescu ISBN: Springer, Nice! but, what about the practice?? In practice the key question is where to start We have devised a methodology to characterize, evaluate and improve the design of object-oriented systems It is based on: The Overview Pyramid The System Complexity View Detection Strategies Class Blueprints Comprensione del software - principi base e pratica reale 24 Comprensione del software - principi base e pratica reale 25 The Overview Pyramid A metrics-based means to both describe and characterize the structure of an object-oriented system by quantifying its complexity, coupling and usage of inheritance Measuring these 3 aspects at system level provides a comprehensive characterization of an entire system The Overview Pyramid in Detail The left side: System Size & Complexity Direct metrics: NOP, NOC, NOM, LOC, CYCLO Derived metrics: NOC/P, NOM/C, LOC/M, CYCLO/LOC The right side: System Coupling Direct metrics: CALLS, FANOUT Derived metrics: CALLS/M, FANOUT/CALL The top: System Inheritance Direct metrics: ANDC, AHH Comprensione del software - principi base e pratica reale 26 Comprensione del software - principi base e pratica reale 27 Interpreting the Overview Pyramid The pyramid characterizes a system from the viewpoints of size&complexity, coupling, and inheritance; based on the 8 computed proportions: They are independent of the size of the system! This allows an objective assessment Wait a second objective? objective? Where is the reference point? Putting things in a real-world context We have measured dozens of systems written in Java and C++ Based on the obtained measurements we can now statistically assess the design of a system Comprensione del software - principi base e pratica reale 28 Comprensione del software - principi base e pratica reale 29 5

6 Example: ArgoUML A system to model and handle UML diagrams The System Complexity View Provides locality and overview! Comprensione del software - principi base e pratica reale 3 0 Comprensione del software - principi base e pratica reale 3 1 Evaluating the Design of a System Design Harmony What entities do we measure in object-oriented design? It depends on the language What metrics do we use? It depends on our measurement goals What can we do with the information obtained? It depends on our objectives The problem is that simple metrics are not enough to understand and evaluate design Can you understand the beauty of a painting by measuring its frame? Software is a human artifact There are several ways to implement things The point is to find the appropriate way! Appropriate to what? Identity Harmony How do I define myself? Collaboration Harmony How do I interact with others? Classification Harmony How do I define myself with respect to my ancestors and descendants? Comprensione del software - principi base e pratica reale 3 2 Comprensione del software - principi base e pratica reale 3 3 Detection Strategies A Detection Strategy is a composed logical condition, based on metrics, that identifies those design fragments that are fulfilling the condition What? Transforming an informal design rule into a detection strategy Comprensione del software - principi base e pratica reale 3 4 Comprensione del software - principi base e pratica reale 3 5 6

7 A Catalogue of Design Disharmonies For each Design Disharmony, we provide Description Context Impact Detection Strategy Examples Refactoring The Class Blueprint It reduces the amount of code that must be read and thus serves as code inspection technique Comprensione del software - principi base e pratica reale 3 6 Comprensione del software - principi base e pratica reale 3 7 Messaggio Ri-Promozionale Object-Oriented Metrics in Practice M. Lanza, R. Marinescu ISBN: Springer, Evolutionary Software Visualization Reverse engineering question: How did the software system become like that? Evolutionary reverse engineering goals: Understand the evolution of OO systems in terms of size and growth rate Understand at which time an element, e.g., a class, has been added or removed from the system Understand the evolution of single classes Detect patterns in the evolution of classes Comprensione del software - principi base e pratica reale 3 8 Comprensione del software - principi base e pratica reale 3 9 The Evolution Matrix - Principles The Evolution Matrix - Principles (II) First Version Version 2.. Version (n - 1) Removed Classes Last Version The Evolution Matrix reveals patterns The evolution of the whole system (versions, growth and stagnation phases, growth rate, initial and final size) The life-time of classes (addition, removal) Moreover, we enrich the evolution matrix view with metric information # methods Class # attributes Added Classes Growth Phase Time (Versions) Stagnation Phase This allows us to see patterns in the evolution of classes Comprensione del software - principi base e pratica reale 40 Comprensione del software - principi base e pratica reale 41 7

8 The Evolution Matrix - Pattern Language The Evolution Matrix - Pattern Language (II) Pulsar Repeated Modifications make it grow and shrink. System Hotspot: Nearly every new system version requires changes. No cheap class Supernova Suddenly increases in size, possible reasons: Massive shift of functionality towards a class. Data storage class Developers knew what to fill in. Time (Versions) White Dwarf Lost the functionality it had and now trundles along without real meaning. Possibly dead code. Red Giant A permanent god class which is always very large Idle Keeps size over several versions. Possibly dead code, possibly good code. Time (Versions) Comprensione del software - principi base e pratica reale 42 Comprensione del software - principi base e pratica reale 43 The Evolution Matrix - Pattern Language (III) The Evolution Matrix - Example Dayfly Persistent Has the same lifespan as the whole system. Part of the original design. Perhaps holy dead code which no one dares to remove. Exists during only one or two versions. Perhaps an idea which was tried out and then dropped. Comprensione del software - principi base e pratica reale 44 Comprensione del software - principi base e pratica reale 45 Evolutionary SV - Conclusions Industrial Validation - The Acid Test Benefits Complexity reduction Limits Scalability (can be solved) Rename problem (can be solved) Relative changes hard to see (can be solved) Several large, industrial case studies (NDA) Different implementation languages Severe time constraints System Language Lines of Code Classes Z C ~2300 Y C++/Java ~400 X Smalltalk ~2500 W COBOL Sortie C/C ~70 Duploc Smalltalk ~230 V C ~10000 Jun Smalltalk ~700 Comprensione del software - principi base e pratica reale 46 Comprensione del software - principi base e pratica reale 47 8

9 Epilogue Did we succeed after all? Not completely, but System Hotspots View on LOC of C++ System Complexity View on ca. 200 classes of C++ e vissero felici e contenti? Questions and Comments Comprensione del software - principi base e pratica reale 48 Comprensione del software - principi base e pratica reale 49 9