![]() | MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
The customers of a software engineering project will not think of their work in terms of classes; it is the job of the developers to determine suitable classes with which to structure their work. This job requires experience and intuition, and invariably improves with practice. Here are a few general hints:
The names of classes are usually nouns. A good place to start is to take a written description of the system and select all the nouns. You will undoubtedly have to remove some classes and add others, but this method provides a place to start.
It is better to have too many classes to begin with, rather than too few. You can always remove some if you find that they are redundant
Classes should, as far as possible, correspond to entities that the clients would understand. Computer terms rarely make good class names. You will find that as development progresses you will need to add classes to represent implementation factors, but you should not start off with these. Classes should make sense to non-technical people, at least in the early stages.
If something has sub-types, or it is a type of something else, it is probably a class
If something is important, but does not appear to be a class, it might be an attribute of some other class
As you add detail to a design you will discover new classes, and you can add these to the model. You will also often find that you can simplify a design by adding classes, as will be shown.
At all stages of development you should challenge your class model and be prepared to modify it if necessary. It is important to remember that iterative, incremental and evolutionary methods will have you update not only requirements, but the software design (and hence class model) for multiple development iterations. This is especially important for agile process methods.