Working with Business Objects: A Case Study
W. Hordijk, S. Molterer, B. Paech, Ch. Salzmann
Institut für Informatik
Technische Universität München
80290 München, F.R.G.
(hordijk / molterer / paech / salzmann)@in.tum.de
In this short paper we report on the first steps of a case study on
the usage and adaptability of business objects (BOs). This toy-world scenario
is the first stage of a study for a German automobile company to evaluate
business objects especially from the reuse perspective. Therefore we transfer
a well known example - a time-planner - from UML to CDL, realize it on
the basis of IBMs SanFrancisco and take a critical look at the resulting
benefits of BOs against ordinary OO techniques.
Keywords: Business Objects, Reuse, Components,
Workshop Goals: Contact to other people in BOs,
discussing experience in using existing BO approaches.
In this short paper we report on the first steps of a case study on the
usage and adaptability of business objects (BOs). This case study is part
of a cooperation with a German company that wants to reengineer a number
of information systems used by the engineers through BOs. Since there are
no BOs for the specific business processes supported by the information
systems available, the central IT-department aims at building its own BOs
based on existing base classes as can be found e.g. in IBM San Francisco.
To gain experience with BOs a case study was started. In particular, the
aim was to evaluate the claims on ease of (re-)use and adaptability of
BOs. Firstly, several usage constraints for BOs were identified. Based
on that an existing case study dealing with the planning of break supervision
in a school (previously used to evaluate UML [BRS98]) was adapted. The
analysis model was specified using the evolving standard for BO specification,
BOCA CDL ([OMG98]). In the momentthis model is being refined to a design
model based on IBM San Francisco Utilities and then it will be implemented.
In this paper we describe the constraints, the resulting scenarios of the
case study and summarize our experiences with modeling in BOCA CDL.
2 Constraints on Business Object Usage
We identified a set of constraints, that in our opinion will be relevant
for the future usage of BOs in the enterprise environment:
The most important business objects are common to several business contexts.
It is desirable that these are identified as early as possible. However,
there will always be a need of including business objects which have been
developed in different business contexts.
An adequate granularity for the units of reuse must be identified - BOs
corresponding to single classes are generally too fine grained.
Changes in workflows should only require local changes in the system. Thus
Process BOs gain an important status for modeling workflows.
Some third party business objects have to be aquired and adapted to the
company needs and to the specialized inhouse developments.
Some business objects will be developed within the company and therefore
be very specific. That gives further challenges in integrating them into
existing BO frameworks.
BOs will be used as parts of application systems which deliver specific
functionality to the end users. Thus, there has to be a clear distinction
between BOs, BO systems which group related BOs, and application systems
which make use of the BO systems, but are not subject to reuse themselves
3 The Scenario
We chose an example scenario, which has been previously used to illustrate
the benefits of OO design and specification techniques, e.g., UML [BRS98].
This allows us to evaluate the benefits of a BO based approach against
the well documented results of the classical OO approach.
The basic scenario is as follows: In a school at several locations breaks
have to be supervised, such that for each break and location a teacher
is present. A teacher may have certain exclusion times where s/he can not
be present. The mission is to design an application system that supports
the school in scheduling the break supervision.
To be able to evaluate the workflow support of BOs, we stipulated an
exemplary workflow for the planning task: After generating plans for each
location, the plans are combined and tuned into a resulting schedule. This
schedule has to be approved by the teacher's union, in case some teachers
have to work over-time. For the case of disapprovement, the head of school
can vote the union down. Otherwise, the schedule has to be tuned again.
This process is shown in figure 1 as an activity-diagram.
To be able to evaluate the reuse support of BOs, we stipulated the following
scenario for the development of IT-support at the school: The planning
component is acquired by the school from a component vendor, that produced
it as a general component to be adapted by different companies for their
planning purposes. This component supports the generation of plans based
on given Resources and Timeslots. It only includes a very limited workflow.
The adaption requires specialization of the Entity BOs of the component
as well as the addition of further Process BOs according to the workflow
associated with break planning. It also requires the design of the functionality
and the user interface for the break planning system. After some time the
school decides to buy a teacher administration system and now needs to
integrate the existing break planning BOs with the BOs of this system.
In particular, the administration of teachers in the break planning system
has to be done by the new administration system and the payment of teachers
in the administration system depends on information on supervised breaks.
Figure 1: The workflow activity diagramm
4 Experiences with BOCA CDL
In the following we sketch the specification of the analysis model of the
case study and our experiences with CDL. The details can be found in [Hor98].
We have identified Plans and Resources as the Entity BOs of the generalized
planning component which are specialized to BreakPlans and Teachers for
the school application. TimeSlots and ExclusionTimes are Dependents. This
was straightforward. Some difficulties in the detailed specification of
the operations of these BOs are collected at the end of this section.
The workflows associated with planning were modeled as separate Process
BOs. The use of state-sets was very convenient for modeling the different
stages of the workflow. In particular, the specialization of the general
Planning Workflow consisting of the stages Edited, In_Operation
to the specialized Break Planning Workflow was elegantly captured by refining
the state sets using the DURING-construct. Compared with UML the expressivitiy
of state transitions in CDL has some minor flaws:
CDL state transitions do not have an action part.
Run-time properties that are true during states, such as attribute values
or constraints on states of related types, cannot be modeled.
If there is a state set with states a and b, where b has substates c and
d, and c is the initial state of b, then a state transition from a to d
cannot be defined.
Operations, which affect several BOs, but do not have intermediate states
were modeled as separate Entity BOs. For ease of change, these operations
should not be associated with one of the affected BOs. On the other hand,
without states they should not be modeled as Process BOs. The meta-model
of CDL does not give any guidance in how to model these operations.
Business System Domains
The Break Planning and the Administration system constitute two different
Business System Domains. The Teacher BOs of both BSDs are related through
Adapters. This construct is very convenient to express the integration
between separately developed BSDs, however the semantics is not fully clear.
There are a few technical details about CDL which either need some more
work or have not been discussed clearly enough in the proposal [OMG98].
Some of these have been mentioned above, here are a few more, without any
intention of being complete:
In the set operations exists, select and forAll,
only one iterator can be used.
There is no predefined relationship keyword for 1-1 relationships.
There is no explicit time concept defined.
It is not clear whether an entity can inherit a dependent.
5 Open Questions
Finally, we collect the major questions we have encountered in the first
steps of the case study for discussion at the workshop. These relate to
the analysis model sketched above, as well as to the first design considerations.
For reusability it is important to have a hierarchy of reusable assets,
where each level serves a specific reuse purpose. In particular, it is
important to be able to group related BOs as reuse units and to distinguish
between reusable assets and applications. The latter must deliver a specific
functionality to the end user and are not reusable as such, while the former
are important for the system developer. It is not clear, whether BOCA business
system domains should be viewed as a reusable group of BOs or as a set
of BOs extended to an application.
BOCA assumes each BO to be a CORBA object. While it is convenient to use
the CORBA services for the BOs, the overhead is considerable, if e.g. each
Teacher is administrated as a CORBA object. It should be possible to group
BOs (of the same type or different type) such that CORBA communication
is not used inside the group.
According to the San Francisco Extension Guide [IBM98], IBM San Francisco
is tuned to allow incremental extension and specialization. The support
for integration with other BO systems is not clear. In particular, IBM
San Francisco offers categories to group BOs. Are they the correspondents
of BSDs? Is the Adapter concept of CDL supported in San Francisco?
[BRS98] K.Bergner, A.Rausch, and M.Sihling. A critical
look upon UML. In M. Schader and A. Korthaus, editors, The Unified Modeling
Language - Technical Aspects Physica Verlag, A Springer Verlag Company,
[Hor98] Wiebe Hordijk. CDL specification of a break
planner application. Internal Report - Institut für Informatik, TU
[IBM98] IBM. San Francisco Extension Guide. http://www.ibm.com/java/SanFracisco,
[JGJ97] I. Jacobson, M. Griss, and P. Jonsson. Software
Reuse: Architecture, Process and Organization for Business Success.
Addison Wesley, 1997.
[OMG98] OMG. Business object component architecture (BOCA). Proposal,
revision 1.1 - OMG Document bom/98-01-07, 1998.
File translated from TEX by TTH,