To design the database backend for your app, your team will create an object-oriented class diagram of your app’s model classes—that is, a model class diagram.
Prerequisite: Each team member must complete the Model Class Diagram Activity before the team can begin work on the model class diagram.
🎦 Watch: Introduction to Data Modeling
Diagram Requirements
Use PlantUML. Your team must use PlantUML to create your UML class diagram.
One Diagram per Team. A single diagram capturing the team’s entire model must be shared by the whole team.
Everyone Contributes. All team members should work together to develop the model design for the team’s app.
Noun-Phrase Identification. Document a list of all the noun phrases your team identifies to inspire your class diagram. Be prepared to submit this list along with your class diagram.
Required Diagram Conventions. The following class diagram conventions must be followed:
Class Conventions. Each class must have:
An UpperCamelCase name (generally a singular noun phrase).
No id-type key attributes. Do not include any primary or foreign key attributes in your classes. These are relational database columns that can be inferred from the object-oriented class diagram. For example, certain foreign keys are implied by the modeling of object-oriented associations. It would be redundant to explicitly model these keys in the class diagram.
Class Attribute Conventions. Each class attribute must have:
A snake_case name (generally a noun phrase).
A valid Rails database-column type: string, text, integer, bigint, float, decimal, numeric, datetime, time, date, binary, blob, or boolean.
Association Conventions. Each association, regardless of type, must have:
Multiplicities on each end.
Role labels on each end with snake_case names that are singular noun phrases.
One-to-* Association Conventions. Each one-to-one and one-to-many association must have:
An association label “has” with the reading direction indicated (▲ ► ▼ ◄).
Many-to-Many Association Conventions. Each many-to-many association, must have:
An association class (to capture the required join class/table).
UML Class Diagrams Only! The diagram must be a UML class diagram. For example, entity-relationship diagrams (ERDs) are NOT acceptable.
Grading Rubric
High-Pass:
90% of diagram elements satisfy all the quality criteria.
The diagram is deemed complete (no noticeable omissions).
Low-Pass:
70% of diagram elements satisfy all the quality criteria.
Minor completeness deficiency (up to 4 key classes and/or associations omitted).
Fail: Fails to meet requirements for Low-Pass.
Quality Criteria
Good Design. Well-made design decisions, for example:
Free of redundancy.
Correct Notation. Correct use of UML class diagram notation, for example:
No id or obvious primary/secondary key attributes.
Only primitive type attributes. No array/collection attributes.
Follows Conventions. No violations of the required diagram conventions, for example:
No missing/incorrect attribute names/types.
No missing/incorrect association labels/roles/multiplicities.
PlantUML. Diagram made using PlantUML.
Layout. Readable layout of diagram elements, for example:
Free of overlapping or ill-positioned labels.
Free of lines/edges that are overly winding and/or difficult to trace.
Up to Date. Up to date with respect to the code, specifically:
All model class design elements (e.g., classes, attributes, associations) present in the code are depicted in the diagram. (Note that it is OK for there to be design elements in the diagram that have not yet been implemented in the code.)