MSc Proposal Jorge Mascena jccpmcin ufpe br Silvio

MSc Proposal Jorge Mascena – jccpm@cin. ufpe. br Silvio Lemos Meira (Advisor) – srlm@cin. ufpe. br

Agenda § Introduction p Software Maintenance p Change Impact p Traceability p Software Product Families p Summary § Context § Future Work Reuse in Software Engineering Group 2

Introduction • [Lago, 2004] • “In software product families, the full benefit of reuse can only be achieved if traceability of requirements to architecture, components and further down to source code is supported. ” Reuse in Software Engineering Group 3

Introduction • Traceability has been generally associated to software maintenance • Source code change propagation [Hassan, 2004] [Kowalczykiewicz, 2002] [Chen, 2001] [Eisenbach, 2001] [Gwizdala, 2003] [Zimmermann, 2004] Reuse in Software Engineering Group 4

Introduction • Traceability has been generally associated to software maintenance • Change impact analysis [Antoniol, 1999] [Elbaum, 1998] [Mockus, 2000] [Gall, 1999] [Bohner, 2002] [Clarke, 2003] [Briand, 2003] [Gold, 2003] Reuse in Software Engineering Group 5

Software Maintenance {History} • [Kilpi, 1997] • “Software industry is developing strongly towards becoming a product business. ” • “This lays increasing demands for the development of software product management process and its tool support in the companies“ Reuse in Software Engineering Group 6

Software Maintenance {History} • Attempts to manage software development complexity are paperwork-oriented [Kowalczykiewicz, 2002] • “US Dept. of Defense spends about 4% of its IT costs on traceability, getting inadequate value from that money” • Tool support is restricted basically to version control systems [Kilpi, 1997] Reuse in Software Engineering Group 7

Software Maintenance {History} • “Software maintenance is an important part of the software lifecycle, typically accounting for at least 50 percent of the total lifetime cost of a software system” [Gold, 2003] Reuse in Software Engineering Group 8

Software Maintenance {Types} • The type of maintenance has effects on the cost of the change [Mockus, 2000] [Souza, 1998] • Classifications vary, most common one • Corrective • Adaptive • Inspection • Perfective Reuse in Software Engineering Group 9

Software Maintenance {Types} • Corrective changes are generally harder than other types [Mockus, 2000] • Adaptive changes take most of the time during maintenance [Souza, 1998] • Perfective and inspection changes usually have small impact [Souza, 1998] Reuse in Software Engineering Group 10

Software Maintenance {Models} • [Souza, 1998] • Quick-fix model is the most used one (no documentation update) • Metrics-based impact analysis is rarely done • Source code is the most used source of knowledge • Most of the time is spent in change comprehension 11 Reuse in Software Engineering Group

Change Impact {Cycle} • [Gwizdala, 2003] [Chen, 2001] Cycle of an incremental change • Change request (free text) • Concept location • top-down • bottom-up • backward data flow • forward data flow Reuse in Software Engineering Group 12

Change Impact {Cycle} • [Gwizdala, 2003] [Chen, 2001] Cycle of an incremental change • Concept actualization (implementation) • Incorporation (replacement of old version) • Change propagation (keep code consistent) Reuse in Software Engineering Group 13

Change Impact {Metrics} • [Elbaum, 1998] • “The introduction of new code, however, is just as error prone a process as was the initial code generation” • Metrics estimate code complexity and fault injection/removal rates • “The general notion of software test is that the rate of fault removal will generally exceed the rate of fault injection” Reuse in Software Engineering Group 14

Change Impact {Visualization} • “In evolving through releases, developers modify system structure and properties. Tracking their historical evolution allows the programmer to document the events that influenced the system evolution and to identify the reasons for structural problems” [Gall, 1999] Reuse in Software Engineering Group 15

Change Impact {Visualization} P P’ Reuse in Software Engineering Group P’’ 16

Change Impact {Visualization} • Version tracking visualization requires abstraction, navigation and automation [Antoniol, 1999] • 2 -D and 3 -D graphics are commonly used (time as the third dimension) in conjunction with color scales to alleviate the process of thinking of abstract information [Gall, 1999] Reuse in Software Engineering Group 17

Change Impact {Comprehensibility} • “The high cost and central role of comprehension within software maintenance has been recognized by many authors and has been attributed to software complexity” [Gold, 2003] • Source code becomes more complex and documentation becomes outdated as software evolves. Reuse in Software Engineering Group 18

