This post originated from an RSS feed registered with Agile Buzz
by Kevin Rutherford.
Original Post: UML style - an example
Feed Title: silk and spinach
Feed URL: http://silkandspinach.net/blog/index.xml
Feed Description: kevin rutherford on agile software development and life in macclesfield
Last autumn I posted a personal UML style guide, followed soon afterwards by a detailed explanation of my reasoning for not including associations. Those articles had quite a positive reception (thanks), but patterns and heuristics can only go so far. So this article presents a (long) worked example to show my UML style in action. I make no claims for the resulting model - except that it works for me, and seems to satisfy those who are able to persuade me to create UML models. I should also point out that I usually - ie. when I have the opportunity - jump right to the last page; what you see here is one conceptual route to that end point...
Fade to an imaginary office somewhere in the north of England. It's the end of an imaginary project in which we've developed an XP planning game tool in Java (this example is based on the Planning Game Simulator exercise in Bill Wake's excellent Refactoring Workbook). The customer has scheduled a story to document any "interesting" parts of the design, as a roadmap for the code's future developers and maintainers. We select the tool's status bar, and we decide to draw a UML model to convey the following information:
The status bar always displays a summary of the plan (number of cards, their total cost, current velocity, and number of iterations required to complete the backlog). Whenever a card is added to or removed from the backlog, or when a card's cost changes, or when a card is split, the Plan re-calculates everything and the status bar updates itself to show the new information. The status bar does this by listening for change events thrown by the Backlog; when one occurs it requests the latest information from the Plan and displays it.
We begin by drawing a static model showing the classes involved, with their relationships, methods and packages. This is the kind of model created by one of those reverse engineering tools that reads our code and constructs a thorough model of it all:
Previous Topic
). The customer has scheduled a story to document any "interesting" parts of the design, as a roadmap for the code's future developers and maintainers. We select the tool's status bar, and we decide to draw a UML model to convey the following information: