Ebook Systems analysis and design (8th edition): Part 2

C H A P T E R

10

Object-Oriented
Systems Analysis
and Design Using UML*
LEARNING OBJECTIVES
Once you have mastered the material in this chapter you will be able to:
1. Understand what object-oriented systems analysis and design is and appreciate its
usefulness.
2. Comprehend the concepts of unified modeling language (UML), the standard approach for
modeling a system in the object-oriented world.
3. Apply the steps used in UML to break down the system into a use case model and then a
class model.
4. Diagram systems with the UML toolset so they can be described and properly designed.
5. Document and communicate the newly modeled object-oriented system to users and other
analysts.

Object-oriented analysis and design can offer an approach that facilitates
logical, rapid, and thorough methods for creating new systems responsive
to a changing business landscape. Object-oriented techniques work well in
situations in which complicated information systems are undergoing continuous maintenance, adaptation, and redesign.
In this chapter, we introduce the unified modeling language (UML), the industry standard for modeling object-oriented systems. The UML toolset includes diagrams that allow
you to visualize the construction of an object-oriented system. Each design iteration takes a
successively more detailed look at the design of the system until the things and relationships
in the system are clearly and precisely defined in UML documents. UML is a powerful tool
that can greatly improve the quality of your systems analysis and design, and thereby help
create higher-quality information systems.
When the object-oriented approach was first introduced, advocates cited reusability of the
objects as the main benefit of their approach. It makes intuitive sense that the recycling of program parts should reduce the costs of development in computer-based systems. It has proved
to be very effective in the development of GUIs and databases.Although reusability is the main
goal, maintaining systems is also very important, and because the object-oriented approach
creates objects that contain both data and program code, a change in one object has a minimal impact on other objects.

*By Julie E. Kendall, Kenneth E. Kendall, and Allen Schmidt.

281

282

PART III • THE ANALYSIS PROCESS

OBJECT-ORIENTED CONCEPTS
Object-oriented programming differs from traditional procedural programming by examining the objects that are part of a system. Each object is a computer representation of some actual thing or event.
General descriptions of the key object-oriented concepts of objects, classes, and inheritance are presented in this section, with further details on other UML concepts introduced later in this chapter.

Objects
Objects are persons, places, or things that are relevant to the system we are analyzing. Objectoriented systems describe entities as objects. Typical objects may be customers, items, orders,
and so on. Objects may also be GUI displays or text areas on the display.

Classes
Objects are typically part of a group of similar items called classes. The desire to place items into
classes is not new. Describing the world as being made up of animals, vegetables, and minerals is an
example of classification. The scientific approach includes classes of animals (such as mammals),
and then divides the classes into subclasses (such as egg-laying animals and pouched mammals).
The idea behind classes is to have a reference point and describe a specific object in terms of its
similarities to or differences from members of its own class. In doing so, it is more efficient for someone to say, “The koala bear is a marsupial (or pouched animal) with a large round head and furry
ears,” than it is to describe a koala bear by describing all of its characteristics as a mammal. It is more
efficient to describe characteristics, appearance, and even behavior in this way. When you hear the
word reusable in the object-oriented world, it means you can be more efficient, because you do not
have to start at the beginning to describe an object every time it is needed for software development.
Objects are represented by and grouped into classes that are optimal for reuse and maintainability. A class defines the set of shared attributes and behaviors found in each object in the class. For
example, records for students in a course section have similar information stored for each student.
The students could be said to make up a class (no pun intended). The values may be different for
each student, but the type of information is the same. Programmers must define the various classes
in the program they are writing. When the program runs, objects can be created from the established
class. The term instantiate is used when an object is created from a class. For example, a program
could instantiate a student named Peter Wellington as an object from the class labeled as student.
What makes object-oriented programming, and thus object-oriented analysis and design, different from classical programming is the technique of putting all of an object’s attributes and
methods within one self-contained structure, the class itself. This is a familiar occurrence in the
physical world. For example, a packaged cake mix is analogous to a class since it has the ingredients as well as instructions on how to mix and bake the cake. A wool sweater is similar to a class
because it has a label with care instructions sewn into it that caution you to wash it by hand and
lay it flat to dry.
Each class should have a name that differentiates it from all other classes. Class names are
usually nouns or short phrases and begin with an uppercase letter. In Figure 10.1 the class is called
RentalCar. In UML, a class is drawn as a rectangle. The rectangle contains two other important
features: a list of attributes and a series of methods. These items describe a class, the unit of analysis that is a large part of what we call object-oriented analysis and design.
An attribute describes some property that is possessed by all objects of the class. Notice that
the RentalCar class possesses the attributes of size, color, make, and model. All cars possess these
FIGURE 10.1
An example of a UML class. A
class is depicted as a rectangle
consisting of the class name,
attributes, and methods.

