Control classes provide coordinating behavior in the system. The system can perform some use cases without control classes (just using entity and boundary classes) - particularly use cases that involve only the simple manipulation of stored information. More complex use cases generally require one or more control classes to coordinate the behavior of other objects in the system. Examples of control classes include transaction managers, resource coordinators and error handlers.
Control classes effectively de-couple boundary and entity objects from one another, making the system more tolerant of changes in the system boundary. They also de-couple the use-case specific behavior from the entity objects, making them more reusable across use cases and systems.
Control classes provide behavior that:
Is surroundings-independent (does not change when the surroundings change).
Defines control logic (order between events) and transactions within a use case. Changes little if the internal structure or behavior of the entity classes changes.
Uses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classes.
Is not performed in the same way every time it is activated (flow of events features several states).
Entity objects represent the key concepts of the system being developed. Entity classes provide another point of view from which to understand the system because they show the logical data structure, which can help you understand what the system is supposed to offer its users.
A frequent source of inspiration for entity classes are the Glossary (developed during requirements) and a business-domain model (developed during business modeling, if business modeling has been performed).
Sometimes there is a need to model information about an actor within the system. This is not the same as modeling the actor (actors are external, by definition). Thus, a naming convention should be employed for naming the system classes that hold actor information (e.g., class StudentActor for the actor and Student for the entity class, or Student for the actor and StudentInfo, for the entity class).
A boundary class intermediates the interface to something outside the system. Boundary class insulate the system from changes in the surroundings (changes in interfaces to other systems, changes in user requirements, etc.), keeping these changes from affecting the rest of the system.
A system may have several types of boundary classes:
User interface classes - classes which intermediate communication with human users of the system.
System interface classes - classes which intermediate communication with other systems.
Device interface classes - classes which provide the interface to devices which detect external events.
Boundary classes may be used as “holding places” for GUI classes. The objective is not to do GUI design in analysis, but to isolate all environment-dependent behavior. The expansion, refinement and replacement of these boundary classes with actual user interface classes (probably derived from purchased UI libraries) is a very important activity of Class Design, and will be discussed in the Class Design module.