You are on page 1of 14

Reengineering Conventional Data and Process Models

with Business Object Models: A Case Study Based on


SAP R/3 and UML
Eckhart v. Hahn1, Barbara Paech1, and Conrad Bock2
1
Institut fr Informatik, Technische Universitt,Mnchen, D-80333 Mnchen,
eckhart.von.hahn@sap-ag.de, pech@in.tum.de
2
Intellicorp Inc. 1975 W. El Camino Real, Suite 201, Mountain View, CA 94040-2216, USA
bock@intellicorp.com

Abstract.Today, the business logic of complex business applications is typically


documented by separate data and process models. This documentation is adequate for
users to understand the functionality of the system. However, these models do not
reflect the business objects which constitute a flexible architecture for continuous
adaption to changes in the business processes. Business objects structure the business
domain model into independent units encapsulating business data and behaviour. In
this paper we describe a modeling technique for business objects and a procedure to
derive the business object model from conventional data and process models. In
particular, we show how to translate structured entity relationship models and event-
driven process chains into UML class and activity diagrams. We then show how to
enrich these diagrams with business object information.

1 Introduction

Complex business applications today typically consist of a database and a separate


layer to implement the functionality of the system. This layer may or may not be
object-oriented. In both cases the business processes are built into the layer such that it
is difficult to adapt this layer to changes. Therefore, business objects have been
suggested as a separate layer mediating between the database on the one hand and the
business logic on the other hand [Ren96]. Business objects structure the business
domain model into independent units encapsulating business data and behaviour
[BOM97]. However, there is no agreement yet on the contents and properties of
business objects. In this paper, a business object contains a set of logically related
classes (e.g. for order management) and all their instances.

The documentation (and implementation, of course) of existing systems does not


reflect this notion of business objects. First, the business logic is most often
documented from the viewpoint of a users. Therefore these documents do not show in
detail which data is affected by which operations. Second, data and behaviour are

T.W. Ling, S. Ram, and M.L. Lee (Eds.): ER98, LNCS 1507, pp. 393406, 1998.
Springer-Verlag Berlin Heidelberg 1998
394 E.v. Hahn, B. Paech, and C. Bock

typically separated into different models. Thus, in order to derive a business object
model, behaviour documented in the process models has to be integrated in the data
model. Third, business processes typically affect several business objects. Thus, the
behaviour described in the process models has to be divided between the business
objects.

In this paper we describe a modeling technique for business objects and a procedure
to derive the business object model from conventional data and process models. The
results have been gained within a case study based on SAP R/3 and UML [Hah98].
Thus, we started with structured entity relationship (SER) models and event-driven
proces chains (EPC). Since we aimed at an object-oriented model, we first translated
the SER models and the EPC into UML notation. The resulting diagrams are enriched
to reflect the distribution of the business logic over different business objects. Finally,
we integrated data and behaviour into business object models which are extended
UML class diagrams. While the translation of SER models and EPC into UML is
specific for SAP R/3 (or at least, these modeling techniques), the business object
model and its derivation from data and process models is applicable to all kinds of
business applications.

The paper is structured as follows: first we introduce the SER and EPC notation with
short examples. In section 3 we sketch the translation from SER models to UML class
diagrams. The translation from EPC to UML activity diagrams is discussed in section
4. Section 5 introduces business object models as an extension of UML class diagrams
and shows how to derive the business object model from the class and activity
diagrams. We conclude with a summary and outlook.

2 SAP R/3 Data and Process Models

SAP R/3 is divided into a hierarchy of high-level software components, each of which
represents a part of the overall business logic in terms of data structures and business
processes. These main components are Accounting, Logistics, and Human Resource
Management. Each of them is further divided into subcomponents. In the case of the
R/3 Logistics component, the subcomponents are for example Sales and Distribution,
Materials Management, Quality Management, Production Planning and Control, Plant
Maintenance. The components on the level below these subcomponents are called
business objects. However, they only capture data structure, not behaviour (see
[SAP96b] for an overview of the SAP R/3 structure). A similar, but different hierarchy
exists for business processes. There, the units below the subcomponents are called
business scenarios. They comprise several processes. Within the R/3 system,
structured entity relationship models [Sin88] are used to describe concrete data
structures of subcomponents. Processes are represented by event-driven process
chains [KNS92]. In addition to the above models, R/3 utility functions allow the
retrieval of the relationships between different business objects on entity type level.
Reengineering Conventional Data and Process Models with Business Object Models 395