Class Name
RentalCar
size
color
make
model
rentOut( )
checkIn( )
service( )

Attributes

Methods (Operations)

CHAPTER 10 • OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN USING UML

283

attributes, but each car will have different values for its attributes. For example, a car can be blue,
white, or some other color. Later on we will demonstrate that you can be more specific about the
range of values for these properties. When specifying attributes, the first letter is usually lowercase.
A method is an action that can be requested from any object of the class. Methods are the
processes that a class knows to carry out. Methods are also called operations. For the class of
RentalCar, rentOut(), checkIn(), and service() are examples of methods. When specifying
methods, the first letter is usually lowercase.

Inheritance
Another key concept of object-oriented systems is inheritance. Classes can have children; that is,
one class can be created out of another class. In UML, the original—or parent—class is known
as a base class. The child class is called a derived class. A derived class can be created in such a
way that it will inherit all the attributes and behaviors of the base class. A derived class, however,
may have additional attributes and behaviors. For example, there might be a Vehicle class for a
car rental company that contains attributes such as size, color, and make.
Inheritance reduces programming labor by using common objects easily. The programmer only
needs to declare that the Car class inherits from the Vehicle class, and then provide any additional
details about new attributes or behaviors that are unique to a car. All the attributes and behaviors of
the Vehicle class are automatically and implicitly part of the Car class and require no additional
programming. This enables the analyst to define once but use many times, and is similar to data that
is in the third normal form, defined only once in one database table (as discussed in Chapter 13).
The derived classes shown in Figure 10.2 are Car or Truck. Here the attributes are preceded
by minus signs and methods are preceded by plus signs. We will discuss this in more detail later
in the chapter, but for now take note that the minus signs mean that these attributes are private
(not shared with other classes) and these methods are public (may be invoked by other classes).

FIGURE 10.2

Vehicle

A class diagram showing
inheritance. Car and Truck are
specific examples of vehicles and
inherit the characteristics of the
more general class, Vehicle.

–size
–color
–make
–model
–available
–ratePerDay
–ratePerWeek
–ratePerMile
+rentOut( )
+checkIn( )
+service( )
+addNew( )
is a

Car
–size
–color
–make
–model
–available
–ratePerDay
–ratePerWeek
–ratePerMile
–style
+rentOut( )
+checkIn( )
+service( )
+addNew( )

is a

Truck
–size
–color
–make
–model
–available
–ratePerDay
–ratePerWeek
–ratePerMile
–length
–4WheelDrive
–manualShift
+rentOut( )
+checkIn( )
+service( )
+addNew( )

284

PART III • THE ANALYSIS PROCESS

C O N S U LT I N G O P P O R T U N I T Y 1 0 . 1

Around the World in 80 Objects

B

ecause you have described the advantages of using objectoriented approaches, Jules and Vern, two top executives at
World’s Trend, would like you to analyze their business using this
approach. You can find a summary of World’s Trend business activities in Figure 7.15. Notice also the series of data flow diagrams in that chapter to help you conceptualize the problem and
begin making the transition to Object Think.
Because you are such good friends with Jules and Vern and because you wouldn’t mind a little practical experience using O-O
thinking, you agree to apply what you know and give them a report.

Once you have reread the business activities for World’s Trend, provide a timely review by completing the following tasks:
᭹

᭹

Use the CRC cards technique to list classes, responsibilities,
and collaborators.
Use the Object Think technique to list “knows” and
corresponding attributes for the objects in those classes
identified in the previous stage.

