BUS 444: chapter 6 - Object Modeling
Terms in this set (19)
Overview of Object-Oriented Analysis
● Object model
The most popular systems development options are:
object-oriented (O-O) analysis
O-O methodology is popular because it integrates easily with O-O programming languages such as:
and (5) Perl.
Programmers also like O-O code because it is modular, reusable and easy to maintain.
O-O analysis describes an information system by identifying things called objects; an object represents a real person, a place, an event or a transaction.
e.g., when a patient makes an appointment to see a doctor, the patient is an object, the doctor is an object and the appointment itself is an object.
O-O analysis is a popular approach that sees a system from the viewpoint of the objects themselves as they function and interact. The end product of O-O analysis is an
, which represents the information system in terms of objects and O-O concepts.
Object-Oriented terms and concepts
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
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
, which are characteristics that describe the object; e.g., a car has attributes such as make, model and color.
An object also has
, which are tasks or functions that the object performs when it receives a
, 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.
is a group of similar objects; e.g., Ford Fiestas belong to a class called CAR.
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.
Consider a simplistic example of how the UML might describe a family with parents and children.
UML represents an object as a rectangle with the object name at the top, followed by the object's
Figure 6-2 (pg. 181) shows a PARENT object with certain
such as name, age, sex and hair color. If there are two parents, then there are two instances of the PARENT object.
The PARENT object can perform
, such as reading a bedtime story, driving the carpool van or preparing a school lunch.
When a PARENT object receives a
, it performs a method (or action).
e.g., the message GOOD NIGHT from a child might tell the PARENT object to read a bedtime story, while the message DRIVE from another parent signals that it is the PARENT object's turn to drive the car pool.
Continuing with the family example, the CHILD object in Figure 6-3 (pg. 181) possesses the same attributes as the PARENT object and an additional attribute that shows the number of siblings. A CHILD object performs certain methods, such as picking up toys, eating dinner, playing, cooperating and getting ready for bed.
To signal the CHILD object to perform those tasks, a parent can send certain messages that the CHILD object will understand; e.g., the DINNER'S READY message tells a CHILD object to come to the table, while the SHARE WITH YOUR BROTHER/SISTER message tells a CHILD object to cooperate with other CHILD objects.
If objects are similar to nouns, attributes are similar to adjectives that describes the characteristics of an object.
- How many attributes are needed?
The answer depends on the business requirements of the information system and its users.
Even a relatively simple object, such as an inventory item, might have a part number, description, supplier, quantity on hand, minimum stock level, maximum stock level, reorder time, and so on. Some objects might have a few attributes; others might have dozens.
Systems analysts define an object's attributes during the
(III.) Systems Design
In an O-O system, objects can inherit (or acquire) certain attributes from other objects.
Objects can have a specific attribute called a
. The state of an object is an adjective that describes the object's current status; e.g., depending on the state, a student can be a future student, a current student or a past student. Similarly, a bank account can be active, inactive, closed or frozen.
A method defines specific tasks that an object can perform.
Just as objects are similar to nouns and attributes are similar to adjectives, methods resemble verbs that describe
an object does something.
Consider a server who prepares fries in a fast-food restaurant. A systems analyst might describe the operation as a method called MORE FRIES, as shown in Figure 6-4 (pg. 182). The MORE FRIES method includes the steps required to:
(1) heat the oil;
(2) fill the fry basket with frozen potato strips;
(3) lower it into the hot oil;
(4) check for readiness;
(5) remove the basket when ready and drain the oil;
(6) pour the fries into a warming tray;
and (7) add salt.
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
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
, 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.
An object belongs to a group or category called a class. All objects within a class share common attributes and methods, so a class is like a blueprint, or template for all the objects within the class.
Objects within a class can be grouped into
, which are more specific categories within a class.
e.g., TRUCK objects represent a subclass within the VEHICLE class, along with other subclasses called CAR, MINIVAN, and SCHOOL BUS, as shown in Figure 6-7 (pg. 183). Notice that all four subclasses share common traits of the VEHICLE class, such as make, model, year, weight and color. Each subclass also can possess traits that are uncommon, such as a load limit for the TRUCK or an emergency exit location for the SCHOOL BUS.
A class can belong to a more general category called a
e.g., a NOVEL class belongs to a superclass called BOOK, because all novels are books in this example. The NOVEL class can have subclasses called HARDCOVER, PAPERBACK and DIGITAL.
Similarly, consider a fitness center illustrated in Figure 6-8 (pg. 184) that might have students, instructors class schedules and a registration process. As EMPLOYEE class belongs to the PERSON superclass, because every employee is a person, and the INSTRUCTOR class is a subclass of EMPLOYEE.
Relationships among Objects and Classes
enable objects to communicate and interact as they perform business functions and transactions required by the system. Relationships describe what objects need to know about each other, how objects respond to changes in other objects and the effects of membership in classes, superclasses and subclasses.
Some relationships are stronger than others (just as a relationship between family members is stronger than one between casual acquaintances).
The strongest relationship is called inheritance.
enables an object, called a
, to derive one or more of its attributes from another object, called a
In the example in Figure 6-10 (pg. 185), the INSTRUCTOR object (child) inherits many traits from the EMPLOYEE object (parent), including Social Security number, Telephone number and Hire date. The INSTRUCTOR object also can possess additional attributes, such as Type of Instructor. Because all employees share certain attributes, those attributes are assumed through inheritance and do not need to be repeated in the INSTRUCTOR object.
Object Relationship Diagram
After objects, classes and relationships have been identified, an object relationship diagram can be prepared to provide an overview of the system. That model is used as a guide to continue to develop additional diagrams and documentation.
Figure 6-11 (pg. 186) shows an object relationship diagram for a fitness center. Notice that the model shows the objects and how they interact to perform business functions and transactions.
Object Modeling with the Unified Modeling Language
Just as structured analysis uses DFDs to model data and processes, systems analysts use UML to describe O-O systems.
Chapter 4 explained that UML is a popular technique for documenting and modeling a system. UML uses a set of symbols to represent graphically the various components and relationships within a system. Although the UML can be used for business process modeling and requirements modeling, it is mainly used to support O-O system analysis and to develop object models.
Use Case Modeling
● Use case
● Use case description
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
the first case. UML indicates the relationship with an arrow that
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
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.
Use Case Diagrams
● System boundary
A use case diagram is a visual summary of several related use cases within a system or subsystem.
Consider a typical auto service department. The service department involves customers; service writers, who prepare work orders and invoices; and mechanics, who perform the work. Figure 6-16 (pg. 189) shows a possible use case diagram for the auto service department.
When a use case diagram is created, the first step is to identify the system boundary, which is represented by a rectangle. The
shows what is included in the system (inside the rectangle) and what is not included in the system (outside the rectangle). After the system boundary is identified, use cases are placed on the diagram, the actors are added and the relationships shown.
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
, 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
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.
A sequence diagram is a dynamic model of a use case, showing the interaction among classes during a specified time period. A sequence diagram graphically documents the use case by showing the classes, the messages and the timing of the messages. Sequence diagrams include symbols that represent classes, lifelines, messages and focuses. These symbols are shown in Figure 6-19 (pg. 191).
: A class is identified by a rectangle with the name inside. Classes that send or receive messages are shown at the top of the sequence diagram.
: A lifeline is identified by a dashed line. The
represents the time during which the object above it is able to interact with the other objects in the use case. An
marks the end of the lifeline.
: A message is identified by a line showing direction that runs between two objects. The label shows the name of the message and can include additional information about the contents.
: A focus is identified by a narrow vertical shape that covers the lifeline. The
indicates when an object sends or receives a message.
Figure 6-20 (pg. 192) shows a sequence diagram for the ADD NEW STUDENT use case in the fitness center example. Notice that the vertical position of each message indicates the timing of the message.
State Transition Diagrams
Earlier in this chapter it was explained that state refers to an object's current status. A
state transition diagram
shows how an object changes from one state to another, depending on events that affect the object.
All possible states must be documented in the state transition diagram, as shown in Figure 6-21 (pg. 192). A bank account, for example could be opened as a NEW account, change to an ACTIVE or EXISTING account, and eventually become a CLOSED or FORMER account. Another possible state for a bank account could be FROZEN, if the account's assets are legally attached.
In a state transition diagram, the states appear as rounded rectangles with the state names inside. The small circle to the left is the initial state, or the point where the object first interacts with the system. Reading fro left to right, the lines show direction and describe the action or event that causes a transition from one state to another. The circle at the right with a hollow border is the final state.
resembles a horizontal flowchart that shows the actions and events as they occur. Activity diagrams show the order in which the actions take place and identify the outcomes.
Figure 6-22 (pg. 193) shows an activity diagram for a cahs withdrawal at an ATM machine. Notice that the customer initiates the activity by inserting an ATM card and requesting cash.
Activity diagrams also can display multiple use cases in the form of a grid, where classes are shown as vertical bars and actions appear as horizontal arrows.
Sequence diagrams, state transition diagrams and activity diagrams are dynamic modeling tools that can help a systems analyst understand how objects behave and interact with the system.
Business Process Modeling
In addition to sequence diagrams and activity diagrams,
business process models (BPM)
can be used to represent the people, events and interaction in a system.
BPM initially was discussed in Chapter 4 as a requirements modeling tool, but it can be used anytime during the systems development process. BPM works well with object modeling, because both methods focus on the actors and the way they behave.
Figure 6-23 (pg. 194) shows the Bizagi Modeler tool, which supports business process modeling and simulation using the standard BPM notation. This free Windows application includes video tutorials, support forums and reusable templates.
Object modeling requires many types of diagrams to represent the proposed system. Creating the diagrams by hand is time consuming and tedious, so systems analysts rely on CASE tools to speed up the process and provide an overall framework for documenting the system components.
In addition, CASE tools ensure consistency and provide common links so that once objects are described and used in one part of the design, they can be reused multiple times without further effort.
Organizing the Object Model
The previous section described how to use O-O tools and techniques to build a logical model of the information system. The next step is to organize the diagrams and documentation so that the object model is easily read and understood. If a CASE tool i used to develop the design, the CASE software will perform much of this work automatically.
There are many ways to proceed with the task of organizing the object model, and experience is the best teacher. After identifying the system's objects, classes and relationships, an object relationship diagram should be developed that provides an overview of the system. If a CASE-generated model is not used, each diagram or object definition should be supported by clear, relevant documentation that can be accessed easily by anyone who reviews the object model.
e.g., use case and use case diagrams should be organized so they can be linked to the appropriate class, state transition, sequence and activity diagrams. The diagrams and documentation are the foundation for the system's design, so accuracy is important. Remember that it is much easier to repair a diagram now than to change the software later.