| Error # | Explanation |
| 1 |
Chose Scale as an object: The Scale is a physical entity that
is involved in a process of the system, but it does not have
any interesting identity by itself. Typically, if for any part of the
system's behavior one could remove the object half-way through some
process and replace it with a different one, the object should not be
part of the data model.
|
| 2 |
Non-static associations: Many people received this comment; it
indicates that your "association" relates two objects together in a
very transient way, instead of the more permanent, static, long-lived
way that UML Class Diagrams call for. Example: In an audio component
store, an inventory database might contain a Stereo
has Speaker assocation. This is a good choice because
various stereos were sold to customers with different speakers, and
once sold the speakers have a long-lived relationship to the stereo
they were sold with. A Player plays CD
association is probably a poor choice for the inventory database,
since that information isn't important to the store owner, nor does a
stereo play just one CD or group of CDs in its lifetime.
|
| 3 |
Too few properties/attributes: Your object model didn't really
have enough detail in its attributes, given the objects you chose.
|
| 4 |
Irrelevant objects: You chose some objects that weren't really
relevant to the way the system worked, i.e. customer's shoes, door,
floor, ceiling, etc.
|
| 5 |
ID fields not necessary: The ID fields should only appear in a
particular implementation of an object model in a particular
application domain (SQL). They should not show up in an analysis of
the system.
|
| 6 |
Not enough description of roles and attributes: Your attributes
and the relationships that your objects had to one another were vague
or unclear, thus requireing more description than you provided.
|
| 7 |
Use inheretance: Even though we haven't discussed it, the
relationship you are trying to show here would be best represented by
an inherets from edge.
|
| 8 |
Concocted detail: The detail in your diagram and object model
was not actually in the narrative provided. Please see previous
course comments about inventing detail.
|
| 9 |
Missing defense: You were asked to describe why you
chose your objects, but no such justification appeared in your work.
|
| 10 |
Vague association: Your association was either poorly named or
required more description in order to comprehend.
|
| 11 |
Association names have wrong form: Association z
between classes X and Y should be English-readable
as "X z Y". Example: Good: Pot contains Flower
Poor: House people live at Address.
|
| 12 |
Attributes must be primitives: You may have listed an attribute
that is more complicated than a simple scalar value (string, number,
boolean, etc.) All complex data structures must be represented as
associated classes, not attributes.
|
| 13 |
Not a class: You identified a class that isn't really an
entity, but a behavior, process, or attribute. Processes should be
represented as use cases or in sequence diagrams, not in Class
diagrams.
|
| 14 |
Associations must be named: You omitted one or more names for
your associations, but associations should have names.
|
| 15 |
Not valid UML: You diagram contains one or more symbols that
are not valid UML Class Diagram elements.
|