A Visible Solution Paper
Object-Orientation and Business-Driven
Information Engineering
Printable
PDF Version
By Robin Peel and Keith Harmon
Copyright © 1997, Visible
Systems Corporation
Object oriented analysis, design, and system
development techniques have become increasingly popular as a
means of meeting the requirement for better tools to support
complex systems. Information Engineering is a popular methodology
for bridging the gap between business requirements and systems.
These two sets of methodologies have similarities and
complementary features that will be examined in detail.
Object-oriented programming has its roots in
the simulation languages of the late 1960s, and has recently
developed in response to a requirement for better tools to
support the implementation of complex systems. The resulting
programming languages (e.g. C++ and Smalltalk) permit or require
the use of "objects", with the goal of producing
complex applications which are more reliable, maintainable, and
expandable than is possible or practicable with conventional
programming techniques.
Object-oriented analysis and design
methodologies have emerged to bridge the gap between business
requirements and the physical implementation of a system. The
techniques are focused upon the design of logical models and
physical designs that will be implemented using object-oriented
programming tools. They use a range of mapping, diagramming,
modeling and documentation conventions and techniques. They model
business requirements in terms of ‘real world’ objects
and their interactions. See the Bibliography at the end of this
paper for references to many of the common methodologies.
Information Engineering, as originally defined
by Clive Finkelstein and James Martin in 1981, has evolved into
two main variants:
- ‘DP-driven Information
Engineering’, supported by James Martin, uses
existing functions of an organization as a starting
point; processes and data needed by the functions are
then defined, and the business knowledge is captured,
often through interviews with users.
- ‘Business-driven Information
Engineering’, developed by Clive Finkelstein (and
referred to as IE in this paper) captures strategic
business requirements in terms of business statements
which define the organization’s mission, goals,
strategies, objectives and policies, and links these to a
logical, technology-independent model of the data and
processes required to achieve those statements. The
resultant logical models then serve as a foundation from
which physical systems can be designed and implemented.
Both business-driven IE and object-oriented
analysis and design define business requirements using real-world
terms. This narrows the gap between business experts and those
who will implement and maintain the systems by generating logical
models that are both unambiguous to developers and understandable
to business experts. The focus of the two sets of methodologies
is different (but complementary), as illustrated in the following
table:
| Object-oriented
analysis and design |
Business-driven
Information Engineering |
| |
|
| Object-oriented
analysis and design techniques develop and link logical
models to a physical system implementation. |
The IE
methodology provides a rigorous link between the logical
data and process models and both the requirements of the
business (as documented in a set of agreed business
planning statements) and the physical system
implementation. |
| An
object-oriented implementation environment is assumed. |
No
assumptions about the proposed implementation environment
are made during data and process modeling. Implementation
can take place in either an object-oriented or other
environment. |
| An
object-oriented design carries the benefits of modularity
and encapsulation from the analysis stage through to the
completed application. |
Data and
process dependencies, which imply the boundaries of
modules, are identified automatically and/or defined
manually. Data access processes (DAPs) encapsulate the
data upon which they act. |
| The use of
objects implies a data-first design. A recurring theme in
the object-oriented texts is that the data and their
inter-relationships are much less vulnerable to changing
requirements than the operations performed on the data. |
Forward
engineering (top-down) using business-driven IE is a
data-first modeling methodology. Business changes bring
about changes in procedures and processes more often than
changes in the data upon which the business is based. A
mature data model is a sound foundation from which to
model changing business requirements.
IE also allows bottom-up modeling (for reverse
engineering and systems migration and integration). The
resulting data and process models can be implemented in
either traditional (e.g. relational) or object-oriented
environments. This will facilitate translation from one
environment to another.
|
The fundamental concept of object-orientation
is the "object," which combines data structure and
behavior in a single component. The inner workings of an object
may be hidden. Only its visible interfaces with the rest of the
world need to be understood by any other processes (or objects)
that interact with it. Objects with the same data structure and
behavior are grouped into an object "class;" libraries
of class definitions are an important asset, and are the basis
for the reusability resulting from the object-oriented approach.
This is in contrast to "conventional" programming, in
which data structures and their behaviors are defined separately
and are only loosely connected [Rumbaugh, 1991, p1].
There is an obvious mapping between the object
classes of an object-oriented design and the entities in an IE
data model. The implementation of the business-driven IE
methodology in the CASE tool Visible Advantage™ uses
the concept of "data access processes" (DAPs) to define
the basic processes which can act upon a specific entity
(documented as Create, Read, Update and Delete
DAPs for each entity). Higher-level business processes (which are
initiated in response to "business events") are
documented in terms of the various DAPs which are required to
interact with the data model (e.g. Create
EMPLOYEE). Using the IE methodology the
definition of an entity, accompanied by its available DAPs, forms
an encapsulated unit which provides the functionality of the OO
object class definition. The IE definition of an entity also
includes the linkages with the business planning statements.
[Booch, 1994] offers precise definitions of
object-oriented analysis and design:
- Object-oriented analysis is a method of
analysis that examines requirements from the perspective
of the classes and objects found in the vocabulary of the
problem domain.
- Object-oriented design is a method of
design encompassing the process of object-oriented
decomposition and a notation for depicting both logical
and physical as well as static and dynamic models of the
systems under design.
To support object-oriented analysis, design and
programming methodologies, a nomenclature has developed to
describe the key concepts. The following table lists and
describes these concepts, and clarifies their relationship with
the business-driven IE methodology and some of the features of
Visible Advantage™:
| |
OO concept |
IE’s
relationship
to OO concept |
| Class or
Object class:
|
Objects
with the same data structure and behavior (in the context
of the particular application environment) are grouped
into an object "class". Classes can be grouped
in a hierarchical structure. Classes may have attributes
(see below). Example: An
object class of PERSON.
|
An entity in
the data model with its associated Data Access Processes
(DAPs). DAPs govern the behavior or operations on an
entity. The IE definition of an
entity additionally includes the linkages to the business
planning statements.
|
| Object
instance: |
A
particular real-world occurrence of an object. Each
instance of an object is assumed to be unique. OO assumes
that all objects in an object class have a unique
identity that separates and identifies them from all
other object instances. Example:
Robin Peel is an instance of the object class PERSON.
|
An occurrence
of an entity or group of related entities.
IE expressly identifies characteristics that
identify one occurrence from another, in the form of a
primary key. A system-generated primary key identifies
entities that do not possess a natural primary key.
|
| Attribute: |
A
data value which can be held by the objects in a class.
Attributes may be assigned to different data types (e.g.
integer). Example: An
attribute of the class PERSON is last name (of type string).
|
An attribute
within an entity. Attributes are assigned a domain, which
define the valid data types. Domains offer additional
flexibility by defining length, range and a specific
valid set of values for one or more attributes. |
| Association
or Relationship: |
A
conceptual relationship between instances of an object.
Associations have cardinality including
one-to-one, one-to-many, and many-to-many. Most
object-oriented texts do not address the nature of
an association (i.e. mandatory or optional), except in
the definition of an object’s behavior.
Example: The object CUSTOMER is
associated with the object ORDER. This
will probably have a cardinality of one-to-many.
|
IE captures
cardinality as degree. IE
additionally captures:
- Association nature (i.e.
mandatory or optional).
- Delete rules for
referential integrity.
- Whether the association is used in
the identification of a child entity (i.e.
cascaded as primary key or foreign key).
|
| Abstraction
or Generalization: |
The
essential characteristics of an object or class, ignoring
irrelevant features, providing crisply defined conceptual
boundaries. This maintains a focus upon identifying
common characteristics among what may initially appear to
be different objects. Abstraction enhances reusability
and inheritance. Example:
Objects CUSTOMER and EMPLOYEE may initially appear to be quite different
objects, but applying the concept of abstraction will
identify them as sub-classes of the object class PERSON.
|
The
strategic, top-down analysis provides a high-level of
abstraction as a starting point for modeling. Lower
levels of abstraction are identified through tactical and
operational modeling. Abstraction
is really a modeling technique used to identify
commonality between things in the real world. The level
of abstraction appropriate to a particular model is
subjective and based upon the specific context.
|
| Inheritance: |
The
relationship between object classes, where one class
shares the attributes and behavior of one or more other
classes, based upon a hierarchical relationship. A discriminator
attribute discriminates an instance of an object
between the possible sub-classes. Example:
If two sub-classes of PERSON were
defined as CUSTOMER and EMPLOYEE, both would inherit all the structure and
behavior defined in PERSON,
which in our example will include the attribute last name.
|
Secondary
entities capture information that is unique to a
particular type or category of the parent entity.
Information that is common between a parent and all its
secondary entities is retained within the parent and
inherited by occurrences of the secondary entities.
If a parent entity may simultaneously have more
than one child entity, then this will be captured in a role
entity.
|
| Multiple
inheritance: |
An
object class may have more than one parent.
Example: The class CUSTOMER has
been defined in our examples as a sub-class of PERSON,
but it might also be a sub-class of SALES LEAD. Another sub-class of SALES LEAD
might be
POTENTIAL CUSTOMER
|
A parent can
have more than one group of secondary entities, and can
be of more than one type within each group (captured in a
role entity). Valid combinations
of sub-types are documented in a rule entity. This
allows the rules (and the behavior derived from them) to
be changed by updating values in an occurrence of the
rule entity.
|
| Typing: |
Quality
control on the interchange of objects of different
classes. Typing may be enforced to different degrees.
Application environments may allow conversions between
types. Example: Although the
classes CUSTOMER and EMPLOYEE share a common super-class (PERSON),
they are different. It might be invalid to perform a
process to Request current salary upon an object of class CUSTOMER, although this process may be valid for
objects of class EMPLOYEE.
|
The
object-oriented concept of type is essentially the
same as the IE concept of a type entity or category
discriminator. If an entity
may simultaneously be of more than one type, or may have
a history of type changes, then this will be captured in
a role entity.
|
| Encapsulation
or Information hiding: |
This
hides the details of the implementation of an object. The
result is that the interfaces of a class do not need to
change if just the internal implementation of a class is
changed. Encapsulation makes implementations more
portable, reliable, stable and reusable.
Example: The derivation of an employee’s
salary can be defined in many potential ways. A request
to an object for an employee’s salary can ignore the
internal workings that the object class EMPLOYEE may use to calculate the appropriate salary.
Any revisions to those mechanisms that may be made from
time to time will not affect the process by which the
salary is requested, or by which the result of the
calculation is returned.
|
Data Access
Processes (DAPs) represent processes that are
encapsulated with the entity upon which they act. The
inner workings of the DAPs are not visible at the
business process level. The business process just
provides a list of required information to a DAP.
DAPs are the only processes which act directly
upon entities within the data model.
|
| Modularity: |
Physical
packaging of the classes and objects in the logical
design into cohesive and loosely coupled modules.
Example: The PERSON
class, along with the sub-class EMPLOYEE,
and other classes such as JOB and its
sub-class MANAGER, might form the basis of a human resources
management module.
|
Visible Advantage™
automatically identifies data clusters based upon
data dependency, which can then be used to define the
boundaries of implementation modules.
It also automatically generates DAPs which
invoke (re-use) each other to form process modules, which
in turn may be re-used by other processes or modules.
|
| Polymorphism: |
Different
object classes may behave differently in response to a
common request or message. This enables instances of
different object classes to respond appropriately to
common operations upon them. Example:
An operation of Print for an object of class PICTURE
will behave differently than the same Print
operation for an object of class TEXT,
even though both these classes may have a common parent
class of FILE.
|
A process may
branch to one of several possible paths depending on the
value of an individual attribute. Additionally,
processes have a defined set of completion states, which
can be used to trigger a range of responses in their
calling processes.
|
| State
transition: |
The
state of an object instance is the status that the
object instance is in. A state transition is the
action of an object instance changing from one state to
another. An event is some
occurrence that may cause the state of a system to change
[Booch, 1994].
Example: When an order is shipped to
a customer, the state of the attribute order status within the object ORDER will
change from "In
warehouse" to "Shipped."
|
The state
of an entity is captured by a static entity related to
that entity, or by a specific domain of values for a state
attribute. Intersecting entities show the history of
the state transitions for the entity.
Rule entities restrict the state value
combinations to only those combinations that are
pre-defined as valid. Any state transition would be
triggered by a business event and implemented in a
business process.
|
| Concurrency: |
It
may be necessary to execute a set of processes either
consecutively or simultaneously. If simultaneous
processes are taking place, then multiple objects will be
active concurrently. Synchronizing
the activities of multiple active objects is difficult.
Implementation environments to support truly concurrent
applications are not widely available: it’s
difficult in C++, but it is supported in Ada (as tasks)
and in Smalltalk (as the super-class Process).
Example: The flight control system
of an aircraft might include object classes such as ENGINE
and RUDDER. To keep the aircraft flying safely, it must
be possible to manipulate both these objects
simultaneously and largely independently. Although
concurrent, these example objects will interact on
occasions (e.g. an engine failure might automatically
trigger a change in the rudder position).
|
Visible Advantage™
process maps show which activities must be executed in a
specific sequence and which can be executed in parallel
(if this is supported in the chosen environment).
If parallel processing is not supported, the
parallel process steps imply that processing sequence is
not important and can be optimized in the physical
implementation for system performance.
|
| Persistence: |
A
measure of the lifetime and location of the occurrence of
an object, including both an object’s state and its
class. Encompasses both the role of variables in
traditional application environments (such variables
usually live just during the execution of a program or
program module) and the domain of database technology
(which enables information, such as the state and class
of an object, to be retained between different executions
of a program). Object-oriented
DBMSs are in their infancy. Most practical implementation
environments coerce existing relational DBMSs toward the
needs of object-oriented application designs.
Example: When an object of class CUSTOMER places an order (defined as an object of
class ORDER), it will be necessary to keep a record of
the each instance of CUSTOMER and
ORDER until the order is filled, invoiced and paid
for.
|
All data
manipulated by processes must be a part of the data
model. It is assumed that all elements of the data model
will be stored and thus "persist". |
| Operations
or Methods: |
The
direct manipulation of an object, categorized as:
- Constructor: Create an
object and/or initialize.
- Destructor: Free the state
of an object and/or destroy the object.
- Modifier: Alter the state
of the object.
- Selector: Access and read
the state of an object.
- Iterator: Access all parts
of an object in a well-defined order.
|
The specific
DAPs created for an entity:
- Equivalent to Create DAP.
- Equivalent to Delete DAP.
- Equivalent to Update DAP.
- Equivalent to Read DAP.
- Equivalent to a Read DAP
that returns more than one occurrence for group
or iterative processing.
|
| Reusability
& Components: |
A
result of abstraction, encapsulation and modularity is
that:
- Object class definitions may be
stored, catalogued and maintained in an object
library.
- Reusable code modules, compiled as
binary files, are called components.
Components exhibit some of the characteristics of
‘objects’, such as encapsulation, but
do not necessarily exhibit other object
features, such as inheritance or polymorphism.
Example: Once the class CUSTOMER has been defined for an order-entry and
stock control system, it can be reused in the design of a
marketing system. The code component that displays the
input window for adding a new object of class CUSTOMER
can also be reused.
|
DAPs
represent re-useable processes that pertain to a specific
object. Business processes can
capture reusable subsets of logic that are invoked by
multiple other processes.
Example: In the CUSTOMER example, the Add Customer
process and CUSTOMER data structure(s) would be re-used in
current and future implementations.
|
Benefits of Object-Orientation
Object-orientation is perceived as providing
many benefits which, at least at a conceptual level, are
understood and seen as highly desirable by non-technical business
experts. Some of these benefits are:
- Reusability.
- Modularity.
- Avoidance of duplication.
- Reliability.
- Flexibility for expansion.
- Portability.
Information Engineering provides all of the
above benefits when used to generate logical data and process
models, but also provides two important additional benefits:
- Documented links between logical data and
process models and both the business requirements and the
physical design.
- Technology independence at the logical
design stage, linked to an optimized technology-dependent
physical design.
Implementing Object-Oriented
Methodologies
The use of either an OO or IE methodology
requires a major commitment of time and resources to the analysis
and design stages of a project. To organizations focused upon
traditional systems development techniques, this may appear as a
high-risk approach. The benefits of a ‘pure’ OO
approach will mainly accrue to the IS department within an
organization (reusability, easier maintenance and extensibility)
and may be difficult to sell to non-technical managers (such as
the end-users of a proposed system). The benefits of an IE
approach to the analysis stage of an OO project, which include
formalizing the linkages between the business requirements and
the final implemented systems, are more clearly visible and
desirable to non-technical managers.
Reusability is one of the strongest selling
points of object-orientation. It is perceived as one of the
rewards resulting from the extra time devoted to analysis and
design. Object libraries can be built from objects designed
during internal projects or purchased as ‘off-the
shelf’ commercial products. But there are practical problems
facing enterprises that establish and use such libraries:
- Reuse presents a cultural change in the
way developers operate.
- Reuse enforces standards when new objects
are created, which is likely to result in additional time
and cost compared with generating a ‘once-off’
solution. The performance pressures placed upon those
responsible for systems implementation usually focuses
upon the timely and cost-efficient delivery of new or
additional functionality to users, rather than offering a
practical incentive to generate reusable objects.
- At the same time, reuse can be perceived
by project managers as a loss of control, if most
development is done by pulling pieces out of a reuse
library.
- Locating the right object classes or code
components in the available libraries is not easy.
Organizations may need to establish a new group just to
manage reusable objects and enforce OO standards. The
operating cost of such a library is likely to be a
vulnerable overhead to the IS department.
- There is a danger that reusable code
components can become too large and generic to be
effective. A balance needs to be maintained to avoid code
components becoming generalized to the point at which
their use becomes inefficient or ineffective.
Re-engineering Legacy Systems
To reverse engineer legacy systems, with a goal
of systems integration in an object-oriented environment, is
difficult using just OO techniques, since the OO analysis and
design methodologies require a means of defining object classes
based upon ‘real world’ objects, rather than upon the
old, possibly inappropriate data structures inherited from the
legacy systems.
A combination of forward and reverse
engineering using the business-driven IE methodology and
Visible Advantage™ can resolve most of these problems,
by combining the reverse-engineered logical data and process
models of the legacy systems with an analysis of current business
requirements. This enhanced analysis can form a solid basis for
an object-oriented physical design.
Summary
Object-orientation and business-driven IE
should be regarded as symbiotic:
- IE can provide the leverage to gain the
benefits of an object-oriented approach to systems design
and implementation. The logical data and process models
resulting from an IE approach to a business requirement
are technology independent and reflect the business goals
of an enterprise. They can be subsequently revised,
amended and refined independent of the implementation
environment of any physical systems. If an
object-oriented application environment is chosen, the IE
data and process models provide a firm base from which an
object-oriented design can be developed.
- The concepts and terminology used to
describe the features of object-oriented analysis and
design are closely related to IE and the features of
Visible Advantage™.
- The perceived benefits of an
object-oriented approach are often quoted as being
reusability, modularity, avoidance of duplication,
reliability, and flexibility for expansion. IE also
provides these benefits, but extends them to include
technological independence and tightly defined links
between logical models, business requirements and
physical implementation designs.
Bibliography - Sources and Further
Reading
- Object-Oriented Analysis and Design
with Applications, Grady Booch, 1994
- Object-Oriented Modeling and Design,
Rumbaugh, Blaha, Premerlani, Eddy & Lorensen, 1991
- Object-Oriented Software Engineering,
Jacobson, Christerson, Jonsson & Overgaard, 1992
- Object-Oriented Information Engineering,
Stephen L. Montgomery, 1994
- Object-Oriented Analysis, Coad
& Yourdon, 1991
- Object-Oriented Design, Coad &
Yourdon, 1991
- Object-Oriented Analysis and Design,
James Martin & James Odell, 1992
- Distributed Object-Oriented
Data-Systems Design, Andleigh & Gretzinger, 1992
- Information Engineering: Strategic
Systems Development, Clive Finkelstein, 1992
- The C++ Programming Language,
Bjarne Stroustrup, 1991
Back to Contents.
This contains additional information
about the Object Oriented - Information Engineering analysis. It
consists of
Back to Contents.
Overview of the main object-oriented analysis
and design methodologies
See the Bibliography on the previous page for
references to supporting documentation for each methodology. Some
further references are listed at the end of this Appendix.
Booch
This is one of the original OO design methods,
which is now mature and widely used. Originally, this method
supported just OO design, but OO analysis has now (1994) been
added in a style similar to OMT (see below). This methodology has
a strong emphasis upon the definitions of classes and their
instances (objects). The notation defined by Booch is regarded as
very complete and the resulting class diagrams bear a strong
resemblance to IE data models.
The book [Booch, 1994] is highly recommended as
a readable, in-depth discussion of object-oriented concepts; it
also has a good glossary of terms and an extensive bibliography.
Rumbaugh - Object Modeling Technique (OMT)
OMT analysis is based upon three models:
- Object model, documenting entities,
attributes and their relationships.
- Dynamic model, a state-transition
diagram showing the reaction of objects in the system to
events.
- Functional model, a data flow
diagram (DFD), documenting the transformation of object
values and the constraints upon these transformations.
The use of the functional model DFD can be seen as a
separation of data and process which is inconsistent with
the focus of object-orientation, since processes (as
single icons) are not clearly linked with the operations
of a single object.
Now that Rumbaugh has joined Booch (at
Rational), the boundary between these two methodologies is likely
to become less clear. These methodologies are the ones favored by
developers using C++ as an implementation language.
Jacobson - Use-Case Analysis and
Object-oriented Software Engineering (OOSE)
Use-case analysis is described by Jacobson
[Jacobson, 1992] as:
- ... a particular form or pattern or
exemplar of usage, a scenario that begins with some user
of the systems initiating some transaction or sequence of
interrelated events.
This technique documents the scenarios
essential to a system’s operation, using storyboarding
techniques which identify the objects (along with the
responsibilities and interactions of the objects) needed to
participate in each scenario. The initial, basic scenarios are
later expanded to include exceptional cases. As well as helping
identify objects in context, which helps ensure an appropriate
level of abstraction, this technique can also identify scenarios
which can serve as the basis of future system testing. This
behavioral approach to the identification of objects is unusual
in both object-oriented analysis and IE.
Analysis will refine the resultant objects into
three types (interface, entity and control).
- Interface objects: Reflect the
external, user’s view of the problem domain.
- Entity objects: Reflect persistent
behavior. These tend to be the major reusable objects.
- Control objects: Capture behavior
specific to particular use cases. Avoiding mingling these
objects with interface and entity objects helps ensure
that control objects are reusable across multiple use
cases.
Analysis models may be further refined and
grouped into ‘subsystems’, which group functionally
cohesive objects together. The design phase of this methodology
includes a special model called the ‘interaction
diagram’, which is especially useful for designing
interactive software, and which reflects the roots of this
methodology in the telecommunications industry.
Coad/Yourdon
The main feature of this methodology is the
unification of the different object-oriented models within a
single conceptual structure on five layers: Subject; Class &
Object; Structure; Attribute; and Service. Each layer of the
conceptual model documents different types of things about the
objects, which is different to the majority of methodologies
which document process, data and data-flow in different diagrams
with different notations.
Martin/Odell - Object-Oriented Information
Engineering (OOIE)
Uses a notation which is designed to ease the
transition from Martin’s IE methodology to OO analysis. OOIE
adds new relationship types to the ‘conventional’
Martin IE methodology, which are believed to help in producing
views of the model at higher levels of abstraction for
presentation to business experts:
- Composition: Used to assist in the
abstraction of a data model by encapsulating other object
types. It is a "comprised of..." association.
An aim of this association is to define business
processes at a higher level of abstraction, where they
appear more meaningful to business experts, whilst
retaining the detail necessary to understand the
implementation of lower-level processes (DAPs).
- Generalization: Equivalent to the
conventional IE secondary/type associations, but extended
to include typing on the basis of behavior. This is used
to implement business rules within the data model.
OOIE also allows the inclusion of object instances
on the data model, where these will add clarification. It also
adds an information typing hierarchy, which can specify the
precision, formatting, permitted ranges and possible operations
which are valid for a declared ‘type’.
Additional notation is included to model the
effect of ‘events’. Events are classified as:
- External request or time
occurrence: Similar to existing IE business events.
- Process status event: The status of
a process (eg. process started) can itself act as a
trigger to another event
- Object state change event: When the
state of an object changes, an event is triggered.
Stephen Montgomery
Although not a formal object-oriented
methodology, Montgomery’s book ("Object-Oriented
Information Engineering") deserves a mention since, as is
implicit in its title, it attempts to combine IE (both the
Finkelstein and Martin flavors) with object-oriented analysis and
design. Montgomery’s approach is to use IE for business
planning and analysis, but to then generate an object-oriented
design from this base by mapping object classes onto IE entities,
and encapsulating the processes which act upon an entity within
the class definition. He generally refers to the Rumbaugh OMT and
Martin/Odell methodologies as a basis for comparison with IE. The
book is weak at discussing the boundaries between the IE and OO
approaches.
Montgomery presents a discussion of process
normalization. He recognizes that both IE and OO analysis can
produce normalized data models, and recommends that, using the IE
approach, the ‘basic processes’ which act upon entities
be uniquely defined and encapsulated with the entity. This
corresponds to the definition and use of DAPs within
Visible Advantage™.
Synthesized methodologies
The variety of object-oriented analysis
methodologies available suggests that it may be possible to pick
some of the best features from each, ‘blending’ them
into a new synthesized methodology which contains the best and
most appropriate features for a specific project or for a
particular organization. Concurrently, as the available
methodologies mature they are tending themselves to coalesce.
Examples of how methodologies can be synthesized include:
- Fusion, developed by
Hewlett-Packard, is a method that combines OMT [Rumbaugh,
1991], OOSE [Jacobson, 1992] and the Booch [Booch, 1994]
methodologies.
- The recent update to the Booch methodology
[Booch, 1994] has adopted some features from other
methodologies, such as use-case analysis [Jacobson, 1992]
and the object-state modeling notation shared with the
dynamic modeling phase of OMT [Rumbaugh, 1991].
- An organization may choose the best and
most relevant features from a group of different
methodologies, and use the resultant blend as its
in-house standard. Such a blend might include the
combination of OO techniques with IE.
The major difference between IE and OO is that
the techniques of OO analysis and design have emerged to support
the implementation of systems in OO programming languages, but IE
can capture and refine the business requirements for systems
independently of a particular implementation environment.
Conceptually, the objects in an OO design can be easily related
to ‘real-world’ things, but in practice the arcane
terminology and the multiple layers of most OO analysis and
design notations still leave a wide gap between non-technical
business experts and the system designers and implementors.
|
OO Penetration |
1994
|
1992
|
|
No plans for OO |
32%
|
8%
|
|
Planning for OO |
15%
|
16%
|
|
Exploring OO |
31%
|
47%
|
|
Developing using OO |
14%
|
20%
|
|
Production using OO |
8%
|
8%
|
|
Source: Gartner Group (ADM Research Note
T-899-1087) |
One of the major advantages of the
business-driven IE methodology is its tightly defined links
between business planning statements and the data, process and
design models. This bridges the gap between business experts and
system designers. The IE methodology can be used to document
business requirements in a form that can be subsequently
implemented in an OO programming environment.
A survey performed this year by the Gartner
Group identified little change since 1992 in the proportion of
organizations using OO for systems development and production,
and a decrease in the number of organizations exploring OO
methods. It is suggested that part of the apparent lack of growth
in enthusiasm for OO techniques is because organizations now
entering the OO arena tend now to be more conservative and
risk-averse, compared with the organizations embracing OO two
years ago as a cutting-edge technology.
The different object-oriented analysis and
design methodologies use a range of techniques to document and
implement business rules, and as yet there is no clear standard.
[Schultz, 1993] summarizes three methods by which business rules
can be captured and implemented in an object-oriented analysis
and design:
- Assign business rule information to
existing objects within the logical model, in terms of
additional behavior and state information. Although
simple, this can complicate otherwise elegant objects,
and decrease reusability.
- Assign the behavior and state information
to the application. Reuse of the rule is made much more
difficult using this technique.
- Create a new object which contains the
behavior and state information necessary to implement the
rule. Such an object may not have an intuitive connection
with the real world of the problem domain, but is likely
to be very reusable.
The final option above is similar to the IE
approach to rule modeling, in which a rule entity is created
which contains attributes which define the nature of rule.
Control links from the rule entity identify the entities which
control and controlled by the rule.
A major feature of version 7 of Visible Advantage™
will be a restructuring of its design phase. The enhancements
will change the present structure of data structures and data
items to design objects and relationships. The
types of design objects and relationships available will be
modifiable in user-defined, extensible lists. The types of design
objects would include data structures, menu objects, classes and
windows. The new design objects will encapsulate associated properties;
these properties can be defined as simple data items, methods, or
other data objects. The potential relationship types might
include the conventional data dependencies and new relationship
types such as "inherited by...", "has a...",
and "is a kind of...".
Diagrams and maps will be available in the
design phase. Templates can be established to allow object
hierarchies to be drawn, which would be equivalent to an OO map
of classes and sub-classes.
These new design features will allow logical
data and process models to be linked to object-oriented designs,
conventional relational designs, or both. They will move
Visible Advantage™ towards being capable of generating
detailed object-oriented or ‘traditional’ application
design specifications. For example, if a new type of data object
was defined, and linked to the logical business processes, all
the elements of an application design would be available from the
tool’s design phase (data objects, DAPs, business processes,
window specifications, menu structures and class hierarchies).
- Business Rules within Object-Oriented,
Ron Schultz, Database Newsletter, Volume 21 # 2,
March/April 1993
- A Comparison of Object-Oriented
Analysis and Design Methods, Mike Gilpin, Case
World, March 8-10, 1993
Back to Contents.
For more information concerning this Visible
Solution please contact:
North
America
Visible Systems Corporation
201 Spring Street Lexington MA 02421 USA
Phone: +1-781-778-0200 · Fax +1-781-778-0208
Web Site: http://www.visible.com
Email: mcesino@visible.com
|
Asia-Pacific
Clive Finkelstein,
Managing Director
Information Engineering Services Pty Ltd
PO Box 246, Hillarys Perth WA 6923 Australia
Phone: +61-8-9402-8300 Fax: +61-8-9402-8322
Web Site: http://www.ies.aust.com/
Email: cfink@ies.aust.com
|
|
