OOPSLA'98 Business Object Workshop IV

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

Abstract

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, Software Engineering.

Workshop Goals: Contact to other people in BOs, discussing experience in using existing BO approaches.

1 Motivation

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 [JGJ97].

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].

Entity BOs: 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.
Process BOs: 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:
Service BOs: 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.
CDL Details: 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:

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?

References

[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, 1998.

[Hor98] Wiebe Hordijk. CDL specification of a break planner application. Internal Report - Institut für Informatik, TU München, 1998.

[IBM98] IBM. San Francisco Extension Guide. http://www.ibm.com/java/SanFracisco, 1998.

[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 T_EX by T_TH, version 1.46.