object-oriented systems: from conception to...

OBJECT-ORIENTED SYSTEMS:

FROM CONCEPTION TO

DELIVERY

Prof. Dr. Guido DEDENE

Ms. Annemie DEPUYDT

Drs. Monique SNOECK

Prof. Dr. Maurice VERHELST

Katholieke Universiteit Leuventhe Leuven Institute for Research on Information Systems

Dekenstraat, 2B-3000 Leuven

Fax 00 32 16 28 57 99

E-mail MAAUM01 @ CC1.KULEUVEN.AC.BE

Presented at OBJECT TECHNOLOGY 94Oxford U.K. March 1994

Abstract

This paper gives a schematic overview of the building of Object-Oriented systems, covering Object-Oriented BusinessModeling, Information Modeling and Implementation Modeling. The components of Object-Oriented Business Models arediscussed in detail, including consistent versus elementary Business models. A simple CAR-RENTAL model is used toillustrate the concepts. Next it is shown how Information Objects can be constructed around a Business Model. In contrast toearlier appraoches, the use of data stream connections between Business and Information Objects is avoided. The options forimplementing Object-Oriented systems are Event-based versus Object-based. Event-based implementations can be performedon traditional technology by means of Object Dismemberment. Object-based implementations have variations on thelocalisation of the Business Rules.A solution package is available as an appendix.

Keywords

Model-driven - Object-Oriented - Event-driven - Entity-Relationship - Systems Development - Software Development -Jackson Systems Development - Software Methodology - Business Modeling - Information Modeling - System Implementation.

0. INTRODUCTION

2

Too many organisations today still underestimate the importance of Object-Orientation in systemsdevelopment [MEYER 1988, DEDENE 1991]. Reasons for this may vary from ignorance, inertia,confusion and fear for integration with the systems development traditions and legacy systems.

The main goal of this paper is to give guidelines to actually deliver Object-Oriented systems. Withoutemphasis on the underlying theory the example of a simple Car-Rental Business is taken as a bootstrap toshow the development steps to build an Object-Oriented system. The M.E.R.O.DE. approach [DEDENE1993a] is taken as a guideline for the development, although most elements of this paper are alsoapplicable to other OO-methodologies.

A key element in delivering Object-Oriented systems is the proper handling of abstraction levels in themodels that are involved [ZACHMAN 1987]. As pioneered by the J.S.D.-methodology, the modeling ofBusiness Functioning allows to construct a solid nucleus for a software system [JACKSON 1983]. Thecomplexity of most systems is driven by the complexity of the reality that it has to deal with. Hence itmakes sense to model this reality first, before doing other development steps.

Information (or Function) modeling can be done around a Business Model, whereby the Business ModelObject Classes act as "information centers". Information Object Classes model the information functionsin a system. These functions take care of Input, Output and Control operations around the BusinessModel. Management (or Executive) Information Functionality is also enabled by this type of ObjectClasses.

A stiff confusion persist in literature about these levels of abstraction in model-driven development.Business Modeling is not the new term for Systems Analysis, which was traditionally the specification of"What" a system should do. Also Information Modeling is not the new term for Systems Design, whichfilled in "How" a system should function. Consequently Object-Oriented Business Modeling should notbe confused with Object-Oriented Analysis, and Object-Oriented Information Modeling is not just Object-Oriented Design. The following diagram positions the terminology somewhat.

BUSINESS

MODELING MODELING

INFORMATION

ANALYSIS

DESIGN

WHAT ?

HOW ?

Functioning of theBUSINESS

Functioning of theInput, Output, Control, ...

Remark that this schema also indicates how components from different OO-methodologies can be used tobuild the complete specifications of an Object-Oriented System.

3The traditional waterfall approach, whereby implementation only comes after Analysis and Design canalso be given up in building Object-Oriented Systems. Nothing prevents developers to implementBusiness Models directly after their specification. In fact, it is the hope of many developers that theimplementation step becomes more and more transparent (for example, by using Object-Oriented run-time environments for Object-Oriented specifications).

This paper is organised such that it discusses the implementation of Business Model Object Classesimmediately after their specification. The implementation of Information Object Classes can follow thesame Guidelines.

A very rich element is the flexibility about implementation options. It will be shown how actuallydevelopers still have full freedom in implementation technology choices. People that wish to stay with3GL and traditional DBMS can go on using this technology for implementation. Nothing prevents themhowever to use Object-Orientation at higher abstraction levels, for Business and Information Modeling.On the other hand, Object-Oriented Technology is not so mature yet that it allows transparentimplementations. In particular support for the localisation of the Business Rules, and the guarding ofsynchronisation and consistency are not trivial.

1. BUILDING AN OBJECT-ORIENTED BUSINESS MODEL

The purpose of this chapter is to give a schematic overview of the components of an Object-OrientedBusiness Model, constructed along the guidelines of the M.E.R.O.DE.-approach.

