Class Diagram Draft
November 1, 2007
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).
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.
November 1, 2007 at 4:59 am
A few initial suggestions for review:
- The “Member” class should be renamed to “User”, assuming we are storing only account information such as username, password, email address, date joined, etc. This increases the portability of the code to other organizations. If we need a mechanism to keep track of deeper information regarding ACM membership, that should likely be handled in a different system and accessed via web service or RMI (remote method invocation). This prevents future consumers of being burdened with our specific business rules.
- The relationship between Title and Media should be more obvious. Perhaps change “Title” to “Media” and “Media” to “MediaInstance”. This also provides a more natural extension of the “Media” abstract class. ["Book" extends "Media"] makes more sense than ["Book" extends "Title"].
- The MediaTag class should reflect the class it is associated with. So if we stick with “Title”, we should change “MediaTag” to “TitleTag”. Personally, I think it might be more flexible in the long run to just go with “Tag”, allowing for the possibility of associating tags with Members at a later time to indicate their personal interests.
- “MemberAct” could be renamed to simply “Action”, allowing for shorter concrete class extensions such as “CheckoutAction”, “CheckinAction”, “ReservationAction”, “AddMediaAction”, and “RemoveMediaAction”. “MemberAct” also places a misleading bias on its relationship to the Member class, when it also has an equally-important association with the Media class.
- We might also want to add a “AddTitleTagAction” class, so we can track who tagged what (couldn’t hurt).