ClassDiagrammer
Software Engineering Documentation
1. Introduction
Requirements
3.
Usage Scenario
The
following scenario describes how one might use the proposed ClassDiagrammer app
to create a class diagram.
The
user wishes to create a diagram of some bank account classes. The user starts the class diagramming app,
and adds three class labels: BankAccount, CheckingAccount and
SavingsAccount. Class labels are added
by right-clicking at the location at which the label should be created.
The
user decides the three labels have been created too close to the top of the
diagram, so the user clicks on each label and drags it downward.
To
show the relationships between the bank account classes, the user connects the
CheckingAccount and SavingsAccount classes with the BankAccount class using “is
a kind of” links. Links are created by right-clicking in an empty part of the
diagram, and then selecting the type of link to create from the menu that
appears.
To indicate the major data held by a
BankAccount, the user adds labels for the owner, the balance, and a list of
transactions. The user links each of
these class members to the BankAccount class label with “has a” links. To define the details of the “owner” class
member, the user adds a Client class with class members “name”, “address” and
“SSN”, linking the “owner” class member with the Client class with an “is a”
link. To provide some detail about transactions, the user adds a class label
named “Transaction”. Additionally, to
further define the SavingsAccount class, the user adds an “interestRate” data
member and a “double” type label, and connects the two labels with an “is a”
link.
To
specify important interfaces, the user adds labels for the Checking and the
Savings interfaces, and links each of these interfaces to the CheckingAccount
and SavingsAccount classes, respectively, with “implement interface”
links. To specify the methods specified
by these interfaces, the user adds interface method labels “processCheck()” and
“depositInterest()”, and links these interface method labels to their
respective interface labels with “interface specifies” links.
To
organize the labels in an aesthetic fashion, the user clicks on and drags each
label that needs to be repositioned. For
each link attachment point that needs to be moved, the user clicks on the
attachment point and drags it to an appropriate location.
The
user decides the diagram will be overly cluttered by including the Transaction
class. To delete the Transaction class
label, the user clicks on the label to bring up a context menu, and deletes the
label by selecting the “Delete” menu item.
The
user also notices that the “is a” link between the “owner” class member and the
“Client” class labels was inadvertently constructed as a “is a kind of”. To correct this error, the user clicks on
the link to bring up a context menu, and selects the appropriate link type from
the menu.
The
user also notices that the “Client” class label contains a misspelling. To correct the misspelling, the user clicks
on the label to bring up a context menu, selects “Change text” from the menu.
To
indicate that BankAccount objects use a printSpooler service to generate
monthly statements, the user adds a printSpooler object label and a PrintSpooler
class. The user connects the
printSpooler object with the PrintSpooler class with an “is a” link, and to
indicate that the BankAccount class uses the printSpooler, the user adds a
“uses/accesses” link from the BankAccount class to the printSpooler
object. Since the “uses/accesses” link
runs too closely to the CheckingAccount label, the user decides to add a bend
to the “uses/accesses” link, and the drag the bend away from the
CheckingAccount label.
The
user is not sure whether the BankAccount class should use the printSpooler
object directly, and would like to include some annotations in the
diagram. First the user marks the
“uses/accesses” link with a “proposed to add” symbol, and then adds a note near
the symbol with the text, “Should the BankAccount class directly use the
printSpooler?”
The
user is also concerned that the interface and interface methods add too much
detail to the diagram. The user decides
to hide these labels. To hide the labels, the user clicks on each label and
link involved to bring up a context menu, and chooses the “Hide” menu
item. As a reminder that the diagram
contains these hidden items, the user adds a note at the top of the diagram
stating, “Interface labels” are hidden.
To check the hidden items, the user shows them with “ghost” graphics by
clicking on the “Show hidden items” item on the “Options” menu in the main menu
bar.
Initially
the user thinks that the key also adds too much clutter to the diagram, and
turns off the key with the “Hide key” item on the “Options” menu. However, the user reconsiders, and brings
back the key with the “Show key” menu item.
The
resulting diagram is:
Figure 3: The class diagram
created by following the steps in this scenario
To
save the diagram to a file, the user brings up the “Save” dialog box, enters a
file name, and clicks on “Save”.
Finally,
the user emails the diagram to a colleague for a design review. The colleague
opens the diagram with the “Open” dialog box, and phones the user to go over design
issues.
5. Non-functional requirements
Design
7. System Structure -
The 30,000 ft view
8. Subsystem objects and interfaces
Download a Java executable of the ClassDiagrammer
(ClassDiagrammerApp.jar)
Download a sample diagram created by the
ClassDiagrammer (BankAccountClasses.cd)
Copyright © 2009 John Keklak. All rights reserved. Based on version 090515a.