----- Comments for students -----

It would be convenient for me if you could include your Pitt username in
the name of the file that you submit, such as bpw5_ex2.zargo.  If you
are submitting a single .zargo file, there's no need to zip it.  A
.zargo file is already a ZIP archive (hence the z) -- unzip it and have
a look at what's inside!

Please don't submit a separate .zargo file for each diagram.  Unless you
want to provide extended rationale, one .zargo file should be all that
you need to turn in.  You can use UML comments for explanatory notes.  I
don't know why you would submit .zargo~ files.  These are just backup
copies of the original .zargo file created by ArgoUML when it overwrites
the .zargo file with a new version.  The .zargo file is the one that
reflects your latest changes.

In the remainder of this email I will discuss some of the problems that
I saw while grading your exercises.

The issue that caused the most difficulty was the relationship between
attributes and associations.  To take one example, many students made
"course : Course" an attribute of Section and then drew an association
between the classes Course and Section.  But when each section is
associated with exactly one course, a course attribute in Section is
redundant.  If you look at the first class diagram in the "Practical
UML" tutorial linked to on the course web page, you will notice that a
Customer is associated with each Order, but no "customer" attribute
appears in the Order class.  In an actual implementation we would expect
to find a customerID field or a pointer to a Customer object, but such
implementation details can be omitted from the UML diagram because it is
the link between orders and customers that really matters, not how it is
stored, and this link is fully captured by the association.

It isn't really incorrect to show an attribute in a class that
represents the opposite end of a binary association navigable from that
class, so an implementation-level view of the GradeReport class could
show that it has the three fields student number, section number, and
grade.  At the design level, however, it's more important to depict the
intention behind the student number and section number fields, which is
just to link a grade with a single student and a single section.

No one lost points specifically for duplicating the information in the
associations as attributes.  I did expect you to show the associations,
however, or else you could have drawn the whole class diagram without a
single association, and if you showed both the association and the
attribute, the two have to be consistent.  For example, if your diagram
shows that one instance of Student is associated with 1..* instances of
Department, but the Student class has just two attributes of type
Department (major and minor), each with an implied default multiplicity
of 1, then it is very unclear what relationship exists between a student
and a third department that the student is associated with.

Sometimes just using an attribute whose type is a class is more
appropriate than showing an association.  Dates are a good example of
this.  Every student has a date of birth, but that doesn't mean that you
have to draw an association between the Date class and the Student
class.  Usually you only care about the date as a property of a student
object, not as an object in its own right, so you don't lose anything by
showing the student's birth date as an attribute of type Date.  On the
other hand, if you care about the relationships that an individual date
has with other objects (suppose, for example, that you wanted to know
how many students were born on a certain date), then it would be useful
to think of a date as an object associated with multiple students in the
role of birth date.

Numbers are an even clearer example.  Suppose that every instance of
class Section is associated with exactly one instance of class Integer,
the number of students in that section.  Should we draw an association
between Section and Integer, and give the role name "number of students"
to the Integer end?  That clearly borders on the absurd, because we
don't care about integers as independent objects.  But when every
instance of class Order is associated with exactly one instance of class
Customer, it is very natural to represent this relationship as an
association (not just as a customer attribute of Order).

In most cases Date and Integer should actually be modeled as data types
rather than classes: a data type is a type whose instances are
identified only by their values, whereas each instance of a class always
has its own identity, regardless of whether its attribute values are
identical to those of another object of the same class.

You might think that a situation where attributes are necessary is when
multiple attributes of a class would have the same type.  For example, a
student can have a major department and a minor department.  If these
were attributes of type Department, there wouldn't be any difficulty.
If a student didn't have these attributes, however, but only an
association with two departments, how would you know which is the
student's major and which is the student's minor?  In this case there
are actually two distinct associations between a Student and a
Department: one in which the department is the student's major and one
in which the department is the student's minor.  These are both
relationships between a student and a department, but the nature of the
association is fundamentally different in the two cases.  Note that the
use of two associations easily handles the case where a student has
multiple majors and multiple minors, or hasn't declared a major.

A similar situation arises if you decide to have an Address class.  An
address can be either a student's permanent address or the student's
current address.  These are two distinct relationships that can exist
between a student and an address, so you should create two associations.
One address object can be associated with a student in both of these
ways at once, however, if the student's permanent address is the same as
the student's current address.

