Class Diagram Draft

Here’s a draft diagram of the classes we discussed. I modeled it up using Rational Software Modeler (I know, I know, it’s not open source).

Class Diagram (Draft 1)

Here are some generic descriptions of the classes, as well.

Member
A user of the webapp. In this case, “Member” would be a member of the ACM.

Title
This abstract class stores all the metadata for a piece of media. Includes things like author, title (of book, DVD, etc), date published, publisher, etc. There may be a case where you would have multiple instances of the same book or DVD, but there would only be one Title object to house the metadata. This class is also abstract to allow for extension. This gives us the flexibility to support many media types, such as books, DVDs, term papers, software installation discs, etc. Each of these media types would be concrete classes, extending the Title abstract class, with their own unique attributes.

Book
This is the only concrete extension to the Title class which we’ve defined so far. This class may include unique attributes such as ISBN number, number of pages, etc.

Media
The physical instance of a title. If the library has three copies of the book “Groovy in Action”, there will be three media objects which represent each copy of the Title.

TitleReview
This class stores text-based content provided by a member as they review a title. This might also be associated with a CheckInMemberAct, in which the Member is prompted to review a book when she checks it back into the library.

MediaTag
This class houses a list of web 2.0-style “tags” (or keywords) that members assign to various Titles. For instance, the book “Groovy In Action” might have “java”, “scripting”, “programming” and “groovy” tags associated with it.

MemberAct
This abstract class defines an action that a Member has performed against a Media item. Since this class is abstract, it cannot be instantiated on its own. Instead, it is instantiated by a specific type of action defined by the concrete classes which extend MemberAct

CheckoutMemberAct
This class defines instances in which a Member has checked out a particular Media item.

CheckinMemberAct
This class defines instances in which a Member has checked in a particular Media item (presumably after having checked it out). This action might be linked directly to its CheckoutMemberAct counterpart.

ReserveMemberAct
This class defines instances in which a Member has requested a particular Media item for checkout sometime in the future. This should probably contain two fields for the beginning and end date.

AddMediaMemberAct
This class defines instances in which a Member has added a new piece of Media to the library for the first time (presumably by donation).

RemoveMediaMemberAct
This class defines instances in which a Member has removed a Media item from the library (presumably if it was lost or stolen).

There was some also some discussion of user roles (such as admin), but this class diagram does not seem to reflect those feaures.

Next steps will be to finalize the class hierarchy and start identifying the attributes.  I’ll start the ball rolling in the comments section very shortly.

Early “Use Cases” and Domain Classes

We had an extremely productive session tonight (more on that later), but I wanted to post up the notes from the whiteboard right away. For those of you who were unable to attend, we decided to go with the ACM Library web app. We decided on some preliminary use case segments and domain model classes. I plan to post some UML very soon. For now, here’s a mind map of what we wrote on the board…

Whiteboard Notes