1.1 The BUSINESS MODEL overview

The following scheme gives an overview of the components of an Object-Oriented Business Model.

Behaviour

Methods

Information

Attributes

OBJECT

Object-Event-

Participation

Business Rules

Reaction : OK or REJECTEVENT

4

1.2 Object-Relationship Models and Object-Event-Participation Table

The relationships amongst object classes are based on existence dependency. Additional cardinality can beindicated (one-to-many versus one-to-one)

OBJECT CLASS A

OBJECT CLASS B

Object Classes participate to Event Types. The Participation Matrix or Table must be consistent with theObject Relationships. In particular, subsets correspond to existence dependencies.

Event Type 1

Event Type 2

Event Type 3

Event Type 4

Event Type 5

Event Type 6

C

X

X

X

X

E

C

X

E

Object Class A Object Class B

In this table, C denotes a Creator Event Type, X a Mutator Event Type and E a Terminator Event Type.

1.3 Object Attributes

Key-attributes

Allow to identify uniquely instances of object classes

Foreign Key-attributes

Are in accordance with relationships amongst object classes

State attributes

5

Are involved in the Finite State Machine representation of dynamic event rules

Other attributes

Strictly, only those attributes should be incorporated which are involved in some business rules (orconstraints).

As a rule, the Object Class name is used as a prefix in the names of the attributes.

1.4 Event Attributes

Allow to identify unique instances of Event Type instances. As a rule, the Event Type name is used as aprefix in the names of the attributes.

1.5 Object State Vector

The set of all Object attributes constitute the Object State Vector.

1.6 Event Types

Are described by a name per Event Type and the corresponding Event Attributes

1.7 Existence Dependency

This arises as soon as an object class can only live within the context of the live of another object class.Existence Dependency is the only allowed relationship type between object classes. All other relationshipsmust be reduced to existence dependencies, for examples, by means of instantiations of many-to-manyrelationships. A synomym for existence dependency is "Marsupial" object. Existence dependencies areclear from the event-participation: existence dependent object classes correspond to subsets of eventtypes.

OBJECT CLASS A

OBJECT CLASS B

6

Event Type 1

Event Type 2

Event Type 3

Event Type 4

Event Type 5

Event Type 6

C

X

X

X

X

E

C

X

E


If an Object Class B is existence dependent on an Object Class A, each Object of Class B has a mandatoryrelationship with exactly one Object of Class A. Moreover the set of Event Types to which B participatesis a subset of the set of Event Types to which A participates.

1.8 Object Classification

Existence Dependency induces a partial ordering relation on Object Classes. The classification of ObjectClasses according to this ordering can be represented by a Lattice-based representation. In the followingdiagram, D is existence dependent on A and B, while E is existence dependent on D and C.

A B C

D

E

Cardinalities of the existence dependency relationships are not represented in the ordering diagrams. AnObject Class is called a Bottom-Object for an Event Type if it is a minimal element in the classificationof all the Object Classes that participate to that Event Type.

1.9 Business Rules

Three kinds of rules or constraints can be imposed on Object Classes and Event Types. They all determinewhether a Business Event can be accepted by the Business Model. Business Rules can basically begrouped by Event Type.

7Business Event Sequence Constraints

These are constraint types in which Event Types within one Object restrict the occurrences of other EventTypes. Various alternative equivalent expressions exist for these type of Business Rules. The followingare some examples of them.

Jackson Structure Diagrams

Event Type 1 Event Type 4


*

° °

An equivalent expression is given by the Finite State Machines, which explicitely model the states andstate transition.

Finite State Machine.

1

E

Event Type 1

Event Type 4


Regular Expression

OBJECT = Event_Type_1 . [Event_Type_2 + Event_Type_3]* . Event_Type_4

It is important to realise that this type of rules represent actually pre-conditions based on the "state" of anObject. It is also possible to formulate these constraints explicitely as Event Type pre-conditions. Anexample is the following:

8Event_Type_2 : Object_A.State = "1"

Perhaps the most exciting feature of these type of rules is the fact that they "follow" the classification ofBusiness Objects according to the existence dependency. The formal expression is the following:

An Object Class B is existence dependent on an Object Class A if and only if

Regular_Expression_B + Regular_Expression_A \ B = Regular_Expression_A \ B

whereby Regular_Expression_A \ B is the regular expression of Object Class A whereby every EventType in the Object Class A to which Object Class B does not participate is replaced by 1, the neutralelement for the sequence structure operator, indicated by the .-symbol. An example is the following.

If A = E1 . [E2 + E3]* . E4 and B = E2 . E3, then

A \ B = 1 . [E2 + E3]* . 1 = [E2 + E3]*

This allows a bottom-up approach to the construction of the Business Event Sequence Constraints. Thiskind of comparision of Business Rules accross Object Classes is typical for the M.E.R.O.DE.-approach.

