The Requirements Model defines a set of analysis classes. Each describes some element of the problem domain, focus on an aspect of the problem that is visible. The level of abstraction of the analysis class is comparatively high. The set of design classes refine analysis classes and providing design detail that enables classes to execute a software infrastructure that supports business solutions.
There are 5 different types of design classes that represent a different layer of design architecture that can be developed:
- User interface classes define abstraction that mandatory for human-computer interaction [HCI]. In cases, HCI occurs within the context of metaphor, and design classes for the interface may be visible representations of elements of metaphor.
- Business domain classes are often refinements of analysis classes defined earlier. The class identifies the attributes that are required to implement some elements of the business domain.
- Process classes implement lower-level business Preoccupation need to manage business domain classes.
- Persistent classes represent the data stores that will persist beyond the execution of software.
- System classes implement software management and control function that permits the system to operate and convey within its computing environment and with the outside world
As architecture forms, the level of abstraction is reduced as each analysis class transformed into two design representations. That is, analysis classes represent data objects using the jargon of the business domain. Design classes present notably more technical detail as a guide for implementation.
Arlow and Neustadt suggest each design class reviewed to ensure that is “well-formed”. They define four characteristics of a well-formed design class:
- Complete and sufficient: A design class should be complete encapsulation of all attributes and method that can be reasonably be expected to exist for class. For example, the class scene defined for video editing software is complete only if it contains all attributes and methods that can agreeably be associated with the creation of a video scene. Sufficiently ensure that design class contains only those methods that are sufficient to achieve the intent of class, no more and no less.
- Primitiveness: Method associate with design class should be focused on accomplishing one service for class. Once service implemented with the method, the class should not provide another way to accomplish the same thing. For example, the class Video Clip for video editing software might have attributes start point and end point to specify start and endpoint of clip.
- High Cohesion:/strong> A cohesion design class has a small, concentrated set of authority and single-mindedly applies attributes and methods to implement those responsibilities. For example, the class video clip might contain set of method for editing the video clip. As long as each method focus solely on attributes associated with video clip, cohesion is maintained.
- Low Coupling: Within the design model, it is necessary for design classes to get together with one another. However, get together should be kept to an acceptable minimum. If the design model is highly coupled, the system is difficult to implement to test and to maintain over time, In general, design classes within subsystem should have only limited knowledge of other classes. This restriction called the Law of Demeter, suggest that method should only send message to methods in neighboring classes.