schultz@grebyn.com (Ronald Schultz) (02/11/91)
One of the strengths of the object-oriented paradigm lies in its
emphasis on reusability. Yet management, at least in the business
information systems arena, is tired of hearing about reuse. What
is needed is a demonstration to senior business management that OO
provides a way to truly realize the benefits of reuse, in a manner
they are familiar with.
While OO in no way guarantees reusability, it does provide a
natural approach to supporting reuse. But the reusability emphasis
to date has been largely on reusable code. While such reuse is
very useful, its utility is limited to a particular language, DBMS,
and often hardware platform.
A number of writers over time have commented on the need for
reusable design and analysis products. In particular, Brad Cox has
used this forum to comment on the need for reusable,
interchangeable software components. He comments on the very real
need for reusable stacks, queues, and Customer objects for example.
Unfortunately I believe that much of software management today is
disenchanted with the concept of reusability, at least in my domain
of management systems such as payroll, general ledger, and order
entry. Reusability has been shouted so long and so hard, yet has
shown so little real value today that many in my arena have given
up.
In order to preach the benefits of any new paradigm, one has to
show real value to the end users (consumers as Cox notes) of the
developed product. I believe that the benefits of OO can be
demonstrated to the most senior levels of management without ever
discussing code. This can be done by conducting OO Planning, or
Enterprise Modeling in an object-oriented manner.
For example, let's consider the Customer object. In business the
development and preparation of business plans is largely in the
domain of senior management. These plans obviously focus on
customers. Yet most business plans I have seen are one sided in
addressing the abstraction of Customer. Most plans focus on the
customer as being only data, or process. A customer is either
considered to have a name, address, budget, ..., or the customer
orders, pays for, or returns product. Yet to date I have seen very
little in tool or empirical support for reusable specifications
that focus on this very real and important abstraction,
'Customer'..
In my use of OO I have seen little to distinguish Customer objects
from queue objects in terms of complexity or effort to define
(albeit implementing these in code is a different matter!). But in
many cases the level of abstraction expertise required to create a
Customer object is beyond the understanding of most analysts. Our
industry has focused on the fine art of hand crafting each new bit
of code. This craftsmanship has blinded many to the commonality of
objects across specific applications, businesses, and business
areas. There exists a need today for object-oriented domain
analysis if the true benefits of reuse are to be ever realized.
The utility of a customer object is illustrated here with an
example. A preliminary object specification may appear as follows:
Class Specification for Retail Drug Store Customer
DESCRIPTION
A retail customer belongs to the class of persons.
In general, the retail customer resides within a 10 mile radius of
the store.
A customer has a name, address, and phone number.
A customer can be unaware of the store, aware and not interested,
aware and interested in the store, in view of the store, entering
the store, browsing the aisles, considering a purchase, purchasing
a product(s), exiting the store, returning a product.
A customer can perform the operations of listen to the radio, watch
television, read the newspaper, drive to the store, park, view the
store, enter the store, browse the aisles, select goods, purchase
good, return goods, and finally, exit the store.
SEMANTIC NETWORK FOR RETAIL CUSTOMER
Customer
has_Part--- =1 Name
has_Part--- =1 Address
has-Part--- >=1 Phone Number
A STATE TRANSITION DIAGRAM FOR RETAIL CUSTOMER
reading ---> drive to store ---> park-----> view the store ----->
listening |
watch TV |
|
--------------------------------------------------------------
|
enter -----> browse ---> select product -----> purchase ---> exit
|<----|
OPERATIONS
reading The customer can read an advertisement about the store in
the local newpapaper.
watch TV The customer can see an advertisement about the store
that appears on a television spot
listen to radio The customer can hear a radio spot about the store
on his radio
drive The customer can drive to a specific location
view the store The customer can see the front of the store
park The customer can park his automobile in the parking lot
of the store
enter The customer can enter the store
browse The customer may browse the aisles looking for selected
items.
select products The customer can select products of interest. The
customer may have been interested in these products from
advertising, or other reasons.
return products The customer may return product(s) that were
either defective or did not meet the customer needs.
purchase The customer can pay for his purchase at the cash
register.
exit The customer may exit the store
END OF DRAFT SPECIFICATION
This simple draft class specification can be used to generate
discussion with management to validate and complete the
specification. This particular specification, from personal
experience with retail drug store projects, would generate a lot of
debate ( in many cases very heated !!).
For example:
The assumption that all customers drive automobiles would be
challenged. Many school children ride their bicycles to the store
to purchase soft drinks.
In addition, many individuals come to the store to purchase
prescription medications. These prescriptions are phoned in by the
customer's physician or the prescription is hand-delivered by the
customer to the store pharmacist, and then are picked up by the
customer.
These, as well as other operations and states, would have to be
discussed and added to the specification when appropriate. When
completed, this specification would prove invaluable to the
business professional in business planning.
Doing business planning in an object-oriented manner involves
selecting or defining operations on objects to get another object
to behave in a desired manner. In this case, the effort would be
looking at all the objects the customer interacts with, and
defining operations or states of those objects that will in some
way get the customer object to purchase goods.
From a senior management standpoint, the advantage of using this
object-oriented approach is that the specification serves to cull
out information and get it represented in a manner that management
can make effective decisions and plans with. It serves as an
excellent communication vehicle. In addition, the customer
abstraction tends to be much more complete than representations
using E-R diagrams or data flow diagrams. The specification shows
the close interrelationships between operations states, and
(although not in this case) attributes.
Also, since the specification is discrete and focuses on a customer
in isolation from other objects, one is not overwhelmed initially
by all the things a customer interacts with. This discreteness and
focus helps in the discussion of the specification and more quickly
bounds what is to be discussed, and not discussed.
Using such an approach as OO Planning shows that the OO paradigm
can 'add value' to processes that senior management is familiar
with. This value translates into support for the MIS staff to
further explore the value of OO in other areas.
What is of interest from a reuse standpoint is that the same
approach to getting a retail customer to purchase from a drug store
is not significantly different from getting a retail customer to
purchase from Sears, or K-Mart, or the local hardware store. Once
defined, this retail customer could be generalized to be usable to
the domain of retail selling. Starting with this premise, one can
develop a library of these reusable business objects to assist in
the planning and developing of approaches to meet the business's
needs.
Does anyone else on the net have experience in defining such kinds
of business objects ? Has anyone else done object-oriented
business planning, or object-oriented organization analysis ? I
would be interested in corresponding and seeing these ideas further
expanded and discussed.
Thanx
=================================================================
Ron Schultz
National Capitol Systems
5634 Claire Court
Dublin, Ohio 43017-2440
Phone - 614 431-8499
schultz@grebyn.com
=================================================================