Referential Integrity Constraints

An Object can only be created if all Objects on which it is existence dependent exist already. This isusually clear from the Business Event Sequence Constraints.

On the other hand, an Object can only be removed if all Objects that are existence dependent are removed.This is indicated by the = 0 symbol in the Event Participation Table. Alternatively, it can be stated that anObject cannot evolve to its last state if all existence dependent Objects are not in their last state. This typeof constraint can also be indicated by the = E symbol in the Event Participation Table.

Again these constraints can also be expressed as pre-conditions, as follows.

Event_Type_6 : All Object_B(Object_B.Object_A-id = Event_Type_6.Object_A-id).State = "E"

Object Attribute Constraints

This type of Business Rules emerges when other attributes than the "state" form pre-conditions for otherEvent Types. In other words, whenever other features of an Object than the state-trace of the occurrenceof an Event Type restrict another Event Type. This type of rule is expressed by means of

- the indication of the Event Type within the Object Class- the conditions that contain Object Class attributes which constrain the Event Type.

These conditions may involve Event attributes as well as Object attributes of all the Object Classesinvolved in the rule. Graphically this can be represented by enumerating this type of rules and attachingthem by means of "flags" to the involved Business Object Classes.

An example could be the following:

Event_Type_3 : Object_A.Attribute_4 = 1 & Object_B.Attribute_2 = 0

9This rule involves two object classes. For simple models, a graphical aid can be used to indicate this in theObject Relationship diagram. Assuming that this rule is numbered as R12, the Object-Relationship-diagram is "flagged" as follows:

OBJECT CLASS A

OBJECT CLASS B

R12

R12

1.10 Business Object Abstract Data Types

The final visualisation of the effect of a Business Event Type on an Object Class is documented in theAbstract Data Type. The Abstract Data Type contains

- The state vector of the Object Class- A Method for every Event Type to which the Object Class participates

A method for a Business Object Class is a set of operations on Object attributes, using Object as well asEvent attributes. For example, the method for the creation of an Object Class will initialise all the Objectattributes. The general layout of an Abstract Data Type is as follows.

Object Class NameObject State Vector

Object Methods

1.11 Generalisation/Specialisation

An Object Class can use other super-classes to define itself. A subclass Object is always existencedependent via a 1-to-1 existence dependency relationship. Single Inheritance occurs when a subclass isdependent on one single Object Class.

10

Super - Class

Sub - Class

Observe that the Generalisation can still be optional or mandatory. In case an Object Class is existencedependent on multiple Object Classes, multiple inheritance occurs.

Sub - Class

Super - Class A Super - Class B

When multiple subclasses are present for a single superclass, additional indications on mutual exclusion,possible inclusion or even mandatory completeness can be given, as follows.

Sub - ClassA

Sub - ClassB

Sub - ClassA

Sub - ClassB

Sub - ClassA

Sub - ClassB

XOR IOR AND

Super - Class Super - Class Super - Class

1.12 The CONSISTENT versus the ELEMENTARY BUSINESS MODEL

In order to facilitate the communication with end-users, it may be usefull to introduce a relaxed form ofthe Business model construction described so far. This form will be called "CONSISTENT", as it alsoallows to group some elementary Event Types. All mathematical consistency checks are performed on theElementary Business Model. The Elementary Model act as a kind of "normalised" Object Model.

These are the rules for the CONSISTENT Business Model:

C1: Redundancy in rules is allowed.

C2: There may be multiple Event Types which act as Creators or Terminators for Object Classes.

C3: The following relationship types are allowed:

11C4: In case two or more Bottom-Objects exist for an Event Type, these Bottom-Objects react together tothis Event.

C5: A Consistent Event Type consists of one Elementary Event Type, or a sequence of Elementary EventTypes.

As an example: the consistent Deletion of an Order consists of the elementary Deletion of all the Order-lines, which are existence dependent on that Order, followed by the elementary Deletion of that Order.

Consistent Event Types represent the actual triggers from the real world, which will later be implementedby means of Input Transactions.

The ELEMENTARY Business Model is a refined Business Model that satisfies the following rules.

E1: Redundancies are removed, sometimes by the introduction of new elementary Event Types.

E2: Every Object Class has one and exacly one Creator and Terminator elementary Event Type.

E3: The following are the ONLY relationship types that are allowed:

E4: For every elementary Event Type there is exactly one Bottom-Object. If necessary, a consistent EventType with multiple Bottom-Objects is splitted into elementary Event Types.

E5: Elementary Event Types are the building blocks for consistent Event Types, which consist of at leastone elementary Event Type.

2. THE CAR-RENTAL BUSINESS MODEL EXAMPLE

A simple Car-Rental example is used to illustrate the actual format of the M.E.R.O.DE.-specifications foran Object-Oriented Business Model. The reality that should be represented by this model is summarisedby the following observations on the "real world".