Change Impact {Comprehensibility} • [Gold, 2003] shows that it’s important to trace concepts to indicators in source code (comments, indentation, variable names, typical code fragments etc. ) in order to improve comprehensibility • Characterization of concept evolution • Add/Delete • Geometry • Assignment 19 Reuse in Software Engineering Group

Change Impact {Comprehensibility} P P’ P Add P’ Remove P P’ Grow Reuse in Software Engineering Group 20

Traceability {Level} • Most research on traceability is focused on the source code level [Antoniol, 1999] [Hassan, 2004] [Chen, 2001] [Eisenbach, 2001] [Gwizdala, 2003] [Clarke, 2003] • Recent work shifted focus to the whole development cycle [Briand, 2003] [Kowalczykiewicz, 2002] [Zimmermann, 2004] • Product family development traceability is the new trend [Lago, 2004] Reuse in Software Engineering Group 21

Traceability {Change Propagation} • “… a machine and a mind can beat a mindimitating machine working by itself” [Chen, 2001] • Change propagation tools help developers in finding ripple effects of changes • History-based [Hassan, 2004] [Zimmermann, 2004] • Structure-based [Chen, 2001] [Eisenbach, 2001] [Gwizdala, 2003] [Briand, 2003] • Protocol-based [Kowalczykiewicz, 2002] Reuse in Software Engineering Group 22

Traceability {Change Propagation} Original change Propagation (1 st level) Propagation (2 nd level) No change Reuse in Software Engineering Group 23

Traceability {Change Propagation} • Precision and recall are used to estimate the performance of change propagation detection methods • Statistics and heuristics to prune false positives Reuse in Software Engineering Group 24

Traceability {Change Propagation} • May be used to prevent error caused by missing changes [Zimmerman, 2004] • Must keep false alarms at a low rate to avoid spoiling developers confidence on the tool Reuse in Software Engineering Group 25

Software Product Families • [Lago, 2004] • “The development of a product family is time-consuming and expensive, and repayment can happen only if its features, architecture and components are used several times…” Reuse in Software Engineering Group 26

Software Product Families • Still open issues • How to trace features all the way down to source code • Be certain that a proper set of variable features are incorporated in a product • Tool support is mandatory • Current notations don’t have tool support Reuse in Software Engineering Group 27

Software Product Families • Mapping features to an architectural style for a new product of the family • Mapping features to components • Feature clustering reduces the number of combinations • Product Family level • Product family feature map (PF FM) Reuse in Software Engineering Group 28

Software Product Families • Product level • Product feature map • Product component map (CM) • Implementation level • COTS • Source code • Documentation • Top-down and bottom-up traceability Reuse in Software Engineering Group 29

Software Product Families • Versioning still not supported • Relies on developer to populate the families manually Reuse in Software Engineering Group 30

Summary • Traceability is fundamental for maintenance and reuse (product families) • Fully automated traceability is not practical • Tool support still not a reality • Focus must shift from source code to a broader context (top-down and bottomup traceability) Reuse in Software Engineering Group 31

Summary Kilpi Version Control and Configuration Management Kowalczykiewicz & Weiss Taming uncontrolled change in software development Gall, et al. Visualizing Software Release Histories Elbaum & Munson Impact of Code Change 1997 1998 1999 Gwizdala, et al. Change Propagation Bohner Software Change Impacts Chen & Rajlich Change in Legacy Software 2000 2001 2002 Gold & Mohan Conceptual Changes in Evolving Source Code Lago, et al. Traceable Product Evolution 2003 2004 Eisenbach & Sadler Changing Java Programs Souza & Moreira A Survey on the Software Maintenance Process Antoniol, et al. Object-Oriented Software Traceability Briand, et al. Impact Analysis and Change Management of UML Models Clarke, et al. OO Changes Identification Taxonomy Mockus & Votta Software Changes x Historic Databases Product Line, Service and Component Traceability Zimmermann, et al. Mining Version Histories Hassan & Holt Predicting Change Propagation Reuse in Software Engineering Group 32

Context {Ri. SE} • [Almeida et al. , 2004] • The IEEE International Conference on Information Reuse and Integration. Component Traceability http: //www. cin. ufpe. br/~rise Reuse in Software Engineering Group 33

