Business events in Business domain modelling
M. Snoeck
Université Libre de Bruxelles
Département d’Informatique
Bd. Du Triomphe - CP 212
1050 Bruxelles
email: msnoeck@ulb.ac.be
Abstract
In this paper we will argue that at the level of business domain modelling, message passing is not an adequate interaction mechanism between objects, because it is too much implementation biased. An alternative is proposed: object interaction based on joint participation to business events. With this interaction mechanism, business events become an integral part of the business domain model, at the same level as business objects. In addition we demonstrate that the concept of business events integrates well with the notion of tasks as components of business processes.
What is business domain modelling
In MERODE [6], an object-oriented development method, systems have a natural component structure by grouping the system specifications according to the desired functionality level in the specifications. Indeed, some specifications may origin from a required business functionality (the business domain model), addressing the essential components of a particular business value chain (including business objects, business events as well as business constraints). Other specifications may address more an administrative type of functionality (including input facilities, generation of output reports, electronic data interchange formatting, as examples), referred to as information functionality (the information model) in general. The specifications addressing the first type of functionality constitute a business domain model, that contains the relevant domain knowledge for a business administration. Around this business domain model an information model is developed as a set of input- and output functions offering the desired information functionality to the users of the information system. Output functions allow the users to extract information from the business model, and present it in a required format on paper, on a workstation or in an electronic format. Input functions provide the facilities for adding information or updating information that is relevant for the business administration.
Most current software development methods have no distinction between such business and information functionality. They typically group in a business object not only the core business attributes and business routines, but also input and output procedures. Some methods offer somewhat analogous concepts. Already in [1] the necessity for specifying "real world models" was pioneered. OOSE [3], with some inherited concepts in UML, allows also to distinguish entity objects, as opposed to interface and control objects. A Use-case groups the three kinds of objects in response to a particular requirement. In these methods however, the choice of techniques is critical in addressing the appropriate functionality level: the use of flows or streamed communication mechanisms (such as message passing) may contain implicit implementation choices, which should be addressed in the implementation model, and not in the specification.
Object Interaction in business domain modelling
The object-oriented paradigm in analysis and design is based on exactly the same principles as the paradigm of object-oriented programming languages. This has created the belief that object orientation allows for a seamless transition from analysis to design. Instead, we should rather expect a design to have a different structure in order to meet a proper modular structure. A pertinent question however, is whether concepts that find their origin in implementation techniques are suited for conceptual modelling of a business domain. More in particular, we argue that the concept of message passing is too much implementation biased. Imagine for example a library where members can borrow copies. In this type of domain member and copy are examples of business object types. In a classical object-oriented approach, the fact that a member borrows a copy can be modelled by means of a message from the member to the copy or by a message from the copy to the member (see Fig. 1 (a)). However, at the level of business domain modelling, it would be irrelevant to debate the direction of the message. Indeed, in reality, none of the objects is sending a message to the other. What really happens is that on occurrence of a borrow event, two objects are involved. The implementation bias of message passing becomes even more apparent when the process of borrowing a copy is modelled by means of sequence charts or interaction diagrams [3, 4].
As one can see from this little example, at the business domain modelling level, object interaction can be specified in a natural way by identifying business events and indicating which objects are involved in these events. For the library example this means that we define a business event called "borrow" and that the two domain objects member and copy are involved in this event. In order to specify the effect of the business event borrow, both involved objects are equipped with a method ‘borrow’ and it is agreed that these methods will be executed simultaneously upon occurrence of a borrow business event (see Fig. 1 (b)).
Fig. 1 Message passing in a library
This communication concept gives rise to what we could call simultaneous or reciprocal polymorphism: a method takes several forms (with possibly different interfaces) in different classes, namely, in each of the classes that is involved in the event. As opposed to polymorphism as consequence of inheritance, no choice is made between the different forms of the method, but all methods are executed simultaneously.
The advantages of using this communication by means of common events are numerous:
The first three points will be clarified in the next sections. For the other arguments we refer to [5, 6].
Identifying Business Events
Because of the concept of communication by means of common events, an enterprise model is not only composed of enterprise objects, but also of business events. The first step in enterprise modelling is the identification of enterprise object types and business event types which occur in the described reality and which, at the same time, are relevant for the system to be constructed. To be included in the list of relevant elements, object types as well as event types should satisfy some important requirements. To be a valid candidate object type, an element must satisfy some basic characteristics: an object has an identity, it has a state described by means of attributes and it shows some behaviour. For business event types the requirements are:
In the enterprise model, enterprise object types and event types are related to each other and defined in more detail. Object-relationship diagrams and statecharts are examples of modelling techniques that are proposed by most object-oriented analysis methods to model the internal structure of object types. Object interaction is often documented by means of message sequence charts, also called interaction diagrams [4]. Communication by means of common event types cannot be modelled adequately with this technique, but it can by means of an object-event table (OET). The object-event table is simply a table with one row per identified business event type and one column per identified enterprise object type. Each cell contains either a blank, a 'C', an 'M' or an 'E', which stands for "creates occurrences", "modifies occurrences" and "ends occurrences" respectively. The tabular form allows for some easy integrity checks.
|
|
member |
copy |
loan |
|
enter |
C |
|
|
|
leave |
E |
|
|
|
acquire |
|
C |
|
|
classify |
|
M |
|
|
borrow |
M |
M |
C |
|
renew |
M |
M |
M |
|
return |
M |
M |
E |
|
sell |
|
E |
|
|
lose |
M |
E |
E |
Let us assume that for the library example we have the object types copy, member and loan and the event types enter, leave, acquire, classify, borrow, renew, return, sell, lose. An object event table for this example is given in Fig. 2.
When introducing additional detail in the analysis model, events can be associated with operations on the involved objects. For example, in the copy object type, the borrow event can be associated with an operation that sets the state of a copy to "off shelf". In the loan object type, this event will be associated with the creating operation. In other words, each non-blank cell in the object-event table is associated with an operation that defines the effect of the event on the involved object.
Modelling Business Processes
As explained in the introduction, the functionality of an information system is conceived a set of input and output functions around the business model The separation between an enterprise model and a functionality model leads to a natural partition of systems in three weakly-coupled subsystems, each corresponding to a single aspect of the problem, and evolving independently of all other aspects. The three independent aspects are
The Output Subsystem
Output functions are activated by messages coming from the user interface or by messages coming from input functions. Output functions can inspect the state vector of enterprise and information objects.
The Input Subsystem
Input functions gather information about events or groups of events occurring in the real world and they broadcast business events to business domain objects. For example, upon arrival of a patient in the hospital, an input function will allow to gather all required information about this patient and notify the patient business domain object of the occurrence of a create-patient event. In many cases, an input function broadcasts the same event to several enterprise object of the same or of different types. If needed, the input functions can inspect the state vector of enterprise objects to obtain all information required for producing event messages.
Input functions will often call groups of business events. There are two reasons to group business events: for ensuring consistency and to account for task organisation.
When defining business events, it was said that such atomic event types do not necessarily keep the object base in a consistent state. For this purpose, we need consistent event type. Assume for example a Mail Course Company, students are only of interest to the company as long as they are enrolled for a particular course. As a result, students must mandatorily be enrolled for a course. The object model for the Mail Course Company contains an object type student and an object type enrolment. Atomic Event types are (a.o.) enrol and cr_student, end_enrolment, end_student. The mandatory nature of the association between student and enrolment (each student must be enrolled at any time) implies that when a student is created, an enrolment must be created as well. Similarly, when the last enrolment is ended, either the student must be enrolled for a new course or the student must be ended as well.
Ensuring this type of consistency gives rise to the definition of consistent event types that are the grouping of atomic event types. Before and after the occurrence of a consistent event, the database must be in a consistent state, this is, a state where all constraints are satisfied.
An other reason to group events is the definition of units of work or tasks. For example, let us assume an enterprise model for Hotel Administration with object types customer and stay. It is most likely that new customers will be registered when they arrive at the hotel for their first stay. Therefore the grouping of the event types and create_customer and create_stay is an example of a useful work unit or task.
The input subsystem can thus be conceived as a set of successive layers. At the lowest level are the atomic event types that have been defined in the enterprise model. The second level groups these atomic event types to consistent event types where necessary. Finally, at the highest level are the tasks, which can in turn be decomposed into subtask. The lowest level tasks are composed of one possibly more consistent events. In order to ensure consistency, only consistent events should be available to tasks.
When the work organisation changes, events will be grouped differently. This only affects the input subsystem and not the output subsystem, nor the enterprise model.
The implementation of business processes as sets of interrelated manual and automated tasks is in itself a complex matter that falls outside the scope of this paper. We therefor simplified the presentation and defined functions as being either an input or an output service. An other way to classify functions is to consider the initiator of the functions: services can be user-initiated or they can be automatically triggered by an internal condition in the system. Still an other classification is the batch or on-line scheduling of functions. Obviously, for complex business processes, the distinction between input and output functions only might be too simple. Often workflow systems are a mix of strongly related input and output facilities. In [2] a more complete classification scheme is given: tasks are classified along three dimensions: task initiative, task content and task performance.
Conclusion
In this paper it was argued that joint participation to common business events is a communication mechanism that is better suited for business modelling purposes than message passing. We have shown how business events can be used as basic building blocks for the development of an input subsystem: task can be defined as aggregates of business events. In addition, this ensures a flexible system architecture: when work organisation changes, it suffices to define new groups of events corresponding to the newly defined tasks.
References