a. A Car-Rental company acquires cars, rents them to customers.

b. A person becomes a customer at the moment when he/she rents a car for the first time.

c. A customer can never have more than one car in rent at the same time.

d. A rental is paid after the car is returned.

e. A customer needs to have a name, an address, a zip-code and city. These details can be changed at anymoment.

f. The business life of a car can only finish if all rentals for that car are paid. It is outside the scope of thissystem to model what happens in that case to the car.

2.1 The Object-Event Table and Object Relationships

12

C

X

X

X

CUSTOMER CAR RENTAL

Cr-Customer

Cr-Car (=Acquire Car)

Rent

Return

Pay X

C

X

X

E

C

X

E

Ch-Customer X

End-Customer E

End-Car = E

= E

The following shows the Object Classes and their relationships. Discuss the cardinalities of therelationships.

CUSTOMER CAR

RENTAL

2.2 The Business Event Sequence Constraints

RENTAL

RENT RETURN PAY

13

CUSTOMER

CR-CUSTOMER

*

° ° ° °RENT RETURN PAYCH-CUSTOMER

END-CUSTOMER

CAR

CR-CAR

*

° ° °RENT RETURN PAY

END-CAR

An alternative representation for the CAR Object Class can be developed, which incorporates the fact thata CAR can only be in rent once at the same time (hopefully !).

2.3 The Event Attributes

Cr-CAR : Cr-CAR-CAR-id, Cr-CAR-TS

Cr-CUSTOMER: Cr-CUST-CUST-id, Cr-CUST-CUST-name, Cr-CUST-CUST-address, Cr-CUST-CUST-zip, Cr-CUST-CUST-city, Cr-CUST-TS

Ch-CUSTOMER: Ch-CUST-CUST-id, Ch-CUST-CUST-name, Ch-CUST-CUST-address, Ch-CUST-CUST-zip, Ch-CUST-CUST-city, Ch-CUST-TS

14End-CUSTOMER: End-CUST-CUST-id, End-CUST-TS

End-CAR: End-CAR-CAR-id, End-CAR-CAR-TS

Rent: Rent-CUST-id, Rent-CAR-id, Rent-RENTAL-id, Rent-TS

Return: Return-CUST-id, Return-CAR-id, Return-RENTAL-id, Return-TS

Pay: Pay-CUST-id, Pay-CAR-id, Pay-RENTAL-id, Pay-amount, Pay-TS

2.4 The Abstract Data Types

The following is the abstract data type for the RENTAL Object Class.

OBJECT CLASS RENTAL

State Vector

RENTAL-id, RENTAL-CUST-id, RENTAL-CAR-id, RENTAL-state,RENTAL-amount

Methods

RENT { RENTAL-id := RENT-RENTAL-id;RENTAL-CUST-id := RENT-CUST-id;RENTAL-CAR-id := RENT-CAR-id; RENTAL-amount := 0;RENTAL-state := "1"; }

RETURN { RENTAL-state := "2"; }PAY { RENTAL-amount := PAY-amount;

RENTAL-state := "E"; }

2.5 Examples of constraints

These are some examples of constraints for Event Types:

R1 : RENT : # RENTAL(RENTAL-CUST-id = RENT-CUST-id & RENTAL-state = "1") < 1.

R2 : CR-CUSTOMER : CR-CUST-CUST-name <> " ".

and so on. Observe that no decision is taken as to whether the number of rentals is calculated or stored asan attribute in Customer. This would indeed be an implementation decision.

15

3. THE PERU-AID PROJECT DESCRIPTION

PERU-AID is a development organisation, which is rather traditionally organised. On one hand, theorganisation is running projects. Each project must have a project title, and a project budget, whichestimates the total expenditures for that project. The system that is to be developed should not take intoaccount the administration of the expenditures for a project: only the incoming financial logistics belongsto the scope of this system.

PERU-AID likes to have a member-administration, so that they can activate the donation of gifts to theorganisation. By definition, gifts belong to the member organisation that donated the gift. It is irrelevantwhether this organisation is a private person, or a company, or another aid-organisation. On the otherhand, every member should have at least a name, an address, a zip-code and a city. The country isincluded into the zip-code. It should be impossible to create members for which the essential informationelements are missing.

Whenever gifts are received, they must be certified on a yearly basis, in order to provide potential fiscalbenefits to the donating organisation. More concretely, at the end of the month of the donation date for agift, a certification document is composed and mailed to the donating member. At the end of the year eachmember receives a statistics report about the status of the gifts belonging to that member for the last year.

Gift may be general gifts, which are not intended towards any particular project. However, a member canalso donate project-gifts, which are for specific projects. At least, as long as the total amount of incomerepresented by the project gifts does not exceed the estimated project budget. Otherwise, a project-giftbecomes automatically a general gift.

