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:
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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.)
  5. Show dependencies between two classes.  (Use the arrow to indicate direction of the dependency.)
  6. 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:
  1. Put 0..* on the line from Student to Course closest to the Course box.
  2. 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.
  3. 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.
  1. 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.
  2. 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.
  3. 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.)
  4. 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).
  5. 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.