Due:

Tuesday,  November 15, 2011 by 6:00 pm.  Email your completed practicum as defined in the Deliverable section below to the TA.

Purpose:

Building on Laboratory I, the purpose of this practicum is to become comfortable with basic UML skills by concentrating on the static model of a fairly contained design.  The design revolves around the requirements for a university course registration system.  This type of system is highly instructive from a structural modeling standpoint, as there are several decisions that need to be made as regards inheritance, aggregation, and various associations between classes.

Strategy:

You are to read the general description of the problem domain below.  Try and identify which classes you would need to create from the description.  Try and identify the central classes first.  After an initial conceptual model has been created, try and define any inheritance associations that exist.  Pay particular attention to the opportunities that exist to abstract (localize) common functionality in multiple related (derivative) classes upwards in the hierarchy.

Then, try and identify the attributes that belong to the classes, along with the operations that are necessary for each class.  Then, identify any collections that should exist in  your model, representing collections of other classes in your model, and note any aggregation or composition examples you find.  You should also identify other major associations between classes, including various types of dependencies.   Stereotype dependencies as to type.  If a class is associated with multiple unrelated classes, detail the role played by the class in the various associations.  Pay special attention to whether an attribute of a class should be contained in the class as an attribute or composed by the class as a separate (aggregated) class instance.  Think about why this would matter in your design.

You will be best if you try and think about this independently of any particular OO programming language that you know.  There are no restrictions in this exercise as to language limitations (read multiple inheritance).

You should create a number of UML class diagrams which detail your understanding of the requirements in the General Description of the Problem Domain below.  The class diagrams should show your interpretation of the classes you've defined and their static relationships with one another.

Deliverable:

A gzipped tarball of your static model (from your project directory down) as a Visual Paradigm project called yourloginid .practicum2.tgz.

As for detail, I do NOT expect a thoroughly detailed class diagram in the sense that one could immediately go and implement a system from your design.  So, no, I don't expect ALL constructors, accessors, modifiers, and argumens for EVERY method for EVERY class.

Having said that, you should make sure you have thought through the problem well enough so that you have all of the salient classes you will need and their supporting classes, and have defined the interface on those classes sufficiently well for a reader of your model to determine from the class diagram what resonsibilities are being handled by the class.  You should comment each class so that I understand the responsibilities of the class.  Certainly, you should show what methods are abstracted up in a hierarchy, what methods are non-generic (in derived classes).  I will want to see that you have engaged UML in the model, and will want to see where you have dependencies, generalization, association, aggregation, multiplicity assumptions, association classes, etc. etc. etc.  Adornments such as tagged values, strereotypes, constraints, qualifiers should be used to clarify your intent. 

In short, the overriding principle is that:

YOUR MODEL SHOULD BE INTELLECTUALLY RICH:  RICH in thought and RICH in UML detail.

Your approach should be to demonstrate that you have THOUGHT DEEPLY about the problem.  Your grading will be on how well you COMMUNICATE that deep thinking to me through your model.

I have posted example static models here.

Click here for a General Description of the Problem Domain