It should be possible to change the details of members as well as projects. In particular, it should bepossible to change the title and the budget of a project. Moreover, it should be possible to change thename, address, zip and city of a particular member. After a while, and in particular if nothing happened toa gift, project or member for the last two years, archivation happens. This means that the person isarchived together with all the object that belong to this member. These gifts should be archived before amember can actually be archived. Gifts cannot be archived before they are certified, for obvious fiscalreasons.

On request a report with the average gift-amount per gift per member should be produced. Morever , theaverage gift-amount per project-gift should be reported on a yearly basis. Standard input functions shouldbe provided for the creating event for all business objects. Last, but not least, gifts should be certified on ayearly basis.

TASK 1: CONSTRUCT THE FOLLOWING ELEMENTS FROM THE BUSINESS MODEL FORPERU-AID:

a) OBJECT/EVENT PARTICIPATION TABLEb) OBJECT-RELATIONSHIP DIAGRAMc) 3 JACKSON DIAGRAMS FOR BUSINESS SEQUENCE CONSTRAINTSd) ONE ABSTRACT DATA TYPEe) 2 OTHER CONSTRAINT EXAMPLES

The solution package will contain the a fully elaborated Business Model for PERU-AID.

16

4. THE IMPLEMENTATION OF BUSINESS MODELS

In an ideal situation, an Object operating system should be available to execute directly the BusinessModel specifications, without an explicit translation into an implementation. A PROLOG-based prototypeof such an environment has been developed [PUT 1988]. However, such technology is not commerciallyavailable today. As a consequence, a Business Model must be translated into an implementation model tomap it on existing Information Technology. In this chapter the following example will be used to indicatethe implementation options.

Ev_Type_1

Ev_Type_2

Ev_Type_3

Ev_Type-4

Ev_Type_5

Ev_Type_6

Ev_Type_1_Attrib.

Ev_Type_3_Attrib.

Ev_Type_2_Attrib.

Ev_Type_4_Attrib.

Ev_Type_5_Attrib.

Ev_Type_6_Attrib.

BR 1

BR 2

BR 3

BR 4

BR 5

BR 6


Obj_A_Attrib. Obj_B_Attrib.

Obj_A_St_Vector Obj_B-St_Vector

C

X

E

X

X

X

C

X

E

= E

EVENT

MESSAGE

4.1 An EVENT-based implementation

In this transformation, "horizontal" cuts are taken in the Business Model to implement the BusinessModel. This means that the Event Types are takes as the basis for structuring the implementation ofBusiness Models.

Ev_Type_1

Ev_Type_2

Ev_Type_3

Ev_Type-4

Ev_Type_5

Ev_Type_6

Ev_Type_1_Attrib.

Ev_Type_3_Attrib.

Ev_Type_2_Attrib.

Ev_Type_4_Attrib.

Ev_Type_5_Attrib.

Ev_Type_6_Attrib.

BR 1

BR 2

BR 3

BR 4

BR 5

BR 6




C

X

E

X

X

X

C

X

E

= E

17As a consequence, the Object Classes are dismembered, and all the methods from the Abstract Data Typesare grouped by Event Type. The State Vectors are grouped into a file system, or in database managementsystems. The following suggest the components of such an implementation.

MES-

SAGE

CallProcedureUsingComm-zone

Procedure Comm-zones Event-Procedures

Ev_Type_1

Ev_Type_2

Ev_Type_3

Ev_Type_4

Ev_Type_5

Ev_Type_6

Ev_T_1_Attr

Ev_T_3_Attr

Ev_T_2_Attr

Ev_T_4_Attr

Ev_T_5_Attr

Ev_T_6_Attr

C

X

E

X

X

X

C

X

E

BP 1

BP 2

BP 3

BP 4

BP 5

BP 6

Obj_A Obj_B

DatabasesDML

Object

Attrib.

In this implementation, a procedure is constructed for each Event Type. This procedure contains allBusiness Rules, which are to be satisfied before an Event of that Type can be accepted. Moreover theprocedure contains all the methods (which must be performed once all Business Rules are satisfied).

The triggers of the implemented Business Models are call of Business Procedures, whereby all Eventattributes are included by means of communication zones. All the dismembered information is stored in adatabase, which can only be accessed through the Business Procedures.

A more systematic implementation diagram for this approach is the following.

18

BUSINESSPROCEDURE

EVENTHANDLER

EVENT - SCHEDULER

USER - INTERFACE

Store State Vectors

Read State Vectors

Result

State VectorData Sets

The functioning of the components of this implementation diagram is the following:

A. The SCHEDULER accepts messages from the USER INTERFACE (e.g. Push Buttoms or PanelSelections) and decides when these messages will be executed. The most trivial scheduler is the completeONLINE-scheduler, which immediately activates the Business Procedures.

