Experiences with a UML Diagram Critique Tool Robert W. Hasker, Andrew Rosene, James Reid University of Wisconsin Platteville MICS, 2012 Motivation Important skill for SE students: constructing, diagramming models Consider the following
"Experiences with a UML Diagram Critique Tool" is the property of its rightful owner. Permission is granted to
download and print the materials on this website for personal, non-commercial use only, and to display it
on your personal computer provided you do not modify the materials and that you retain all copyright
notices contained in the materials. By downloading content from our website, you accept the terms of this
agreement.
Presentation Transcript
01
Experiences with a UML Diagram Critique Tool Robert W. Hasker, Andrew Rosene, James Reid
University of Wisconsin – Platteville MICS, 2012<br>
02
Motivation Important skill for SE students: constructing, diagramming models
Consider the following class diagram
Reasonable structure, collection of classes<br>
03
Motivation Closer inspection:<br>
04
Motivation Closer inspection:<br>
05
Motivation Closer inspection:<br>
06
Motivation Closer inspection:<br>
07
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<br>
08
Use case model defects Use case diagrams:
good for introducing diagram “rules”
A pet food dispenser:<br>
09
Use case model defects Use case diagrams:
good for introducing diagram “rules”
A pet food dispenser:<br>
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<br>
11
Class model defects<br>
12
Class model defects<br>
13
Class model defects<br>
14
Class model defects<br>
15
Class model defects<br>
16
Class model defects Public
attribute<br>
17
Class model defects Public
attribute Nonstandard methods<br>
18
Class model defects Public
attribute Nonstandard methods Index variables Complex attributes<br>
19
Class model defects Capitalization standards
Missing documentation Public
attribute Nonstandard methods Index variables Complex attributes<br>
20
Using UMLint Visit www.uwplatt.edu/~hasker, find “umlint”<br>
21
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<br>
22
Example 1: Use case model<br>
23
Errors identified by UMLint Directed associations
(Directed) Associations between use cases
Classes
() after use case names<br>
24
Improved use case model Remaining error:
>3 links from
actor
Indicates flowchart<br>
25
Example 2: Mobile Application Ordering food
Items in categories
Optional condiments, components<br>
26
Underscores vs. camelCase Missing multiplicities Inconsistencies
Slow down development<br>
Example 4: Application Framework Second diagram by same group as ex. 3
Missing multiplicities, documentation<br>
31
Ex. 4: Revised Framework Result of adding documentation:<br>
32
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<br>
33
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<br>
34
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.”<br>
