Some things are easy to identify as a class. For example, if you look around the room, you can find lots of physical objects which can be made into classes.
However, in a software environment, this may not always be as easy to identify. So look at the following questions to start to identify what might be a class:
- External Entities
- Things (reports, displays, etc)
- Roles (this could be a hierarchy of classes such as user, administrator, etc)
- Organizational Units
- Places
- Structures
The book offers six suggestions to help determine if something should be a class:
- Retained information. The potential class will be useful during analysis only if information about it must be remembered so that the system can function.
- Needed services. The potential class must have a set of identifiable operations that can change the value of its attributes in some way.
- Multiple attributes. During requirement analysis, the focus should be on “major” information; a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity.
- Common attributes. A set of attributes can be defined for the potential class and these attributes apply to all instances of the class.
- Common operations. A set of operations can be defined for the potential class and these operations apply to all instances of the class.
- Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements mode
Identifying Classes was originally found on Access 2 Learn
