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

2. 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

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

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

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

6. 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?

7. 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

8. 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

9. 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

10. 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

11. 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?

12. 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)

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

14. Experimental Process

15. Tasks

16. 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).

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

19. 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

20. 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

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

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

23. Appendix (Results: Time)

24. Appendix (Results: Correctness)

25. Appendix (Results: Design Quality)

26. Appendix (Results: Time Spent on UML)