These examples show that it isn't unusual for multiple associations to
exist between a pair of classes.  In ArgoUML you can draw a second or
third association in the same way that you draw the first one (if this
doesn't seem to work, the new association is probably on top of the old
one -- try dragging it around).  Be sure to give all of the associations
names or label their association ends with role names so that a reader
of the diagram knows which relationship each association stands for.

It's probably not a good idea to store an entire address as one string.
You would have to put delimiters in the string and parse it every time
you wanted access to one of the parts of the address (you might only be
interested in knowing what state a student is from, for example).  I
would prefer to create an Address class or data type that captures the
structure of an address directly and allows easy access to each of its
members.  A Date class or data type is also arguably more useful than a
string or integer representation of a student's birth date.

Most students included multiplicities in their use case diagrams,
although none of the examples that we've seen in class had them.  For
this exercise I don't think that multiplicities contribute any
information that common sense does not supply, so I would prefer to
leave them out.  It took me a while to figure out how to do so in
ArgoUML, however.  Here's how:

1. Click on the association whose multiplicities you want to remove.

2. In the middle of the Properties tab at the bottom of the window there
   is a list box labeled "Connections."  It should contain two
   AssociationEnds.  Double-click on one of them so that its Properties
   tab appears.

3. Uncheck the check box to the right of the "Multiplicity" label.  The
   multiplicity on one end of the association will disappear from the
   diagram.

4. Click on the second button from the left at the top of the Properties
   tab (the one with tooltip "Go Opposite").  This takes you to the
   other AssociationEnd.

5. Uncheck the Multiplicity check box here as well.

You can also get to the AssociationEnds from the "Association Ends" list
box of an Actor or Use Case (on the right side of the Properties tab).

If the above procedure seems tedious, you can edit the XMI file
contained within the .zargo file directly.  If you unzip the .zargo
file, you will find that one of the files contained in it has the
extension .xmi.  This is just an XML file.  Delete all of the
<UML:AssociationEnd.multiplicity> elements (since you're upper-level CS
students, you should be able to automate this).  Now zip together the
other files from the .zargo archive and the modified .xmi file into a
new .zargo file.  Open it in ArgoUML and all of the multiplicities
should be gone.

If you do decide to include multiplicities in a use case diagram, here's
how to interpret them: "when a use case has an association to an actor
with a multiplicity that is greater than one at the actor end, it means
that more than one actor instance is involved in initiating the use
case" (UML Superstructure Specification v2.1.2, p. 595), and "when an
actor has an association to a use case with a multiplicity that is
greater than one at the use case end, it means that a given actor can be
involved in multiple use cases of that type" (ibid., p. 587).  If an
actor's involvement in a use case is optional, you could use a
multiplicity of 0..1 on the use case end.  The multiplicity on the actor
end would typically be 1.  For example, a student doesn't have to
request a grade report, but if a grade report is requested, exactly one
student actor is responsible for initiating the request.

The information system in the use case described as "a student can
request a grade report from the information system" is not an actor: it
is the software system that you are modeling.  Thus the exercise
instructions tell you to "consider the following set of requirements for
a university information system."  The actors are the entities that are
not part of the system but interact with the system (strictly speaking,
the actors model the roles played by these entities).

It's probably best to make one diagram that contains all of the use
cases as long as that diagram doesn't grow so large that it becomes
difficult to read.

Some people labeled the use case diagram "University."  This is a bit
too broad: the subject of the use case diagram is properly "University
Information System," and the right notation for the name of the subject
is not the note symbol, which is a UML comment.  You can draw a system
boundary rectangle and a subject name using the tools accessible from
the rightmost button on the diagram editing toolbar (the one that shows
a capital A by default).  Some tips:

- If you make the line color of a text object the same as the fill color
  of an enclosing rectangle object, the rectangular border around the
  text will be invisible.

- If you draw a rectangle and it covers up the elements in your diagram,
  right-click on it and select "To Back" from the Ordering submenu.

The notation for extension points in ArgoUML is not entirely
satisfactory.  Extension points are supposed to be listed in a
compartment of a use case with the heading "extension points."  I
believe that the words "extension points" are mandatory.  The reason for
this is probably that according to the UML specification, a use case can
have additional compartments for operations and attributes.  Note also
that an extension point just identifies a point in a use case where its
behavior can be augmented: the additional behavior needs to be shown
separately as an extending use case.

Brian Wongchaowart