A Behaviorally Driven Approach to Object-Oriented Analysis and Design with Object-Oriented Data Modeling

FOR IMMEDIATE RELEASE
(Free-Press-Release.com) January 28, 2012 -- http://quickbiznet.com/elance.html

When software is developed using objects, the software system is modeled as a
set of objects with each object an instance of a class. A class
1
defines the messages
that can be sent to an object with the corresponding signatures, the attributes
to be represented in the object, and the associations between objects of this class
1. This is more precisely a type; we use the term class as in OMT.
and other objects (of this class or a different class). The software system executes

by sending messages to objects. A message to an object invokes the relevant
method, which may send messages to other objects, etc. The implementation of
objects is encapsulated. That is, the internal data structures and the method bodies
are not visible to other objects. The choice of classes, the attributes of classes,
and the associations among classes is sometimes called an object-oriented data
model.

An object model sets the structure of the software system; at the same time, an
object model must include all behavior required of the software system. How can the

object model be developed? One popular approach (22) focuses first on the structure
of objects based on concepts in the real world of interest to the application. We take
a different approach, focusing on the desired behavior of the system as expressed
in a set of use cases (17). These two approaches are contrasted in Table 2.1. The
difference between these two approaches is most evident during analysis when the
first object model is constructed.
The Object Modeling Technique (OMT) (22) recommends that the object model
be defined first, with an emphasis on representing objects (and attributes and associations)

that correspond to concepts of interest in the real world. The second step is
to model each object that has interesting states along with the events that cause state
transitions, in a state diagram, based on statecharts (14). Cook and Daniels have described
a similar approach more recently (5).
2. An object-oriented data model also includes other, more advanced constructs such as
aggregation, composition, and generalization among objects as well as more detail such as
attribute types, multiplicity of associations, etc.

Our approach focuses first on the desired behavior of the software system by
describing use cases
3

(17). Each use case describes one interaction with a software
system from the point of view of an actor. Each actor represents a class of users (such
as booking clerk, branch manager, etc. for a car rental application). The scenario
of the use case describes how the system must perform, i.e., the desired behaviors
of the system to be built. The objects can be discovered using a responsibilitydriven
approach (26) based on CRC (class-responsibility-collaboration) cards (1).
A responsibility for an object is something that the object must “do” or must “know.”

Collaboration is when one object sends a message to another object, to receive some
assistance to perform the currently invoked responsibility. We refer to our approach
as Disciplined Object-Oriented Software Engineering (DOOSE) (6, 7) because of
our focus on work products from one step driving the next step and our requirement
for traceability among the work products.
These approaches differ in their central focus. OMT produces a richly structured
object model that describes objects, attributes and associations that occur in the real
world to which methods can be added. Our approach is driven by the desired behaviors

of the system. The resulting object model represents a set of responsibilities and
collaborations that will support the complete set of use cases.
We focus on a behaviorally driven approach to object-oriented development because
we believe that the resulting software is more likely to reflect the needs of
the application. We also believe that it is valuable to focus on the responsibilities
and collaborations of objects early in the development lifecycle (rather than associations,
attributes, and methods) because it provides a more abstract view of objects.

However, we must find a way to include the object-oriented data modeling necessary
to complete the object model. The contribution of this paper is the identification of
which aspects of data modeling should be included (and excluded!) from the analysis
step and which aspects of data modeling should be handled during design. This
paper also introduces the concept of the shared model to guide the developer as to
what should be included and excluded in the use case and analysis models.
Regardless of the object-oriented analysis and design method used, we might wonder

whether object-oriented software requires a “database design” step, much like
traditional database design, in order to model the persistent data in a way that meets
the needs of multiple applications and that provides reasonable performance. Should
we take the object model for the software system, perhaps discovered using a behaviorally
oriented approach, as the basis for our (object-oriented or other) database
schema? One could argue that object-oriented databases set out to eliminate the need
for database design. Because they support persistent C++, Java or Smalltalk, it is

possible to take classes from the software model and simply make them persistent.
We believe that such an approach, although possible, is naive.
Database design is a necessary step for several reasons (18). (1) The attributes and
data structures of a class required to support the software might not be exactly the
attributes and data structures that are to be stored persistently. We may need only a
subset of the attributes and data structures to be stored persistently. (2) We may need
more than one collection (e.g., set, list, bag, array) of objects of a particular type

(class). Thus it is inappropriate to assume that there is a single set of all instances of
a given class. (3) Databases typically define a global name space, including such
things as table names, attribute names, etc. For objects, we may need persistent
“handles” or names for objects that serve as entry points into the persistent data. (4)
We may need individual objects that are persistent by themselves, without being in a
named collection. Such objects may have the kind of handle mentioned in point (3).
(5) Database design requires information about how many instances are likely for

each collection, in order to decide about clustering, indices, etc. Such information is
typically unavailable in an object model for software.
In the remainder of this paper, we give a brief description of our behavioral
approach using an example from the EU Car Rental application in Section 2.2. This is
followed by a discussion in Section 2.3 of how to do object-oriented data modeling
in this method. Related work is presented in Section 2.4. The paper concludes in
Section 2.5 with a brief discussion of open issues with regard to object-oriented data
modeling.

In this section, we give a quick overview of our approach to object-oriented analysis
and design by developing a portion of the Use Case, Analysis, and Design Models
for the EU-Rent Rental Car example (23).
We begin by developing the Use Case Model, starting by identifying the scope of
the system under development (setting the system boundary), the actors (roles) that
interact with the system, and the “original” use cases. For the EU-Rent case study,
we identified 11 actors and 46 original use cases, shown in Table 2.2.
For each use case, we develop a scenario, often in the form of a conversation (25)

between the actor and the system. The scenario reflects the normal course of execution
for the use case (17). We also indicate alternatives, where conditional or exceptional
situations require revisions to the scenario. We refine the use case model to
eliminate redundant portions of scenarios by factoring them into separate use cases.
This brings us to the refined use case model.
A UML use case diagram of the refined use case model for the actor Booking
Agent is shown in Figure 2.1. Since a complete refined use case diagram for the
system is often quite large, we may draw several use case diagrams where each

diagram shows the use cases that pertain to one actor. We see the
uses and extends
relationships between refined use cases. uses indicates that one use case (the client
at the tail end of the arrow) uses the other (at the head end of the arrow) as part of the
client’s scenario.
Any software system with human actors will require some form of user interface.
We concur with Jacobson (17) that sketching out a user interface can assist with the
development of the use case model. However, the actual user interface design, based
on aesthetics and other issues, is separate from elaborating the way that the software

system must work, as shown in the fourth line of the top portion of Table 2.4.
Because the use case model and the analysis model are both expressed in natural
language, it is important to be precise about terms and concepts from the application
domain and how they are defined. If standards exist, e.g., through an existing glossary,
they can be used directly. The glossary allows us to be precise about concepts
from the domain without requiring that the domain concepts appear in the object
model. The use of a glossary is listed on line 5 of the top half of Table 2.4.

We believe data structures as well as the detailed structure of the object model
should be developed during design. But we need to represent the data required for
the application in the analysis model. The bottom half of Table 2.4 describes how we
represent data in our analysis model.
If data is present in the system, then it is represented as the responsibility for one
object to “know” something as shown in the first line in the bottom half of Table 2.4.
As an example, we expect the Customer object in the EU-Rental system to