Class vs. Object
An individual class is shown on the diagram as a box with up to four sections:
- The first section shows the name of the class. Names should be nouns. Typically the first letter of every word in a name is capitalized.
- Attributes represent the state of the object or what the object knows.
- Operators represent the behavior of an object or what the object does.
- Responsibilities are optional. A Responsibility is a contract or an obligation of the class. They are normally only used in analysis and early in the design phase to describe what a class should do without describing how it should do it.
The + sign indicates that an attribute or operation is public or visible to all other objects or operations in the system.
The – sign indicates that an attribute or operation is private or hidden from any objects or operations other than those objects also of the current class.
The # sign indicates that an attribute or operation is protected or visible only to members of the same class or members that are specialization’s of (or derived from) that class.
Object diagrams have a very similar appearance to class diagrams (see next slide), but are more specific. It is very important to make sure the syntax rules for writing the names of classes and objects are followed. Otherwise, confusion is sure to result.
Object diagrams are useful when information about the dynamic relationships between classes must be captured. Dynamic relations are between instances (of classes).
If a particular person (Bob) rents a particular movie (Casablanca), there is a dynamic relationship between Bob:Person, and Casablanca: Movie. Compare to static relationships
Note that the object diagram is much more specific. Values are provided for data. The relationship is less abstract, because it refers to the relationship between two instances (here, ‘Joe’ and ‘Casablanca’), and not the theoretical relationship between classes.
The UML specification requires that object names be underlined. Objects do not need to be named, but if an object does not have a name, the name of its class must be preceded with a colon. This makes clear that the name represents a class and not an object. In the diagram above, “:Customer” could also be used. Class names are also not required; if the class name is not provided, there should not be a colon. In the diagram above, ‘Joe’ could also be used. Obviously, each object should have either a name or a class name.
Be careful when simplifying diagrams by removing names — ensure that you have not removed vital information. If ‘Joe’ could be an instance of any of a number of related classes, it may be important to show which class it is. The idea is to strike the right balance between a diagram that captures the needed information, and one that’s not so cluttered the eye cannot follow the concepts.