B. The EVENT-HANDLER gets activated by means of messages transmitted by the SCHEDULER. TheEvent-Handler activates the appropriate Business Procedures, resulting from Object Dismemberment.Finally the Event-Handler will be responsible for updating the State Vectors.

C. The BUSINESS PROCEDURES function as described before, grouping Business Rules, BusinessMethods and the possible rejection of Events.

The above diagram can easily be the starting point of the implementation of an Object-Oriented BusinessModel in a traditional CASE-tool. It is indeed the top level Data Flow Diagram, which can be furtherexploded into the necessary subprocesses for the methods and the rules.

In this implementation procedure, the Object Relationship diagram can be transformed into a DBMS-schema, according to the classical rules for Data Base Design. The Object Relationship diagram acts inthis case as the Conceptual Schema. Classical normalisation rules apply as usual.

TASK 2:

1. Write (using the pseudo-code of your choice) the structure of the Event Handler.

2. Sketch the Event-based implementation diagram for the PERU-AID case.

3. Design the Data Base for the PERU-AID Business Model.

The solution package contains a full specification of the Event Handler and examples of BusinessProcedures.

The major advantage of this approach lays in the fact that it is possible with all types of technology,varying from very advanced to very traditional. Even in every third generation language and file system itis possible to implement a Business Model this way.

19

4.2 An OBJECT-based implementation

In this implementation approach, the Object Class Abstract Data Types are taken as the basis for theimplementation. Any Object-Oriented programming language that handles Abstract Data Types can beused for this type of implementation. Of course, support for persistent Objects facilitates the completeintegration with the long-term storage of Objects.

Ev_Type_1

Ev_Type_2

Ev_Type_3

Ev_Type-4

Ev_Type_5

Ev_Type_6

Ev_Type_1_Attrib.

Ev_Type_3_Attrib.

Ev_Type_2_Attrib.

Ev_Type_4_Attrib.

Ev_Type_5_Attrib.

Ev_Type_6_Attrib.

BR 1

BR 2

BR 3

BR 4

BR 5

BR 6




C

X

E

X

X

X

C

X

E

= E

The base principle for this implementation is the use of Bottom Objects as the starting point for acceptingEvent messages. In fact, each Event Type enters the Business Model implementation in its Bottom Object.Next a bottom-up approach is used to transmit messages to all the higher level Object Classes (whichparticipate to the Event Type) in the Object Classification.For the example of this chapter, this leads to the following implementation diagram.

20

Ev_Type_1

Ev_Type_2

Ev_Type_3

Ev_Type_1_Attrib.

Ev_Type_3_Attrib.

Ev_Type_2_Attrib.

BR 1

BR 2

BR 3

Object Class A

Obj_A_Attrib.

Obj_A_St_Vector

C

X

E

X

X

X

Ev_Type-4

Ev_Type_5

Ev_Type_6

Ev_Type_4_Attrib.

Ev_Type_5_Attrib.

Ev_Type_6_Attrib.

BR 4

BR 5

BR 6

C

X

E

Object Class B

Obj_B_Attrib.

Obj_B-St_Vector

ABSTRACT DATA TYPE A

ABSTRACT DATA TYPE B

There are obviously a number of alternatives for the location of the Business Rules and to make sure thatObject Classes which particpate together to an Event Type react simultaneously, are at least consistently.In the above example, the Business Rules of an Event Type could be attached to the Abstract Data Typeof the Bottom Object Classes of that Event Type. If necessary, one Object Class inspects the state vectorof other Object Classes to obtain the necessary information. Some OO-languages, like EIFFEL [MEYER1992], provide support for a large variety of Business Rules directly. In some other Object-Orientedlanguages, additional methods have to be included to Abstract Data Types for all the Business Rules.

A mixed implementation could check all the Business Rules by means of additional Transaction ObjectClasses (one per Event Type). These Transaction Classes inspect the necessary Object Classes and onlysend correct, accepted Event Messages to the implemented Business Model. An obvious advantage is thefact that many Object-Oriented Presentation Shells (ObjectVision, ObjectView, VisualAGE, and so on)allow fast implementations along this scheme. The following diagram indicates the necessary componentsof such an implementation.

21

USER INTERFACE OBJECT CLASSES

TRX-MESSAGE-HANDLER

TrxTrx-message

Trx-message

TRX OBJECT CLASS

Event-message

Query Object SV

Reject Trx

Acknowledge Event

(Persistent)OBJECT CLASS

Event-Message

EVENT-MESSAGEHANDLER

This implementation alternative can even allow a mixing of OO-technology and conventional technology.As an example, an OO-presentation shell can be used for the GUI-based transaction handling. On theother hand Object dismemberment can be used for the Event Handler, and the objects stored in aconventional DBMS.

A natural mapping on CLIENT/SERVER technology is also possible. If wanted, the transaction handlingcan take place on CLIENT technology. The Event Handler and the Business Objects can be located onSERVER technology to facilitate easy consistency.