Altogether, three different views on the software system are possible:


the Internal Static View: SER models show the entity types and their relationships
within one Business object;
the External Static View: R/3 utility functions yield the relationships between
business objects, derived from the relationships between the entity types of the
different business objects;
the Behavioural View: EPC display the behaviour of the system in terms of
business processes.
Within the present R/3 implementation, the static and the behavioural views are
separated, i.e. there are no model-inherent connections between SER models, business
object relationships or EPC. The reengineering efforts described in the following
sections therefore concentrate on an integration of the three views.

In the following we introduce the model elements of the three views with examples of
the SAP R/3 order mangement.

A SER model consists of An EPC consists of


Entity types; Functions,
Attributes: Entity attributes, Entity type Operators (logical AND, OR, XOR),
attributes; Events, and
Relationships: Process Paths as connectors between
- Hierarchical Relationships(H), different EPC.
- Aggregational Relationships (A),
- Referential Relationships (R),
- Cond.-agg. Relationships (CA),
- Cond.-ref. Relationships (CR), and
- Temporary-ref. Relationships (TR);
Specializations/ Generalizations;
Cardinalities of Relationships and Entity
types
Table 1. SER Model and EPC Elements

SER Model

Table 1 lists the elements of the SER model, which are used in the R/3 system. Add-
itional explanations of their definitions and use can be found in [SAP96a,Sin88]. The
SER model of Fig. 1 describes the structure of an Order with a header (entity type
"Order") and one or more Order Items. The Order itself may be arranged in an Order
Hierarchy. This additional entity type represents the child/parent relationship between
two different Orders. Thus, an instance of Order Hierarchy has two relationships to
two different orders, namely the child and its parent. In addition, an Order may have
Global Conditions (prices, discounts etc.) and may contain information about its
execution ("Order Operation"). An Order Item is either a Material, a Service or an
Outline Level and has a Schedule Line and optionally Billing Plan Dates as well as
particular Item Conditions.
396 E.v. Hahn, B. Paech, and C. Bock

O rd er
G lob al CR
C on d ition

O rd er O rd erItem
H
O p eration C on d ition

H H
O rd erItem
O rd er
B illin g P lan
A H ierarch y
H D ate
A

O rd erItem
O rd er H O rd erItem H S ch ed u le
Lin e

Material

S ervice

O u tlin e
Level

Fig. 1. A SER Model with Excerpts from the R/3 Order Management

EPC

Table 1 lists the elements of the EPC, which are used in the R/3 system. Additional
explanations of their definitions and use can be found in [KNS92]. A function
(denoted as a box with rounded angles) is a significant step in the advance of a
business process performed by the system either with or without user interaction. It is
triggered by one or more events and may result in one or more events. Events are
denoted as hexagonals. They may be the result of a preceding function or may be an
external stimulus. An operator (denoted by a small circle) connects events and
functions. A process path (denoted as box with added triangular) is a connector
between two EPC. In both EPC it serves as a placeholder for the respective other
EPC.
Reengineering Conventional Data and Process Models with Business Object Models 397

Order
Contract Notifi- Legend
Date due cation
arrived
XO Event
R

< name
>
Create Order

Function
Order
created
< name >

AND

Process Path
Determine Determine
Sold-to party Vendor
< name >

Sold-to
Order
party de- Operator
created
termined
Op

AND

Determine
Order Items

Order
Items de-
termined

Calculate Order

Order
calcu-
lated

Release Order

Order
released

AND

Order Goods
Confirmation Movement

Fig. 2. An EPC with Excerpts from the R/3 Order Management


398 E.v. Hahn, B. Paech, and C. Bock