Write up both steps and fly over to World’s Trend headquarters
with your report in hand. Clearly, Jules and Vern are hoping for a
fantastic voyage into the new world of object-oriented methods.

Program code reuse has been a part of structured systems development and programming languages (such as COBOL) for many years, and there have been subprograms that encapsulate data.
Inheritance, however, is a feature that is only found in object-oriented systems.

CRC CARDS AND OBJECT THINK
Now that we have covered the fundamental concepts of object-oriented systems analysis and design, we need to examine ways to create classes and objects from the business problems and systems we are facing. One way to begin enacting the object-oriented approach is to start thinking
and talking in this new way. One handy approach is to develop CRC cards.
CRC stands for class, responsibilities, and collaborators. The analyst can use these concepts
when beginning to talk about or model the system from an object-oriented perspective. CRC
cards are used to represent the responsibilities of classes and the interaction between the classes.
Analysts create the cards based on scenarios that outline system requirements. These scenarios
model the behavior of the system under study. If they are to be used in a group, CRC cards can
be created manually on small note cards for flexibility, or they can be created using a computer.
We have added two columns to the original CRC card template: the Object Think column and
the property column. The Object Think statements are written in plain English, and the property,
or attribute, name is entered in its proper place. The purpose of these columns is to clarify thinking and help move toward creating UML diagrams.

Interacting During a CRC Session
CRC cards can be created interactively with a handful of analysts who can work together to identify the class in the problem domain presented by the business. One suggestion is to find all the
nouns and verbs in a problem statement that has been created to capture the problem. Nouns usually indicate the classes in the system, and responsibilities can be found by identifying the verbs.
With your analyst group, brainstorm to identify all the classes you can. Follow the standard
format for brainstorming, which is not to criticize any participant’s response at this point, but
rather to elicit as many responses as possible. When all classes have been identified, the analysts
can then compile them, weed out the illogical ones, and write each one on its own card. Assign
one class to each person in the group, who will “own” it for the duration of the CRC session.
Next, the group creates scenarios that are actually walk-throughs of system functions by taking desired functionality from the requirements document previously created. Typical systems
methods should be considered first, with exceptions such as error recovery taken up after the routine ones have been covered.
As the group decides which class is responsible for a particular function, the analyst who
owns the class for the session picks up that card and declares, “I need to fulfill my responsibility.” When a card is held in the air, it is considered an object and can do things. The group then

CHAPTER 10 • OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN USING UML

285

Class Name: Department
Superclasses:
Subclasses:
Responsibilities

Collaborators

Object Think

Property

Add a new department
Provide department information

Course

I know my name

Department Name

I know my department chair

Chair Name

Class Name: Course
Superclasses:
Subclasses:
Responsibilities
Add a new course
Change course information
Display course information

Collaborators
Department
Textbook
Assignment
Exam

Object Think
I know my course number
I know my description
I know my number of credits

Property
Course Number
Course Description

Credits

Class Name: Textbook
Superclasses:
Subclasses:
Responsibilities
Add a new textbook
Change textbook information

Collaborators

Object Think

Property

Course

I know my ISBN
I know my author

ISBN

I know my title
I know my edition

Title

I know my publisher
I know if I am required

Publisher

Find textbook information
Remove obsolete textbooks

Author
Edition
Required

Class Name: Assignment
Superclasses:
Subclasses:
Responsibilities
Add a new assignment
Change an assignment
View an assignment

Collaborators
Course

Object Think
I know my assignment num

ber

I know my description

I know how many points I

Property
Task Number
Task Description

am worth

I know when I am due

proceeds to refine the responsibility into smaller and smaller tasks, if possible. These tasks can
be fulfilled by the object if it is appropriate, or the group can decide that it can be fulfilled by interacting with other things. If there are no other appropriate classes in existence, the group may
need to create one.
The four CRC cards depicted in Figure 10.3 show four classes for course offerings. Notice
that in a class called Course, the systems analyst is referred to four collaborators: the department,

Points
Due Date

FIGURE 10.3
Four CRC cards for course
offerings show how analysts fill in
the details for classes,
responsibilities, and collaborators,
as well as for object think
statements and property names.