Peer Review of Object-Oriented Database Design

For this activity, your job is “grade” another team’s draft of their database design—a UML class diagram of their Rails model classes. Address each and every one of the following criteria. For any issues you find, write a comment explaining the issue.

Use of the Class Diagram Notation and Following Naming Conventions

Inspect each of the individual elements of the design (i.e., classes, attributes, associations, and generalization relationships). For each one, check that it follows the relevant criteria below. Make note of any issues you discover.

• Classes
  • Class name follows the naming convention (upper-camelcase).
• Attributes
  • Attribute name is present and follows the naming convention (snakecase).
  • Attribute type present and valid.
  • No attribute that is meant to reference a class object. Such a reference should actually be modeled as an association.
  • No primary keys modeled. That is, no id attribute modeled (unless it is actually a thing in the problem domain).
  • No foreign keys modeled.
• Associations
  • Association name is present and follows the naming convention (i.e., named “has” with an arrow in the appropriate reading direction).
  • Association end labels are present and follow the naming convention (snakecase).
  • Association multiplicities present and correct.
• Generalization relationships
  • Generalization is denoted correctly (triangle-arrow with no labels and no multiplicities).
  • Generalization follows the Is-A Rule.
  • Superclass attributes aren’t redundantly duplicated in the subclass.
• General issues
  • Words are spelled correctly and correct grammar is used.
  • Names of elements are well chosen for their clarity and conciseness.

Quality of the Design

Considering the design as a whole, do you seen any issues with its quality? Does it seem like anything is missing? Were the design decisions well thought out? Be sure to offer suggestions for how to go about addressing any issues you note.

• Completeness
  • No missing elements (i.e., classes, attributes, etc.). You may not always know for certain if an element was supposed to be present, but you should mention any omission that you deem to be even somewhat likely.
  • Database can store all the data necessary for the app to perform its functions. A common pitfall in designing the model is to fail to account for certain data that would clearly be needed in order for the app to work properly.
• Quality of design decisions
  • Structure of data (i.e., choice of classes, attributes, etc.) makes sense.
  • Design effectively adheres to the Single Responsibility Principle.
  • Design effectively adheres to the DRY (Don’t Repeat Yourself) Principle.