Yeah, it is a little implementationish. Probably because I’m going to be doing the implementing, so adding some extra stuff/thoughts into it “while I’m there” is a risk.

Thanks for taking the time to look at the diagram in more detail, and reply.

Edit/resubmit: I think the rule we need to use is “only if the URL changes, should the author resubmit.” I would encourage Brian (the Blogger persona) to add a review of an existing article when he edits it.

Link-last-checked. Cool idea. I put it in “surprise and delight”, but it’s on the stack.

login – I use, and would love to support openID user authentication. Will have to add that. Not sure what’s already been done with Rails to support it. openID allows exactly what you suggest.

Contact-rules: From a community standpoint, people may want to send private emails to each other. But they won’t want to share their email addresses publicly on the site. I think we should be able to facilitate sending emails opaquely from one user to another. Would likely be a minor extension to the support we need for Paul’s (the product manager persona) broadcast of articles to non-users by email. But if people anticipate getting spammed with emails from “non-qualified” other users, they may use a secondary email address (like spam@hotmail.com) and never see the “real” emails. Or even worse, not sign up. This was a design attempt to address an implicit requirement for community participation.

Rating of reviews – got it.

Thanks again!

TIA

I take your comment as a great suggestion, not a “form of documentation” critique! You’re making a suggestion about representation of the domain model – not description. I’ll have to check out Larman’s book, but I was generally trying to follow exactly that precept.

Example: Rating is a first class object, not just an attribute. The enumerations are another manifestation of this. I realize the blog-documentation approach makes it harder to consume (because I included the easily scannable attribute-placeholders).

With the diagram, I tried to show all of the relationships as concepts – including multiplicity and navigability intentionally. As a habit in previous OOA/OOD efforts, I started “double documenting” each relationship as an attribute name (userRatings is an example) to make the document easier to scan over time – reminding me that there is a relationship there.

Maybe Larman has a better approach to describing the concepts, I’ll have to check. Thanks again for the suggestion – and I will definitely turn up the volume on that as I move forward.

And thanks again for your sustained readership and multiple contributions to discussions basically since the beginning of the blog. I truly appreciate it.

How about a link-last-checked timestamp? Checking can be done automatically, I guess.

reviewTitle and reviewBody:
It should be possible to fill in the Title only (for short comments)

User metadata: Isn’t there a technology that relieves me of entering my data in dozends of sites?

Should user roles be private? No.

Is there a reason to have a distinction between reviewers and submitters? No.

Any other contact rules? I can’t see the point in having contact rules. Please explain.

Should people be able to “Rate” a review? Yes!

Threaded commenting? I think rating reviews is enough.

“Perhaps the most common mistake when creating a conceptual model is to represent something as an attribute when it should have been a concept.”

Larman offers a guideline:

“If we do not think of some concept X as a number or text in the real world, X is probably a concept, not an attribute.”

However:

“If in doubt, make it a separate concept.”

This information comes from Larman’s APPLYING UML AND PATTERNS.