Managing Information Technology

352 Part III • Acquiring Information Systems

Method A

Method B

Data

Method C

Method D

Data

FIGURE 8.21 Message Passing

to as encapsulation. Encapsulation also means that
systems developed using O-O techniques can have
loosely coupled modules, which means they can be
reused in other O-O applications much more easily. This
is why O-O approaches and traditional approaches that
have incorporated some O-O concepts should theoreti-
cally result in faster project completion times: New
systems can be created from preexisting objects. In fact,
vendors can sell libraries of objects for reuse in different
organizations.
A second major O-O principle is inheritance. That
is, classes of objects can inherit characteristics from other
object classes. Every object is associated with a classof
objects that share some of the same attributes and
operations. Object classes are also typically arranged in a
hierarchy, so that subclasses inherit attributes and
operations from a superclass. For example, if a bird is a

superclass, the bird object’s attributes and operations

could be inherited by a specific type of bird, such as a

cardinal.

Techniques and notations for O-O analysis and

design modeling have now been standardized under a

Unified Modeling Language (UML). Some UML

techniques and notations are used even with non-O-O

systems development approaches. According to UML,

logical modeling begins with a Use Case diagram that

captures all the actors and all the actions that they initiate.

(The actors are similar to external entities in a data flow

diagram.) For example, the actors for a software applica-

tion to support the renting of videos would include

customers who are registered members, noncustomers

(browsers) who could choose to become members, a

billing clerk, a shipping clerk, and an inventory system.

As shown in Figure 8.22, nine different functions initiated

by these actors are modeled as Use Cases.

Each Use Case is also described in a text format

using a standard template. Common elements in a

template are Use Case Name, Actor, Goal, Description,

Precondition, and Postcondition, as well as Basic,

Alternate, and Exceptional Flow events, which describe

the actor’s actions and the system’s response. The events

to be documented for one of the use cases (Become

Member) in Figure 8.22 are shown in Figure 8.23. Use

Case documentation is reviewed by system users and

developers to verify that system requirements are

adequately captured.

UML also has many other types of diagrams. Three

common diagrams are as follows:

Become

Member

Log In Check

Account

Browse

Catalog

Submit

Rental Order

Select

Item

Log Out

Delete

Item

Accept

Order

Browser

Member

Billing

Clerk

Inventory

System

Shipping

Clerk

FIGURE 8.22 Use Case Diagram (Reprinted with permission from Chand, 2003)