The EPC of Fig. 2 describes an excerpt from the process of the R/3 Order Creation.
The process presented here starts with two external events, Contract Date Due and
Order Notification Arrived. Afterwards a new empty order is created with the Sold-to
Party and the Vendor to be determined. Additionally, the Order Items are determined,
the order is calculated and released by an employee. The process continues with two
process paths to Goods Movement and Order Confirmation, which are separate EPC.

Business Object Relationships

Business
Material
Partner

Order

Warehouse Conditions

Fig. 3. Relationships between Business Objects with Excerpts from the R/3 Order Management

Fig. 3 shows the external relationships of the business object Order to the business
objects Business Partner, Material, Conditions and Warehouse. Each line represents
one or more actual foreign key relations between a table (entity type) of the business
object Order and one from the associated other business objects.

3 Translation of SER Models into UML Notation

In this section we describe the translation of a SER model into an UML class diagram.
This translation serves as the basis for the business object models, since each business
object model will contain the classes covered by the business object. For definition of
UML class diagram elements we refer the reader to [Rat97].

The translation of the SER model elements into UML class diagram elements is
straightforward. We present the details in Table 2. Fig. 4 shows the result of the
translation of Fig. 1.
Reengineering Conventional Data and Process Models with Business Object Models 399

As mentioned in line 6 of Table 2, the associations corresponding to the aggregational


relationships do not capture all information. In particular, it is not possible to express
the existence dependency of the aggregational entity type (in this case Order
Hierachy) from the source entity types (in this case Order). The property {frozen}
only captures the fact that the relationships cannot be changed after being established.
The existence dependency would usually be expressed in UML by aggregation. This is
not possible for aggregational relationships in general, since the aggregational entity
type cannot be included in both source entity types.

SER model element UML Class Diagram element Comment

1 Entity type Class ---


2 Entity Instance (Object) ---
3 Entity type Attribute Class-scope Attribute ---
4 Entity Attribute Instance (Object) Attribute ---
5 Hierarchical Composition ---
Relationship
6 Aggregational Normal Association with Slight loss of information:
Relationship multiplicity 0..1 on target side see above
and property {frozen}
7 Referential Relationship Normal Association ---
8 Conditional- Normal Association with see 6
aggregational multiplicity 0..1 on source side
Relationship
9 Conditional-referential Normal Association with ---
Relationship multiplicity 0..1 on source side
10 Temporary-referential Normal Association with ---
Relationship explicit changeability
11 Specialization Specialization ---
12 Relationship Cardinality Association multiplicity ---
Table 2. Translating SER Model Elements into UML Class Diagram Elements
400 E.v. Hahn, B. Paech, and C. Bock

0..N O rd er
G lob al 0..1
C on d ition

0..N
0..N O rd er 0..N O rd erItem
O p eration C on d ition

0..N
O rd erItem
O rd er 0..N
B illin g P lan
0..1 H ierarch y
D ate

1
1 1..N 1 O rd erItem
O rd er O rd erItem 1..N S ch ed u le
1 Lin e

Material

S ervice

O u tlin e
Level

Fig. 4. An UML Class Diagram Corresponding to the SER-Model of Fig. 1

4 Translation of EPC into UML Notation

In this section we present a translation of the EPC into the notation of UML activity
diagrams. The later are advocated in [Rat97] as the adequate notation for business
process modeling. Swimlanes are not considered in this section. However, they play
an important role in Sect. 5.
Table 3 lists those elements of the UML activity diagram which are used below for the
translation. Further definitions and explanations of activity diagram elements can be
found in [Rat97].
Reengineering Conventional Data and Process Models with Business Object Models 401

An UML Activity Diagram consists of


Action states (Activities) - excactly one Start State:
Transitions;
Transition bars;
Decision operators.
Table 3. UML Activity Diagram Elements
The translation poses three problems: first, activity diagrams do not support
operators. We therefore extend UML by adornment of transition bars with operators.
Second, events are not allowed on transitions leaving activities. By looking at the EPC
in detail, we found that the events which follow the activities typically only capture
the completion of the activity. We therefore, decided to omit these events altogether in
the UML activity diagrams. Thus, only external stimuli are allowed as events in the
activity diagrams. Third, activity diagrams - as a special case of statechart diagrams -
do not allow events on transitions which join or fork, but only on the transition bar.
Since this situation occurs for external stimuli triggering the EPC and triggered by the
EPC (as exemplified in Fig. 2), we decided to extend UML in this respect. Given the
preliminary status of the activity diagrams at the time of the case study, these exten-
sion seemed to be reasonable.

