Homework 2. CS4240: Principles of SW Design
Last modified: Sept. 23, 2010,
3 pm
Summary: Create
high-quality UML diagrams from existing code.
Learning objectives for this homework:
- Study and apply the rules for creating UML class and sequence
diagrams.
- See how these diagrams can document and help in understand
existing code
When Due: Tuesday, Oct.
5, 11:30 pm. Submit this to the ITC Collab site for the course
under the Assignments section.
Rules on collaboration, tools:
(A)
You may talk to one other student to choose the classes and
interactions to model. If you're confused about "the rules" or
how UML works on these classes and methods, you can also discuss that
with this class-mate.
(B) However, each person must draw their own
diagrams and turn in their own report. In your report, list any
person you talked to.
(C) The use of reverse-engineering tools is
not allowed. The goal for this assignment is for you to learn how to
draw diagrams, and the use of tools defeats this purpose. (Later we
will see about these tools.)
What to do:
1)
Choose
one of the SW applications available for HW1. Probably simplest
for you to choose the one you worked on for HW1, but you can change if
you wish.
2) UML Class Diagram:
Choose
a small number of interesting or important classes from the system.
These should be at least four classes that are defined in terms
of each other or have interesting associations
or dependencies (in the UML
class diagram sense of those words). Create a class diagram of these
classes that shows:
- All attributes in the class (but see note below). Make
sure these show access and type according to UML syntax. If any are
abstract classes, mark them in italics or with the {abstract} comment.
- All
operations except for getters, setters, and constructors. Make
sure these show access, parameters, and return values according to UML
syntax. If any are abstract classes, mark them in italics or with
the {abstract} comment.
- Associations
to other classes in your diagram. For each one, show the
direction and the multiplicity. Put the variable-name as the
role-name. (See note below). Also use arrows to show if the
association is one-way or two-way.
- If it seems informative to
treat an association as a aggregation or composition, use the
appropriate diamond symbol. (But you can just name them as the
previous item describes.)
- Show dependencies between two classes. (Use the arrow to
indicate direction of the dependency.)
- You
do not have to choose classes where inheritance is used, but if you do,
show that in your UML class diagram. Also, if any of your classes
implement an interface, show that. If your objects have
associations with abstract classes or interfaces, show those as "class
boxes" with the proper indicator that their an interface or abstract
class.
Note on attributes: If the Java class has a field with
a type that is one of your classes in your diagram, do not list it as a
attribute in the class diagram. Instead, draw an association line
as described in (C) above.
But, if Java class has a field that is
not one of those in your diagram, list it as an attribute. (This
include library class-types such as String.)
Note on associations: If class Student contains a list of Course
objects and that variable is named courseList,
then in the UML class diagram you would:
- Put 0..* on the line from Student to Course closest to the Course
box.
- Put the variable name courseList
on the line from Student to Course, close to the Course box but not as
close as the multiplicity symbols. (In Violet, put "courseList
0..*" in the "start label" or "end-label" property for the
association-line.
- There
would be an arrow-head on the line pointing to Course. There would not
be an arrowhead on the line pointing to Student unless each Course
object had some kind of reference to Student(s) that were enrolled in
that Course. If there was, then there would be an arrow and also
symbols for multiplicity and role-name at the end of the line closest
to Student.
3) UML Sequence Diagram:
Create
a one-page UML sequence diagram that helps you understand or document
some interesting interactions in your classes. (It would be best
if this diagram used the classes in the previous part, but this is not
required.) The goal here is to get an understanding of how to
properly draw correct UML sequence diagrams and to see how they're
useful in documenting system behavior. Ideally you'll produce a diagram
about the size of the one on page 44 of the textbook (Figure 2-8) or a
bit smaller.
- Your
diagram starts with an "important" call to an object that will carry
out some responsibility that this object must take care of. (If
you're using Violet, you can't draw an incoming message call unless it
is attached to some object's activation bar, so you'll need one more
object at the far-left of your diagram showing this important incoming
method-call that comes to your object.) If a small diagram
results from this call (just two or three objects and three or fewer
method calls, say), then draw another diagram or diagram a follow-on
method call to your first object.
- Show the sequence of method
calls among at least four or so objects. For each method call,
show the name of the method call and any parameters passed.
- Show
the return back to the caller. If the code assigns a return value
to a variable, show this as a label on the return-line. (Only do
this if it conveys useful information.)
- If an object is created
by a constructor, show this as a method call but give the name as
<<create>> (the usual UML stereotype for this).
- Don't
show any method calls an object makes on itself. Don't show static
method calls. Don't show method calls to objects defined in the
standard library.
Note: Since the goal is to get
practice and not to fully document a system, if this diagram gets too
large then we can limit it as follows. If you're getting over to
the right-side of your diagram and are in a deepening sequence of
method calls to objects you didn't intend to document, then don't show
any calls the current method makes to other objects, and just show the
return back to the caller. But, put a UML note and a connector
here with this text: "Details omitted."
4) Report:
Create a Word document (or PDF document) that has:
A) Your name and any partner.
B)
A section with the class diagrams that has text that tells me what
application they're from and what package they're found in.
C) A
section with the sequence diagrams that has text that tells me what
method(s) are being called, and also where exactly in the application's
code I can find the initial call. (I'll need this to check your
results.)
Note: You can use Violet, Visual Paradigm, or any other tool.
However, if your tool does a bad job, you may lose points! Drawing by
hand is not permitted unless you talk to me and explain some kind of
unusual circumstances.
The systems you might do are listed in the HW1 assignment.