Page 304 -

chaPter 10 • object-oriented systems analysis and design Using Uml 271

Types of Classes
Classes fall into four categories: entity, interface, abstract, and control. These categories are
explained below.
Entity ClassEs. Entity classes represent real-world items, such as people, things, and so on.
Entity classes are the entities represented on an entity-relationship diagram. CASE tools such as
Visible Analyst will allow you to create a UML entity class from an entity on an E-R diagram.
An analyst needs to determine which attributes to include in the classes. Each object has
many attributes, but a class should include only those that are used by the organization. For
example, when creating an entity class for a student at a college, you would need to know attri-
butes that identify the student, such as home and campus address, as well as grade point average,
total credits, and so on. If you were keeping track of the same student for an online clothing
store, you would have to know basic identifying information, as well as other descriptive attri-
butes such as measurements or color preferences.
Boundary, or intErfaCE, ClassEs. Boundary, or interface, classes provide a means for users
to work with the system. There are two broad categories of interface classes: human and system.
A human interface may be a display, window, Web form, dialog box, menu, list box, or
other display control. It may also be a touch-tone telephone, bar code, or other ways for users to
interact with the system. Human interfaces should be prototyped (as described in Chapter 6), and
often a storyboard is used to model the sequence of interactions.
System interfaces involve sending data to or receiving data from other systems. This may
include databases in the organization. If data are sent to an external organization, they are often
in the form of XML files or other well-published interfaces with clearly defined messages and
protocols. External interfaces are the least stable, because there is often little or no control over
an external partner who may alter the format of the message or data.
XML helps to provide standardization because an external partner may add new elements
to the XML document, but a corporation transforming the data to a format that may be used to
append to an internal database may simply choose to ignore the additional elements without any
problems.
The attributes of these classes are those found on the display or report. The methods are
those required to work with the display, or to produce the report.
aBstraCt ClassEs. Abstract classes are classes that cannot be directly instantiated. Abstract
classes are those that are linked to concrete classes in a generalization/specialization (gen/spec)
relationship. The name of an abstract class is usually denoted in italics.

Control ClassEs. Control, or active, classes are used to control the flow of activities, and they
act as a coordinator when implementing classes. To create reusable classes, a class diagram may
include many small control classes. Control classes are often derived during system design.
Often a new control class will be created just to make another class reusable. An example
would be the logon process. There might be one control class that handles the logon user inter-
face, containing the logic to check the user ID and password. The problem that arises is that the
logon control class is designed for a specific logon display. By creating a logon control class that
handles just the unique logon display, the data may be passed to a more general validation con-
trol class, which performs a check on user IDs and passwords received from many other control
classes receiving messages from specific user interfaces. This increases reusability and isolates
the logon verification methods from the user interface handling methods.
The rules for creating sequence diagrams are that all interface classes must be connected to a
control class. Similarly, all entity classes must be connected to a control class. Interface classes,
unlike the other two, are never connected directly to entity classes.

Defining Messages and Methods
Each message may be defined using a notation similar to that described for the data dictionary
(as shown in Chapter 8). The definition would include a list of the parameters passed with the
message as well as the elements contained in the return message. The methods may have logic
defined using structured English, a decision table, or a decision tree, as depicted in Chapter 9.
The analyst can use the techniques of horizontal balancing with any class method. All the
data returned from an entity class must be obtained either from the attributes stored in the entity