Exclusive OR AND OR UML Translation

E1 ... EN E1 ... EN E1 . . . EN E1 EN
Op (AND |
XOR AND OR
OR |
F XOR)
1 F 2 F 3 F
1-3

4 F 5 F 6 F 5,6
F
XOR AND OR
Op (AND |
OR)
. . . E2 . . . E2 ... E1 EN
E1 E1 E1 E2

7 E 8 E 9 E 8 E
AND
XOR AND OR

F1 ... FN
F1 ... F F1 ... F F1 ... F
N N N

F1 . . . FN F1 . . . FN F1 . . . FN F1 ... FN

XOR AND OR Op (AND |


E OR |
XOR)
10 E 11 E 12 E 10-12

Fig. 5- Combinations of EPC Functions, External Stimuli and Operators and Their Translation
into UML
402 E.v. Hahn, B. Paech, and C. Bock

Figure 5 shows all possible combinations of functions, external stimuli and operators
in EPC and their corresponding UML translation. Cases 7 and 9 are not allowed, since
they are nondeterministic with regard to the selection of the following functions. Case
4 is translated into an UML decision operator. This is not shown in the table for
reasons of space.

O rder
C ontrac t
N otific atio n
D ate due
arrived

XO R

C re ate O rder

AND

D e term ine D e term ine


S old -to party V endo r

AND

D e term ine
O rder Item s

C a lculate O rder

R e lease O rder

AND

O rder
G oods M ovem en t*
C o nfirm atio n*

Fig. 6. UML Activity Diagram Corresponding to Fig. 2


Reengineering Conventional Data and Process Models with Business Object Models 403

Altogether, we use the following extensions of UML activitiy diagrams:


Transition bars are adorned with XOR, AND or OR labels to show the logic of the
branching.
Decision operators represent Exclusive OR branches (XOR).
External stimuli are allowed as adornments to transitions which join or fork..
An asterisk on an activity denotes a former EPC Process Path and connects an
activity-like placeholder of one activity diagram with the same placeholder
contained in a different activity diagram.

Figure 6 shows the UML activity diagram resulting of the translation of Fig. 2.

5 Integrating Structure and Behaviour within Business


Object Models

In this section we present the business object model as well as its derivation from class
and activity diagrams. The most important step in this derivation is the introduction of
swimlanes into the activity diagrams which make explicit the business objects the
activities are assigned to. Since this assignment is not included in the EPC, it has to be
derived a posteriori. The business object relationships diagram introduced in Sect. 2
shows all the partner business objects which are candidates for the assignment.The
choice of the right candidate for each activity could only be done by domain experts,
since this assignment is not documented in any existing model of SAP R/3. As a rule
of thumb an activitiy is assigned to the business object which either provides most of
the needed input data or which can be made responsible for the correct execution of
the particular functionality. Activities which clearly denote manual user input without
system intereference such as "Enter Order schedule lines" or "Release Order" are
assigned to an artificial business object "User".

Fig. 7 shows an UML activity diagram with swimlanes consistent with Fig. 6.
404 E.v. Hahn, B. Paech, and C. Bock

O rder B usiness P artner M aterial C ondition U ser W arehouse

O rde r
C ontract
N otificatio n
D ate due
arrived

C re a te O rd e r

AND

D e te rm in e
S o ld -to p a rty

D e te rm in e
V endor

AND

D e te rm in e
O rd e r Ite m s

C a lcu la te O rd e r

R e le a s e O rd e r

AND

O rd e r
G o o d s M o ve m e n t*
C o n firm a tio n *

Fig. 7. UML Activity Diagram with swimlanes, transformed from Fig. 6

