Application Class Diagram | UML 2 For Dummies

There comes a point in your project when you have to understand requirements imposed by your application. To gain that insight, we build an application class diagram for each use case. The application class diagram is simply a UML class diagram that shows the classes that work together to accomplish all the scenarios of a particular use case.

Remember A domain class diagram defines the requirements imposed on you by the user’s language. The application class diagram defines the requirements imposed on you by the very application that you’re building.

Tip If your users interact with a graphic user interface (GUI), you need classes that know how to paint the GUI in a way that offers a view of some domain classes. For example, if a user wants to see a policy object, you need a view class that extracts the data out of an instance of the policy class and shows that data in a GUI window—complete with text boxes, radio buttons, and drop-down lists.

If any use cases require your application to do things in a specific order, create a controller class. This class is responsible for remembering what the user has done and what comes next. For example, in the insurance scenario, when a user generates a policy, he or she must create the policy first—and then assign coverage to it, assign covered items, and indicate who owns the policy. When the user has done these tasks, all this information must be complete and correct before the policy goes to the underwriter for review. In this case, we create a policy manager class that controls the other objects at runtime, making sure that the use case works properly.

Other than a controller class and view classes, you may have to create the following application classes:

Boundary class: This is a class that hides the details of one part of a system from another part. We use a separate class that knows how to access the database as a boundary between our domain objects and the database.
Device class: A device class usually represents a physical device (such as a barcode scanner) or the software driver for a physical device. Working much like a boundary class, a device class isolates a physical device for our domain objects.
Surrogate class: We use surrogate classes to stand in for our use-case actors. Actors are those things outside our system that interact with the system. Surrogates are classes inside our system that stand in for the actor outside the system. If our application must store and track information about users (for example), we create surrogate classes inside our system to hold that data.

You may find that other developers use different terminology for these classes. Instead of using controller, they use control. Instead of the word boundary, they use the word view or interface. Instead of calling the diagram an application class diagram, they call it a robustness diagram. (“You say tomayto, I say tomahto. . . .’’) No wonder people get confused.

Warning Don’t try to give your domain classes all the knowledge of the following:

How to display themselves in a GUI window
How to display themselves over the Net in a Web browser
When to display different attribute values
How to store and retrieve data from a database

Let your domain classes know how to be themselves. Let other classes have the responsibility of showing your domain classes as pictures in a GUI or of handling their interactions with a database.