Classes

During analysis objects were defined that helped in the analysis. These objects were used to aid in diagramming the requirements of the system. A class is a description of a group of objects with common properties and behavior. A class is defined as a template to create an object. Every object is an instance of a class. No object can be defined by more than one class. A class can instantiate multiple objects. For example, the Video class can be defined with the following properties:

  • Attributes - title, UPC, count, status
  • Operations - retrieve title, retrieve count, modify status

The videos Gladiator and Halloween are both objects of the Video class. Each video object would have values for title and count and would support the operations defined by the Video class.

Classes should be designed with a specific purpose. A class designed with more than one theme can be difficult to implement and maintain. For example, the video class should support basic information about a video. If we want to maintain history about the video such as who rented the video, the VideoHistory class should be created. Classes should also be named so as to make sense for the system being designed. The class documentation needs to be as clear as possible. Acronyms can be used as long as they are understood by the people using the system and that there is no chance of being misunderstood. A class describing videos should be named Video and not V or MovieThing, etc.

The UML models a class as a rectangle with three sections. The top section is the identity or name of the class. The middle section describes all of the attributes of the class. The bottom section contains the operations or methods of the class.

 

 

Defining classes can be one of the most challenging aspects of building a system. How are the classes defined and what are the attributes and methods that those classes support. Most methodologists will agree that discovering classes can be hard. Here is where the work product from the analysis will really pay-off. By examining the analysis diagrams and looking at the entities that were discovered, you can begin to describe the classes of a system. The classes can be derived by looking at the sequence and activity diagrams built in the analysis phase. These diagrams will help in discovering the types of objects that are needed. From those objects, the template classes can be defined.

The UML defines three types of classes for a system. These types following the model-view-controller aspect of design. These types are: boundary, control, and entity.