8.1 Identify object classes

1. List all candidate object classes found in the written description problem. This can be done by writing down all the nouns of the problem description.
2. Now discard all the unnecessary and incorrect classes according to the following criteria:
   Redundant classes: if two classes express the same information, the most descriptive name should be kept;
   Irrelevant classes: if a class has little or nothing to do with the problem, it should be eliminated;
   Vague classes: non-specific classes with ill-defined boundaries should be eliminated;
   Attributes: names that primarily describe individual objects should be restated as attributes
   Operations: if a name describes an operation that is applied to objects and not manipulated in its own right, then it is not a class
   Roles: the name of a class should reflect its intrinsic nature and not a role that it plays in an association
   Implementation constructs: constructs extraneous to the real world should be eliminated from the analysis model

If one of the classes in the association has been eliminated, then the association must be eliminated or restated in terms of other classes.
Eliminate any associations that are outside the problem domain or deal with implementation contructs.
An association should describe a structural property of the application domain. Eliminate associations that describe a transient event.
Try to decompose associations between three or more classes in binary associations, or phrase them as qualified associations. If a term in a ternary association is purely descriptive and has no features of its own, then the term is a link attribute on a binary association.
Omit associations that can be defined in terms of other associations because they are redundant. Also omit associations defined by conditions on object attributes.

Name the associations correctly: don't say how or why a situation came about, say what it is. (names of associations should be structural, not events or actions)
Add role names where appropriate. If there is only one association between a pair of classes, and the name of a class adequately describes its role, you may omit role names.
Specify multiplicity, but don't put too much effort into getting it right, as multiplicity often changes during analysis. Challenge multiplicity values of "one".
Add qualifiers where necessary, to distingsuish the objects on the many side of an association.
Add any missing associations that are discovered

8.4 Identify attributes of objects and links

If the independent existence of an entity is important, rather than just its value, then it is an object;
If the value of an attribute depends on a particular context, then consider restating the attribute as a qualifier;
Identifiers must exist in the problem-domain, implementation-identifiers should not be listed as attributes.
If a property depends on the presence of a link, then the property is an attribute of the link and not of a related object
If an attribute describes the internal state of an object that is invisible outside the object, then eliminate it;
Omit minor attributes which are unlikely to affect most operations
An attribute that seems completely different from and unrelated to all other attributes may indicate a class that should be split into two distinct classes

1. Bottom up: by generalizing common aspects of existing classes into a superclass.
   You can discover inheritance from the bottom up by searching for classes with similar attributes, associations, or operations. For each generalization, define a superclass to share common features. Some attributes or even classes may have to be redefined slightly to fit in properly (this is acceptable, but don't push too hard if it doesn't fit, you may have the wrong generalization). Some generalizations will suggest themselves based on an existing taxonomy in the real world; use existing concepts whenever possible.
2. Top down: by refining existing classes into specialized subclasses. Top-down specializations are often apparent from the application domain. Look for noun phrases composed of various adjectives on the class name (e.g. fixed menu, pop-up menu, sliding-menu). Avoid excessive refinement. If proposed specializations are incompatible with an existing class, the existing class may be improperly formulated.

Where a unique value is expected, is there a path yielding a unique result?
For multiplicity "many", is there a way to pick out unique values when needed?
Think of questions you might want to ask, are their useful questions which cannot be answered? They indicate missing information.

An operation with no target class: add the missing target class
Duplicate associations with the same name and purpose: generalize to create the missing superclass that unites them.

Redundant information in the associations: remove associations that do not add new information or mark them as derived.
Lack of operations that traverse an association (you can only remove associations because of this reason after you specified the operations)

8.8 Group classes in modules