Along with design sketches and requirements, as part of the concurrent design and requirements development for our agile project, we have created a UML class diagram representing the domain. This iterative process allows us to incorporate the benefits of each perspective rapidly with the others in our race to prototype a working site.
This article reviews the domain model.
UML Class Diagram Background
Scott Ambler has an excellent article explaining how to use and read UML 2.0 Class Diagrams – also called static diagrams or static models. This article does not have the typical “explain how to read it” introduction, please bear with me, or refer to Scott Ambler’s excellent tutorial as background for this. [Note: Ambler will have a lot of articles submitted to the ratings site – he does lots of great stuff!]
Ratings Project UML Class Diagram
The goal of this diagram is to capture / describe our understanding of the space – an object oriented analysis step. This diagram represents a business-perspective on the space, not an implementation-perspective. The implementation will look very similar, and does crop up a little in the naming of attributes. In “true agile fashion” we are trying to use the same document to represent the OOA as well as OOD artifacts.
This is the 20070424 version of the model. It will evolve. If you see any glaring holes or errors, please mention them in the discussion below this article.
[Update 20070427. Here’s the next version of the domain model]
Ratings Project Domain Entities
- articleScore. Each article will have a score that represents the collective perception of the quality of the article.
- articleReviews. A list of all reviews / commentary on the article.
- articleSubmitter. The user who submitted the article.
- articleTimestamp. When the article was submitted.
- articleRatings. [Private]. The individual ratings of the article, used to calculate the score.
- articleStatus. [Private]. An article can be public, possibly private, or removed (no longer visible to users, but still in the database to prevent its re-appearance).
- userRatings. All of the ratings submitted by the user.
- userArticles. All of the articles submitted by the user.
- userAdmiredUsers. Possibly have a list of users who you admire. Keeping this as a placeholder.
- userFans. Possibly have a list of all users who admire you. Placeholder.
- userRole. [Private?] A user can be an admin, can submit articles, and can review articles. Most likely, anyone who can review can submit. An admin can do both, but also has the ability to “clean house” in the system.
- userContactRule. [Private?] A user may allow other users to contact her. The site may provide an abstraction/email interface that allows contact without revealing email addresses. And people may want to restrict who can contact them based on the fan-admired network, or allow any user to contact them. Another placeholder for future possibilities.
- ratingArticle. The article being rated.
- ratingUser. The user doing the rating.
- ratingValue. The actual rating value assigned to the article by the user.
- ratingTimestamp. When the rating was created.
- reviewArticle. The article being reviewed.
- reviewUser. The user doing the reviewing.
- reviewTimestamp. When the review was created.
- reviewTitle. Title of the review (e.g. “Best. Article. Ever.”)
- reviewBody. The content of the review. Possibly “safe” html, analogous to comment field limitations on blogs.
Thoughts And Questions
- User metadata (name, loginID, pwd, email, timestamp, etc) is missing from the domain model. Pwd will need to be encrypted in the database [design note: probably SHA1 vs. MD5 – review details and options to determine].
- Should user roles be private?
- Is there a reason to have a distinction between reviewers and submitters? What would be the reason that someone would be able to do one, but not the other?
- Any contact rules other than “Only people I admire”, “People I admire or who admire me”, “All registered users”, and “No One?”
- ratingValue – last night, I believe I convinced myself not to do it this way. Will cover in more detail in the next article.
- Should people be able to “Rate” a review? Think of Amazon’s “Was this review helpfull?” feature. Over time, the feedback that people give to reviewers could be used to create a notion of credibility, or be used to determine similarity of opinion between users.
- What about threaded commenting? Essentially reviews of reviews – not just reviews of articles.
Share your thoughts and feedback below. And thanks in advance.