Experiences with a UML Diagram Critique Tool

1. Experiences with a UML Diagram Critique Tool Robert W. Hasker, Andrew Rosene, James Reid University of Wisconsin – Platteville MICS, 2012

2. Motivation • Important skill for SE students: constructing, diagramming models • Consider the following class diagram • Reasonable structure, collection of classes

3. Motivation • Closer inspection: Redundant with association

4. Motivation • Closer inspection: Missing objects Redundant with association

5. Motivation • Closer inspection: Missing objects Redundant with association Nonstandard notation

6. Motivation • Closer inspection: Missing objects Redundant with association Nonstandard notation What sort of thing is a “security”?

7. Solutions • Ideally, the modeling tool would catch such errors • Professional tools (such as IBM Rational Rose used here) must allow for a wide variety of practices • Student tools reduce competitiveness, don’t seem mature • UMLint: identifies potential errors • Inspiration: the C programming utility, lint • Currently focused on class, use case diagrams • Presentation • Overview of issues identified by UMLint • Experiences from the students in using the tool in upper-level classes

8. Use case model defects • Use case diagrams: • good for introducing diagram “rules” • A pet food dispenser:

9. Use case model defects • Use case diagrams: • good for introducing diagram “rules” • A pet food dispenser: Backwards dependencies Belongs in class model Improper notation

10. Use case model defects • Use case diagrams: • good for introducing diagram “rules” • A pet food dispenser: • Backwards <<extend>>: no route to Block Excessive Eating Backwards dependencies Belongs in class model Improper notation

11. Class model defects Reversed generalizations

12. Class model defects Reversed generalizations Multiple “owners”

13. Class model defects Nondescript word Reversed generalizations Unnecessary abbreviation Multiple “owners”

14. Class model defects Nondescript word Reversed generalizations Low cohesion Unnecessary abbreviation Multiple “owners”

15. Class model defects Nondescript word Reversed generalizations Low cohesion Unnecessary abbreviation Multiple “owners”

16. Class model defects Nondescript word Reversed generalizations Low cohesion Unnecessary abbreviation Multiple “owners” Public attribute

17. Class model defects Nondescript word Reversed generalizations Low cohesion Unnecessary abbreviation Multiple “owners” Public attribute Nonstandard methods

18. Class model defects Nondescript word Reversed generalizations Low cohesion Unnecessary abbreviation Multiple “owners” Public attribute Complex attributes Index variables Nonstandard methods

19. Class model defects • Capitalization standards • Missing documentation Nondescript word Reversed generalizations Low cohesion Unnecessary abbreviation Multiple “owners” Public attribute Complex attributes Index variables Nonstandard methods

20. Using UMLint • Visit www.uwplatt.edu/~hasker, find “umlint”

23. Experiences • Example 1: model a rescue system for the Australian Outback • Victim calls for help • Operator plans route • Self-guided system delivers supplies • System can navigate obstacles • Goal of assignment: check skills retention • Students: capstone project course • Prerequisites: Data Structures, Object-Oriented Analysis & Design, Intermediate Software Engineering

24. Example 1: Use case model

25. Errors identified by UMLint • Directed associations • (Directed) Associations between use cases • Classes • () after use case names

26. Improved use case model • Remaining error: >3 links from actor • Indicates flowchart

27. Example 2: Mobile Application • Ordering food • Items in categories • Optional condiments, components

29. Underscores vs. camelCase Missing multiplicities • Inconsistencies • Slow down development

30. Example 3: Alternative Food App

31. Example 3: Alternative Food App • Complex attribute • Two owners for Item • Unrecognized/ misspelled words • Missing Multiplicities

32. Improved Food App • Fixing multiplicities revealed missing containers • Improved method placement

33. Example 4: Application Framework • Second diagram by same group as ex. 3 • Missing multiplicities, documentation

34. Ex. 4: Revised Framework • Result of adding documentation:

35. Discussion • Goal: improve student diagram quality • Assumption: forcing students to look more closely at diagrams would result in identifying missing classes, introduce generalizations, improve associations • Results: could not find cases of this for the students involved in this project (spanning multiple groups) • Report: these issues were identified by groups before submittal • Was successful in identifying smaller issues • Naming conventions • Incorrect associations • Missing multiplicities • Missing containers • Generally: found detailed errors that are difficult to identify by hand

36. Improvements • Improve check for documentation • A single space satisfies this check • Consider using natural language parser • Improve notification of deleted objects • Rose allows deleting object from diagram, not model • Should provide better feedback on where to find these • Provide command-line interface • Current web interface too cumbersome for frequent checks

37. Conclusion • In practice, UMLint addresses details more than big picture issues in designs • However, did help groups eliminate errors • Group members pointed out UMLint would flag certain choices • Helped remind users of notation • “Basic stuff, but it’s that basic stuff you forget.”