The assignment information of these activity diagrams is used to integrate class and
activity diagrams into business object models. Business object models are used to
represent the classes covered by the business object and the behavioural dependencies
on other business objects. A business object model therefore is a class diagram rep-
resenting the classes (data and behaviour) encapsulated by the business objects and
the relationships to other business objects. Therefore, the class diagram is extended
with specialized objects representing partner business objects (denoted by boxes with
a small box on top) and with labels on the associations to the partner business objects
denoting operation calls to the classes of the business object. These calls may be
realized with the open Business Application Programming Interfaces (BAPI) of SAP
where the partner business objects collects all the relevant BAPI. The operations cor-
respond to the activities of the activity diagrams. Activities which are assigned to the
main business object are associated as operations to the corresponding internal class.
Again, the assignment of operations and operation calls to classes within the business
object has to be done by domain experts.
Reengineering Conventional Data and Process Models with Business Object Models 405

Fig. 8 shows the business object model for Order integrating Fig. 3, Fig. 4 and
Fig. 7.

B u sin ess O b ject "O rd er"


C a lc u la te O rd e r()
Con d ition s
0..N O rd er
G lob al 0..1
Con d ition

0..N
0..N O rd er 0..N O rd erItem
O p eration Con d ition

0..N
O rd erItem
O rd er 0..N
B illin g P lan
0..1 Hierarch y
Date

1
1 1..N 1 O rd erItem
O rd er O rd erItem 1..N S ch ed u le
Lin e
1
G o o d s M o v e m e n t*()
C re ate O rde r()
O rd erC o nfirm a tio n*()
W areh ou se

Material

D e te rm in e O rd e rI te m s ()
D e te rm in e S o ld -to P a rty ()
S ervice
D e te rm in e V e n d o r()
R e le a s e O rd e r()

O u tlin e
Level

B u sin ess
Material
P artn er
User

Fig. 8. Business Object Model integrating Fig. 3, Fig. 4 and Fig. 7

6 Conclusion
The introduction of process integrating business objects requires the reengineering,
respectively the evolution, of existing systems and their documentation. In particular,
the classes covered by the business object have to be identified, and the business logic
has to be distributed over the business objects. In the case study, the classes covered
had already been determined. The emphasis therefore was on the distribution of the
business logic. To make the distribution explicit, we have introduced the notion of
business object model. Based on two preliminary steps which translate data models
into class diagrams and process models into extended activity diagrams, we have
introduced an assignment of activities to business objects. This enabled us to identify
the operations and dependencies of the business objects.
406 E.v. Hahn, B. Paech, and C. Bock

Reengineering of the documentation is clearly only a first step. It is necessary in order


to explore different business object architectures. For implementation, one can
eventually use the standard issued by the OMG [BOF96].

Acknowledgements. We would like to thank Dietmar Nowotny for his continuous


feedback on earlier versions of this work.

References
[BOF96] Object Management Group, Common Facilities RFP4, Common Business Objects
and Business Object Facility, OMG TC Document CF/96-01-04, 1996
[BOM97] Object Management Group, Business Object DTF, Common Business Objects,
bom/97-12-04, Version 1.5, 1997
[Hah98] E. von Hahn: Development and Utilization of an Application Pattern
Demonstrated on the SAP R/3 Order Management, Master Thesis, Computer
Science,Technical University Munich, Germany, February 1998
[KNS92] G. Keller, M. Nuettgens, A.-W. Scheer: Semantische Prozemodellierung auf
der Grundlage Ereignisgesteuerter Prozeketten (EPK), Verffentlichungen des
Instituts fr Wirtschaftsinformatik, Heft 89, Saarbrcken 1992
[Rat97] UML 1.1 documentation, Rational INC, http://www.rational.com/uml/
[Ren96] D.S. Renshaw, Application Model Trends in Distributed Object Systems,
OOIS96, pp.506-514, Springer, 1996
[SAP96a] Data Modeling with the Data Modeler, SAP Documentation R/3 System Release
3.0, SAP AG, 1996
[SAP96b] The SAP Information Model. Model supported Information Management in the
System R/3, SAP Method Manual, SAP AG, 1996
[Sin88] E.J. Sinz: Das Strukturierte Entity-Relationship-Modell (SER Modell),
Angewandte Informatik 5/88, pp.191-202, Vieweg Verlagsgesellschaft, 1988