1 / 15

A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance

A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance. By: Wojciech James Dzidek – Student Member, IEEE Erik Arisholm – Member, IEEE Lionel C. Brand Senior – Member, IEEE

rafal
Download Presentation

A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance

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. A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance By: Wojciech James Dzidek – Student Member, IEEE Erik Arisholm – Member, IEEE Lionel C. Brand Senior – Member, IEEE Published in IEEE Transactions on Software Engineering, Vol. 34, Issue No. 3, May/June 2008

  2. Unified Modeling Language allows for the visual representation of a system’s specification. It is most useful in the maintenance phase of the software life cycle. Increased overhead makes investigation into whether use of UML can justify the costs necessary. Philosophies on how to implement UML vary between two extremes: Casual Implementation Model Driven Architecture Introduction

  3. To identify the costs and benefits of using UML in software maintenance. To identify the conditions needed for UML to be effective. Key Objectives

  4. T = Time taken to supply a correct solution excluding diagram T’ = Time taken to supply a correct solution including diagram modifications when using UML. C = The number of solutions submitted with a fault. C’ = The number of solutions submitted with a functionality-breaking fault. C’’ = The number of submissions that introduce a fault due to not taking all existing behavior into account. Q = The design quality of each correct submission will be higher when using UML Variables

  5. T (UML) < T(No-UML) T’(UML) ≠ T’(No-UML) C(UML) < C(No-UML) C’(UML) < C’(No-UML) C’’(UML) < C’’(No-UML) Q(UML) > Q(No-UML) Hypotheses

  6. Controlled experiment performed in a realistic environment at the Simula Research Laboratory. 20 professional developers split into UML and no-UML groups. Tasks were performed on BESTweb, a real, nontrivial system that was new to the developers. Each developer was given the same set of 5 maintenance tasks to perform. The EXPERIMENT

  7. PROCESS OF THE EXPERIMENT

  8. Add functionality to save a user’s search query to memory. Extend the system to handle an additional piece of data from an input file. Add functionality to allow users to add categories to the database. Add caching logic for statistical requests. Add functionality to allow users to remove categories from the database. Five TASKS

  9. For every subject, an initial questionnaire to gauge the subject’s knowledge and experience. For every submission, a copy of the entire source code and acceptance test reports. For every submission by a UML subject, a percentage estimate of the amount of time spent reading and updating the UML documentation. For every subject, an audiorecorded debriefing interview. Data Collection

  10. Quantitative: The variables were put through univariate and multivariate analysis, to check for significance. Qualitative: The answers from the debriefing sessions were coded to show UML usage patterns. Analysis

  11. The UML group spent 1.4% less time when not including the time spent modifying diagrams. When including diagrams, the UML group spent 14.5% more time. Neither of these differences were found to be statistically significant. In general, as the developers became more experienced with using and updating the UML, less time was spent on it Time Results

  12. Correctness Results

  13. The UML group had 7.3% more acceptable solutions overall. For Task 1, the UML group’s number of acceptable subtasks was 56.2% higher. There were no other significant differences in design quality. Design Quality Results

  14. The majority of the programmers felt the system and documentation were average or better as compared to the industry standard. More subjects in the UML group reported having trouble with Struts Framework or being rusty with Java. UML subjects complained of bad variable naming that made the UML diagrams hard to understand. Only one UML subject had extensive prior experience with UML and thus made full use of the UML. All UML subjects felt the UML training was adequate. Almost all of the developers had trouble with the UML tool. Qualitative Results

  15. The UML was always beneficial for functional correctness. The UML was slightly more costly in terms of time, if the documentation was updated, though not significantly so. The UML helped produce code of better quality before developers became familiar with the system. Biggest gains were for the first task. Qualitative evidence suggests a couple conditions in the experiment that limited the impact of UML. UML subjects’ relative lack of UML experience. UML subjects’ relative lack of familiarity with Java and Struts. A UML tool that was not optimally functional for the developers. Conclusions

More Related