CS 4448 - Fall 1998 - Talk 7.1
Object-Oriented Programming and Design
Talk 7.1
by
Jake Burhenn
QUOIN Analysis & Design Guidelines
Heuristics for Improved Object Models
by
J. Bradford Kain
- Introduction.
This article contains a series of guidelines for improved analysis using object models.
- Object Types
- Identify several instances of each object type
During the design of object-oriented software different candidate objects are
suggested. In order to decide whether to keep or discard these candidate objects, one should create example instances of these candidates. This gives more information about the design and what objects are needed.
- Evaluate instances with respect to the characteristics of an object type
Identifying something is an instance of an object type is not enough, it is too subjective. One must also ascribe values for the attributes of the object type to be sure that something is an instance.
- Use singular names for object types
Use names that identify the unifying characteristic of the instances.
- Use the object type name preferred by the domain expert
The domain expert is the person with knowledge about the project as a whole, so his choice for the names of objects is probably best.
- Identify the characteristics of an object type immediately
Once an object is decided upon, immediately fill in the attributes. This allows for more objective understanding of how the object functions.
- Attributes
- Do not specify a unique identifier for each object type
If you want to create a relational database with objects, you need to specify a unique identifier for each instance. However, it is not necessary to specify this during the creation of the object model.
- Do not automatically assume simple characteristics are attributes
If a characteristic of an object type has been isolated, first you want to see if it can be represented as a distinct object. If other objects can make use of this new object, it is probably the best solution. Otherwise you can go ahead and include it in the original object type.
- Operations
- Each operation should access or modify the state of the objects for the target object type
Operations should only affect instances of the object type on which it is defined. Behavior that affects more than one object type must be broken up into steps, then these steps should be defined as operations of the single object type affected.
- Specialization
- Test specialization relationships
Decide if specialization exists by seeing if all instances of the subtype are instances of the supertype and if all characteristics of the supertype apply to these instances.
- Avoid excessive use of specialization
Overuse of specialization is a common mistake, so be sure a specialization relationship exists and is necessary before creating objects.
- Consider replacing specialization with an attribute
In practice any specialization can be replaced with an attribute. In the case that subtypes are merely classifications of the supertype, this is probably the way to go.
- Consider replacing specialization with role types
When a role for an object type is discovered, the intuitive approach is to use specialization. However, this can lead to difficult implementation as when an object can have changing or multiple roles, so a better way is to create a relationship with different role types.
- Relationships
- Cardinality constraints specify important semantics
The constraints on how one object can map to another object through a relationship, can give important information about the problem.
- Test composition relationships
Check to make sure composition relationships are valid by making sure that all instances of the part type are included in the object type and the characteristics of the object type apply to the part type.
- Use invariant characteristics to specify dependence
Invariant characteristics can not be changed, therefore they can be used to specify that an instance of an object is dependent on that value for the characteristic.
- Conclusion
These are some of the things to be thinking about when designing and analyzing an object model.
Copyright © University of Colorado. All rights reserved.
Revised: October 16, 1998