BUS 444: chapter 6 - Object Modeling

Terms in this set (19)

The Unified Modeling Language (UML) is a widely used method of visualizing and documenting an information system. In this chapter, UML is used to develop object models.


In chapter 5, DFDs were created that treated data and processes separately. An object, however, includes data and the processes that affect data.

e.g., a customer object has a name, an address, an account number and a current balance. Customer objects also can perform specific tasks, such as placing an order, paying a bill and changing their address.


An object has certain attributes, which are characteristics that describe the object; e.g., a car has attributes such as make, model and color.

An object also has methods, which are tasks or functions that the object performs when it receives a message, or command, to do so; e.g., a car performs a method called OPERATE WIPERS when it is sent a message with the wiper control, and it can APPLY BRAKES when it is sent a message by pressing the brake pedal.


A class is a group of similar objects; e.g., Ford Fiestas belong to a class called CAR.

An instance is a specific member of a class; e.g., a Toyota Camry is an instance of the CAR class. At an auto dealership, many instances of the CAR class may be observed: the TRUCK class, the MINIVAN class, and the SPORT UTILITY VEHICLE class, among others.

Although the term "object" usually refers to a particular instance, systems analysts sometimes use the term to refer to a class of objects. Usually, the meaning is understood from the context and the way the term is used.
A message is a command that tells an object to perform a certain method.

e.g., the message PICK UP TOYS directs the CHILD class to perform all the necessary steps to pick up the toys. The CHILD class understands the message and executes the method.


The same message to two different objects can produce different results. The concept that a message gives different meanings to different objects is called polymorphism.

e.g., in Figure 6-5 (pg. 182), the message GOOD NIGHTS signals the PARENT object to read a bedtime story, but the same message to the CHILD object signals it to get ready for bed. If the family also had a DOG object, the same message would tell the dog to sleep.


An object can be viewed as a black box, because a message to the object triggers changes within the object without specifying how the changes must be carried out.

A gas pump is an example of a black box. When the economy grade is selected at a pump, it is not necessary to think about how the pump determines the correct price and selects the right fuel, as long as it does so properly.

The black box concept is an example of encapsulation, which means that all data and methods are self-contained.

A black box does not want or need outside interference. By limiting access to internal processes, an object prevents its internal code from being altered by another object or process.

Encapsulation allows objects to be used as modular components anywhere in the system, because objects send and receive messages but do not alter the internal methods of other objects.


Object-oriented designs typically are implemented with O-O programming languages.

The major advantages of O-O designs are that systems analysts can save time and avoid errors by using modular objects, and programmers can translate the designs into code, working with reusable program modules that have been tested and verified.

e.g., in Figure 6-6 (pg. 183), an INSTRUCTOR object sends an ENTER GRADE message to an instance of the STUDENT RECORD class. Notice that the INSTRUCTOR object and STUDENT RECORD class could be reused, with minor modifications, in other school information systems where many of the attributes and methods would be similar.
A use case represents the steps in a specific business function or process. An external entity, called an actor, initiates a use case by requesting the system to perform a function or process.

e.g., in a medical office system, a PATIENT (actor) can MAKE APPOINTMENT (use case), as shown in Figure 6-12 (pg. 186).

Notice that the UML symbol for a use case is an oval with a label that describes the action or even. The actor is shown as a stick figure, with a label that identifies the actor's role. The line from the actor to the use case is called an association, because it links a particular actor to a use case.


Use cases also can interact with other use cases. When the outcome of one use case is incorporated by another use case we say that the second case uses the first case. UML indicates the relationship with an arrow that points at the use case being used.

Figure 6-13 (pg. 187) shows an example where a student adds a fitness class, and Produce Fitness-Class Roster *uses* the results of Add Fitness-Class to generate a new fitness-class roster. Similarly, if an instructor changes his or her availability, Update Instructor Information usesuses 6-13 (pg. 187) shows an example where a student adds a fitness class, and Produce Fitness-Class Roster *uses* the results of Add Fitness-Class to generate a new fitness-class roster. Similarly, if an instructor changes his or her availability, Update Instructor Information *uses* the Change Availability use case to update the instructor's information.


To create use cases, start by reviewing the information that gathered during the requirements modeling phase. The objective is to identify the actors and the functions or transactions they initiate.

For each use case, develop a use case description in the form of a table. A use case description documents the name of the use case, the actor, a description of the use case, a step-by-step list of the tasks and actions required for successful completion, a description of the use case, a step-by-step list of the tasks and actions required for successful completion, a description of alternative courses of action, preconditions, postconditions and assumptions.

Figure 6-14 (pg. 187) shows an example of the Add New Student use case for the fitness center.


When use cases are identified, all the related transactions should be grouped into a single use case.

e.g., when a hotel customer reserves a room, the reservation system blocks a room, updates the occupancy forecast and sends the customer a confirmation. Those events are all part of a single use case called Reserve Room, and the specific actions are step-by-step tasks within the use case.
A class diagram shows the object classes and relationships involved in a use case.

Like a DFD, a class diagram is a logical model, which evolves into a physical model and finally becomes a functioning information system. In structured analysis, entities, data stores and processes are transformed into data structures and program code. Similarly, class diagrams evolve into code modules, data objects and other system components.

In a class diagram, each class appears as a rectangle, with the class name at the top, followed by the class's attributes and methods. Lines show relationships between classes and have labels identifying the action that relates the two classes. To create a class diagram, review the use case and identify the classes that participate in the underlying business process.


The class diagram also includes a concept called cardinality, which describes how instances of one class relate to instances of another class.

e.g., an employee might have earned no vacation days or one vacation day or many vacation days. Similarly, an employee might have no spouse or one spouse.

Figure 6-17 (pg. 190) shows various UML notations and cardinality examples. Notice that in Figure 6-17, the first column shows a UML notation symbol that identifies the relationship shown in the second column. The third column provides a typical example of the relationship, which is described in the last column. In the first row of the figure, the UML notation 0.. (asterisk) identifies a zero or many relation. The example is that an employee can have no payroll deductions or many deductions.


Figure 6-18 (pg. 190) shows a class diagram for a sales order use case. Notice that the sales office has one sales manager who can have anywhere from zero to many sales reps. Each sales rep can have anywhere from zero to many customers, but each customer has only one sales rep.