Reviewed By: Paul Varcholik University of Central Florida EEL 6883 – Software Engineering II Spring 2009 Wojciech James Dzidek, Erik Arisholm, Lionel C. Briand IEEE Transactions on Software Engineering May-June 2008

Unified Modeling Language (UML)  Allows for the visual representation of a system’s specification  Used to construct and document the artifacts of an object-oriented software system  Aids in communicating system properties

UML Advantages  Simplifies software complexities through higher levels of abstraction  Traceability from requirements to low- level design  More efficient communication

Traditional Design Conveyance  Domain-specific standardized notations Textual Notation Visual Notation  PV: Commonly no standard notation, or company/team specific notation standards

Need for UML  To efficiently communicate design intent, during: Initial development Maintenance Evolution

Need for an Empirical Study  Little reported evaluation of the use of UML-based development  Many perceive the development and maintenance of analysis and design models in UML to be ineffective  UML practices are therefore viewed as difficult to apply in projects were resources and time are tight (PV: read, all projects)  Can UML make a significant difference that would just the costs?

How should UML be used?  Diagrams sketched on a whiteboard  Selective communication rather than complete specification  Diagrams soon discarded  Mostly models, little code  UML becomes the programming language  All changes occur in the model

Experiment Overview  20 Professional Developers (Intermediate to senior- level consultants)  Individually performing the same 5 maintenance tasks  Real, nontrivial software system  Same development environment 10 developers used UML 10 developers did not use UML  Secondary Objective: identify reasons for varying results

Experiment Definition  Analyze the effects of UML for the purposes of evaluating costs and benefits of modeling artifacts with respect to: Effort Functional program correctness Design quality of the solution

Experiment Definition (cont.)  Baseline definition (against which the use of UML would be compared): 1. Source code is the main artifact used to understand the system 2. Source code is commented to define the meaning of the most complex methods and variables 3. There exists a high-level textual description of the system objectives and functionality

Research Questions 1. Does the provision of UML documentation reduce the effort required in correctly implementing the change tasks? 2. Does the provision of UML documentation increase the functional correctness of the delivered solution? 3. Does the provision of UML documentation improve the design quality of the delivered solution? 4. What are the shortcomings of the used state-of- the-art UML tool and how can it be improved?

Context Selection  Professional Java programmers performing realistic, nontrivial maintenance tasks  1-2 week duration  Real, nontrivial software system  20 developers recruited from Norwegian consulting companies (not students)  Developers given a 1-day refresher course on UML  UML modeling tool: Borland Together for Eclipse (BTE)

Targeted Software System  BESTweb Company-internal, web-based system developed in Java (by the first author of the paper)

Experimental Process

Tasks

Experimental Results  The UML was always beneficial in terms of functional correctness (introducing fewer faults into the software).  The UML was slightly more costly in terms of time if the UML documentation was to be updated (though, slightly less costly if it was not), though these results were not significant.  The UML helped produce code of better quality when the developers were not yet familiar with the system. The largest gains were experienced during the first  task. This is an important finding as developers in industry are often faced with the “first task” scenario due to high staff turnover and involvement on a very large system (where any one developer is only familiar with a small portion of the system).

Conclusion  Using UML can be beneficial when a developer must extend a nontrivial system that he/she is unfamiliar with

Strengths  Interesting, relevant, and modern topic  Well designed experiment  Very well written paper Clear Technical sound Compelling results Good use of tables and diagrams (not too heavy on the math) Even included a comparison against previous studies

Weaknesses  Only 1 study (needs to be replicated and verified)  More subjects  Could have included a secondary documentation system (non-UML) as a comparison point

Final Thoughts  Are the improvements because of UML or merely better documentation as a whole?

Wojciech James Dzidek, Erik Arisholm, Lionel C. Briand IEEE Transactions on Software Engineering May-June 2008 Reviewed By: Paul Varcholik University of Central Florida EEL 6883 – Software Engineering II Spring 2009

Appendix (Results: Time)

Appendix (Results: Correctness)

Appendix (Results: Design Quality)

Appendix (Results: Time Spent on UML)