TASK 3:

1) Discuss implementation alternatives for the PERU-AID case: what parameters do you use to choose ?

2) Observe the OBJECTVISION demo of an OO-implementation. Complete the specification of the GIFTObject Class.

The solution package contains the procedure to implement the PERU-AID case in an OO-presentationshell. A running version for Windows 3.1 is available.

22

5. INFORMATION OBJECT TYPES

Around a Business Model, additional Object Classes can be defined to satisfy the InformationRequirements of the Users. The triggers for these Information Object Classes are Information Requests,which in turn can be triggered by means of Business Event Types, Real World Time Clocks (referred to asTime Grain Markers) or real information requests (to be implemented by push-buttoms or panel choices,for example). Observe that an Information Object Class that is only triggered by Business Event Typesbecomes AUTOMATICALLY existence dependent on the Bottom Object Class for that Event Type. Thisconvention avoids the use of Data Streams between Business and Information Objects, which impliesalways implementation choices.Observe that the methods for Information Object Classes are structures of operations, whereas themethods for Business Object Classes are sets of operations.

5.1 An Information Object Class Typology

Basically three types of Information Object Classes can be distinguished.

Input Object Classes

The outcome of this type of Information Objects is on one hand a stream of Event Types, for acceptedinputs, and Output Messages for rejected inputs. The general structure of such an Object Class is asfollows.

INFO REQUESTS

SV-QUERIES

BUSINESSMODEL

OBJECT

CLASSES

EVENT TRIGGERS

REJECTION MESSAGES

INPUTOBJECTCLASS

This type of Information Object Classes is used mainly to interface the input of real world messages intoEvent Types for Elementary Business Models. The specification of an input function consists of anAbstract Data Type, with a method for each trigger, i.e. each type of Information Request.

Output Object Classes

This type of Information Object Classes produces information as a reaction to triggers. The information isextracted from the Business Model by means of State Vector Queries. The outcome of this type of

23Information Objects is always a stream of output messages. The general topology of an outputInformation Object Class, triggered by information requests, is the following.

BUSINESSMODEL

OBJECTCLASSES

INFO REQUESTS

OUTPUT STREAM

SV QUERIESOUTPUTOBJECTCLASS

In case an output Object Class is triggered by Business Event Types, the Polymorphism principle impliesthat the Output Object Class becomes existence dependent on the Bottom Object Class for that EventType.

BUSINESSMODEL

OBJECTCLASSES

OUTPUT STREAM

SV QUERIESOUTPUTOBJECTCLASS

BUSINESS EVENT TYPES

Implicitely it is assumed that Business Model Object Classes are updates before Information Objectsquery state vectors, in order to preserve consistency !

Control Object Classes

Control Object Classes are typically the kind of feedback/feed-forward functions that are used to control aBusiness Model ON REQUEST (not on a basis of Event Types, since this should be modelled by meansof the Business Model). The output of this type of Information Objects is a stream of Business Event

24Types, which may (or may not) be acknowledged by the "real world". The general layout for this kind ofInformation Objects, in case when explicit information requests are the triggers, is as follows.

BUSINESSMODEL

OBJECTCLASSES

INFO REQUESTS

SV QUERIES

OBJECTCLASS

STREAM OF BUSINESS EVENTS

CONTROL

TASK 4:

Discuss why Control Object Classes can never be existence dependent on Business Object Classes.

5.2 Some CAR-RENTAL Information Object Classes

The following is a list of some information requests for Information Object Classes.

Function 1

On request a list should be given of all customers that have actually some car in rent.

Function 2

End each customer which had no car in rent for the last two years.

Function 3

Print a congratulation letter for each customer that reached his fifthied rental.

The general topology of these functions can be represented by the following diagram.

25

CAR

RENTAL

PERSON

I1

O1

F1

F2I2 O2

F3

O3

The detailed formulation of the function methods is outside the scope of this tutorial. However it shouldbe remarked how, in principle, any 4th generation reporting language is sufficient to implement thesefunctions. This allows to position the proper role of 4th versus 3th generation languages inimplementations.

The abstract data type for the Information Object Class F3 could be the following.

OBJECT CLASS F3

State VectorF3-id, F3-CUST-id, F3-#-RENTALS

Methods

F3-CUST-id := CR-CUSTOMER-CUST-id;F3-#-RENTALS := 0;

F3-id := new(F3-id);CR-CUSTOMER seq

endRENT seq

F3-#-RENTALS := F3-#-RENTALS + 1;RENT-CONGR sel (F3-#-RENTALS = 50)

CONGR seqSend-Message ("Congratulations ! ");

CONGR endRENT-CONGR end

RENT end

26Of course these specifications are not optimised. The packaging of the state vector together withCUSTOMER and the grouping of the methods, for example for RENT, is an implementation decision.