Context {Ri. SE} • Repository system provides components • Keep track of versions and clients • Metrics to evaluate client dependency • Notification mechanism for updates • Change visualization • Component-level traceability • Process enforcement + Tool support Reuse in Software Engineering Group 34

Problems • Traceability-related work focused on source code • Large-scale repository needs a traceability mechanism • Component evolution x Client base • Current reuse metrics are misleading • Trace links creation supported by tools • Evolution notification and visualization Reuse in Software Engineering Group 35

Problems {Large-scale} Reuse in Software Engineering Group 36

Problems {Metrics} Reuse in Software Engineering Group 37

Proposed Solution Software Reuse Environment Change Visualization Client Dependencies Reuse Metrics Change Notification Repository System Reuse in Software Engineering Group 38

Future Work • • • Thesis plan: feb/05 Metrics research: feb/05 Metrics tool: mar/05 Metrics paper: apr/05 Visualization research: may/05 Visualization paper: jun/05 Reuse in Software Engineering Group 39

Future Work • • Development and integration: sep/05 Solution paper: oct/05 Thesis writing: jan/06 Thesis presentation: mar/06 Reuse in Software Engineering Group 40

References § [Kilpi, 1997] Kilpi, Tapani. New Challenges for Version Control and Configuration Management: A Framework and Evaluation. IEEE, 1997. § [Lago, 2004] P. Lago, E. Niemela, H. Van Vliet. Tool Support for Traceable Product Evolution. Proceedings on the Eigth European Conference on Software Maintanance and Reengineering. IEEE, 2004. § [Hassan, 2004] Ahmed E. Hassan, Richard C. Holt. Predicting Change Propagation in Software Systems. Proceedings of the International Conference on Software Maintenance. IEEE, 2004. § [Kowalczykiewicz, 2002] Krysztof Kowalczykiewicz, Dawid Weiss. Traceability: Taming uncontrolled change in software development. IV Krajowa Konferencja Inzynierii Oprogramowania. Poznan, 2002. § [Chen, 2001] Kunrong Chen, Václav Rajlich. RIPPLES: Tool for Change in Legacy Software. 2001. § [Eisenbach, 2001] Susan Eisenbach, Chris Sadler. Changing Java Programs. 2001. Reuse in Software Engineering Group 41

References § [Gwizdala, 2003] Steve Gwizdala, Yong Jiang, Václav Rajlich. Jtracker: A Tool for Change Propagation in Java. Proceedings of the Seventh European Conference on Software Maintenance and Reengineering. IEEE, 2003. § [Zimmermann, 2004] Thomas Zimmermann, Peter Weizgerber, Stephen Diehl, Andreas Zeller. Mining Version Histories to Guide Software Changes. Proceedings of the 26 th International Conference on Software Engineering. IEEE, 2004. § [Antoniol, 1999] G. Antoniol, G. Canfora, A. De Lucia. Maintaining Traceability During Object-Oriented Software Evolution: a Case Study. 1999. § [Elbaum, 1998] Sebastian G. Elbaum, John C. Munson. Code Churn: A Measure for Estimating the Impact of Code Change. 1998. § [Mockus, 2000] Audris Mockus, Lawrence G. Votta. Identifying Reasons for Software Changes Using Historic Databases. 2000. § [Gall, 1999] Harald Gall, Mehdi Jazayeri, Claudio Riva. Visualizing Software Release Histories: the Use of Color and Third Dimension. 1999. 42 Reuse in Software Engineering Group

References § [Bohner, 2002] Shawn A. Bohner. Software Change Impacts: An Evolving Perspective. Proceedings of the International Conference on Software Maintenance. IEEE, 2002. § [Clarke, 2003] Peter Clarke, Brian Malloy, Paul Gibson. Using A Taxonomy Tool To Identify Changes In OO Software. Proceedings of the Seventh European Conference On Software Maintenance And Reengineering. IEEE, 2003. § [Briand, 2003] L. C. Briand, Y. Labiche, L. O’Sullivan. Impact Analysis and Change Management of UML Models. Proceedings of the International Conference on Software Maintenance. IEEE, 2003. § [Gold, 2003] Nicolas Gold, Andrew Mohan. A Framework for Understanding Conceptual Changes in Evolving Source Code. Proceedings of the International Conference on Software Maintenance. IEEE, 2003. § [Souza, 1998] Maria João Castro Souza, Helena Mendes Moreira. A Survey on the Software Maintenance Process. IEEE, 1998. Reuse in Software Engineering Group 43