Object-oriented methodologies work to discover classes, attributes, methods, and relationships between classes. Because programming occurs at the class level, defining classes is one of the most important object-oriented analysis tasks. Class diagrams show the static features of the system and do not represent any particular processing. A class diagram also shows the nature of the relationships between classes.
Classes are represented by a rectangle on a class diagram. In the simplest format, the rectangle may include only the class name, but may also include the attributes and methods. Attributes are what the class knows about characteristics of the objects, and methods (also called operations) are what the class knows about how to do things. Methods are small sections of code that work with the attributes.
Figure below illustrates a class diagram for course offerings. Notice that the name is centered at the top of the class, usually in boldface type. The area directly below the name shows the attributes, and the bottom portion lists the methods. The class diagram shows data storage requirements as well as processing requirements. Later in the chapter we will discuss the meaning of the diamond symbols shown in this figure.
The attributes (or properties) are usually designated as private, or only available in the object. This is represented on a class diagram by a minus sign in front of the attribute name. Attributes may also be protected, indicated with a pound symbol (#). These attributes are hidden from all classes except immediate subclasses. Under rare circumstances, an attribute is public, meaning that it is visible to other objects outside its class. Making attributes private means that the attributes are only available to outside objects through the class methods, a technique called encapsulation, or information hiding.
A class diagram may show just the class name; or the class name and attributes; or the class name, attributes, and methods. Showing only the class name is useful when the diagram is very complex and includes many classes. If the diagram is simpler, attributes and methods may be included. When attributes are included, there are three ways to show the attribute information. The simplest is to include only the attribute name, which takes the least amount of space.
The type of data (such as string, double, integer, or date) may be included on the class diagram. The most complete descriptions would include an equal sign () after the type of data followed by the initial value for the attribute. Figure below illustrates class attributes. If the attribute must take on one of a finite number of values, such as a student type with values of F for full-time, P for part-time, and N for non-matriculating, these may be included in curly brackets separated by commas: studentType:char{F,P,N}.
Information hiding means that objects’ methods must be available to other classes, so methods are often public, meaning that they may be invoked from other classes. On a class diagram, public messages (and any public attributes) are shown with a plus sign () in front of them. Methods also have parentheses after them, indicating that data may be passed as parameters along with the message. The message parameters, as well as the type of data, may be included on the class diagram.
There are two types of methods: standard and custom. Standard methods are basic things that all classes of objects know how to do, such as create a new object instance. Custom methods are designed for a specific class.
Method Overloading
Method overloading refers to including the same method (or operation) several times in a class. The method signature includes the method name and the parameters included with the method. The same method may be defined more than once in a given class, as long as the parameters sent as part of the message are different; that is, there must be a different message signature. There may be a different number of parameters, or the parameters might be a different type, such as a number in one method and a string in another method. An example of method overloading may be found in the use of a plus sign in many programming languages. If the attributes on either side of the plus sign are numbers, the two numbers are added. If the attributes are strings of characters, the strings are concatenated to form one long string.
In a bank deposit example, a deposit slip could contain just the amount of the deposit, in which case the bank would deposit the entire amount, or it could contain the deposit amount and the amount of cash to be returned. Both situations would use a deposit check method, but the parameters (one situation would also request the amount of cash to be returned) would be different.
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. The analyst needs to determine which attributes to include in the classes. Each object has many attributes, but the 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 attributes 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 attributes 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 way for users to interact with the system. Human interfaces should be prototyped (as described in Chapter “Agile Modeling and Prototyping“), 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 achieve classes that are reusable, 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 interface, 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 control 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 “Analyzing Systems using Data Dictionaries“). 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 “Process Specifications and Structured Decisions“.
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 class, from the parameters passed on the message sent to the class, or as a result of a calculation performed by the method of the class. The method logic and parameters must be examined to ensure that the method logic has all the information required to complete its work. Horizontal balancing is further described in Chapter “Using Data Flow Diagrams“.