TASK 5:

1) Design the above diagram for the PERU-AID specifications given above.

2) Specify at least one function method using the pseudo-code dialect of your choice.

The solution package will contain a complete specification of these Information Classes.

6. A GENERIC IMPLEMENTATION SCHEME

All elements can now be grouped together in implementation diagrams. The following is animplementation diagram which includes the different function types.

USER INTERFACE OBJECT CLASSES

SCHEDULERCLASS

INPUT-REQUEST-HANDLER

INPUT-OBJECT-CLASS

OUTPUT-OBJECT-CLASS

EVENT-MESSAGE-HANDLER

(Persistent)OBJECT CLASS(Bus. or Info.)

CONTROL-

OBJECT-

CLASS

Trx-message

Output

Output-request

Event-message

ControlRequest

Event-message

Input-Request

Rejec-

tion

Acknow-

ledge-

ment

Input-request

Event-message Query Object State Vector

Event-

message

A new element is the scheduler, which can also be dismembered into different schedulers(BATCH/ONLINE or FOREGROUND/BACKGROUND) as necessary. The above diagram can again beinterpreted as a traditional data flow diagram for implementation in a traditional CASE-tool. After Objectdismemberment, all state vectors can be grouped into a database, and all Object Abstract Data Types canbe transformed into COBOL-programs. The traditional packing considerations from structured analysisand design approaches should be used to decide on an optimal packaging of the code.

27

TASK 6:

Design the above diagram in the case of a conventional 3GL-based implementation for the PERU-AIDcase.

The solution package contains some relevant fragments of such an implementation, which will bedemonstrated.

7. DISCUSSION

This paper has shown that the use of Object-Orientation is a feasible way to enhance softwaredevelopment. Moreover, the traditional fear that Object-Orientation is necessarily revolutionary instead ofevolutionary can be relaxed somewhat, given the re-use of traditional software techniques and theavailable implementation freedom.

The M.E.R.O.DE.-approach [DEDENE 1994a] does nothing else but putting existing analysis and designtechniques together in such a way that model-driven development and Object-Orientation are enabled.The algebra behind it provides however unprecedented consistency checks on the software specifications[SNOECK 1993, DEDENE 1994b], in order to detect inconsistencies as soon as possible. The use ofBusiness models as the kernel for systems specifications should lead to a higher conformity of thesystems.

This paper examplifies how Object-Oriented tools are not absolute pre-requisites to start using Object-Orientation at higher abstraction levels. In other word, organisations having investments in traditionaltools and a lot of legacy systems should not use this as a reason to wait for the introduction of Object-Orientation in their Application Development Environments.

Of course, software developers have strong hopes that ultimately Object-Oriented technology will becomeso powerfull and rich that it makes transformations obselete. Once this is realised, our society is one stepcloser to the so-hoped-for "information society". Because, if Business Model specifications cantransparently be implemented, Object-Oriented Models become the "de-facto" way to run the BusinessProcesses [DEDENE, 1993b]. Users should not wait to start to learn and experiment with this. By thetime the technology becomes available, they might miss the boat...

References

(Dedene, 1991)

Dedene G., "Productive Application Development using an Object-Oriented Business ModelingApproach", Keynote lecture for the 2th International Conference on Repository and AD/Cycle, Chicago1991.

(Dedene, 1993a)

Dedene G., "M.E.R.O.DE. by examples : A tutorial on Object-Oriented Business Modeling", Proceedingsof Object Technology 93, Cambridge 1993.

(Dedene, 1993b)

28Dedene G., Snoeck M., "Object-Oriented Modeling: a new language for Consistent BusinessEngineering", Proceedings of EasteurOOPe 93, Bratislava 1993.

(Dedene, 1994a)

Dedene G., Depuydt A., Verhelst M, "Object-Oriented Business Modeling with M.E.R.O.DE.", book toappear, 1994.

(Dedene, 1994b)

Dedene G., Snoeck M., "Mathematical Foundations of Object-Oriented Business Modeling", book toappear, 1994.

(Jackson, 1983)

Jackson M., "System Development", Prentice-Hall 1983.

(Meyer, 1988)

Meyer B., "Object-Oriented Software Costruction", Prentice-Hall 1988.

(Meyer, 1992)

Meyer B., "Eiffel, the language", Prentice-Hall 1992.

(Put, 1988)

Put F., "Introducing dynamic and temporal aspects in a conceptual database schema", Doctoral Thesis,Faculty of Economics and Applied Economics, K.U.Leuven 1988.

(Snoeck, 1993)

Snoeck M., "Requirements for Correct Business Models", L.I.R.I.S. K.U.Leuven Research Note 1993.

(Zachman, 1993)

Zachman J.A., "A framework for Information Architecture", IBM Systems Journal, Vol 26, n° 3, 1987.

object-oriented systems: from conception to...

Documents