Object Event Modeling (OEM) is a new paradigm for modeling discrete dynamic systems, including organizations and their “process-aware” information systems (IS). OEM combines information modeling with discrete process modeling. An Object Event (OE) information model defines the types of objects and events of a problem domain, with their attributes, associations, operations and constraints, typically in the form of an OE Class Model, which is a UML class model with the class stereotypes «object type», «event type» and «activity type». In OEM, an activity is a special kind of non-instantaneous event that is composed of an instantaneous activity start event followed by an instantaneous activity end event.

In this article, we first introduce OEM with an example of an organization that does not need any form of process-model-based activity sequencing (or workflow modeling) for its business processes. The business app, or IS (Information System), of such an organization has to support its business processes by allowing its clerks to perform business activities with the help of activity user interfaces provided by the IS. We argue that a sufficiently rich OE class model is all you need for automatically creating a business app for these organizations, either with model-driven code generation or with the help of a low-code app development approach like OEMjs, which is introduced as a reference implementation of OEM in Section 2.

In Section 3, we provide a brief outlook of combining OE information modeling with discrete process modeling using the Discrete Event Process Modeling Notation (DPMN) for supporting structured business processes with activity sequencing. Section 4 discusses the use of OEM for Discrete Event Simulation. In Section 5, we briefly discuss the question if UML has missed the modeling of events and the opportunity of modeling behavior/processes based on a general concept of events and their state changes. Finally, in Section 6, we compare OEMjs with other low-code app development approaches and discuss related research in Section 7.

1 Introduction to OEM

The world consists of objects and events. “Smiles, walks, dances, weddings, explosions, hiccups, hand-waves, arrivals and departures, births and deaths, thunder and lightning: the variety of the world seems to lie not only in the assortment of its ordinary citizens—animals and physical objects, and perhaps minds, sets, abstract particulars—but also in the sort of things that happen to or are performed by them” (Casati and Varzi 2015).

While research in Business Process Modeling has focused on events and processes, neglecting objects, research in Conceptual Modeling for Information Systems (IS) engineering has focused on objects, neglecting events. OEM reconciles both perspectives, giving equal weight to objects and events.

As an illustrating example, consider a public library, which lends book copies to their users. For this organization, the most important object types are Book, BookCopy, Publisher, Person, and LibraryUser, while the most important activity types are BookLending and BookTakeBack, as described by the following OE class diagram:

If the library has automated entrance and exit registrations, we would have to add the two event types UserArrival and UserDeparture to this model. All event types, including activity types, have the implicit attributes occurrenceTime, startTime, and duration, where duration = occurrenceTime − startTime. Activities occur when they end/complete. For instantaneous events, such as user arrivals and departures, only their occurrence time is meaningful, they don’t have a start time and a duration.

It is important to understand that objects participate in events – this is a principle of foundational ontologies such as UFO. This implies that there are corresponding participation associations between an event type and its participating object types. In our running example, we have two such associations both for BookLending and BookTakeBack, because both types of activities have two types of participants as represented by their implicit reference properties libraryUser and bookCopies.

Due to the temporal snapshot semantics of UML class models, according to the multiplicity 0..1 at the BookLending association end, a library user participates in at most one current BookLending activity, although there may be many past/historic BookLending activities, in which that user has participated and we assume that an IS stores these historic activity records in its database. For supporting a distinction between snapshot and history cardinality constraints, Tauzovich (1991) has proposed to add a “lifetime cardinality” as a supplement to the snapshot cardinality to association ends in his Temporal Entity-Relationship modeling approach. We adopt this distinction for OE class models, where we allow for a history multiplicity expression in the form of “H:m“, where m is a normal multiplicity expression (such as * or 0..1), in addition to the standard snapshot multiplicity expression at the event/activity class side (or association end) of a participation association. For avoiding the cluttering of OE class diagrams, we assume that, by default, at the event/activity class side of a participation association, the snapshot multiplicity is 0..1 and the history multiplicity is *, so explicit expressions for these two multiplicities only have to be displayed if they differ from these defaults.

For many organizations, but not for our example of a public library, an IS needs to support the sequencing of activities where after an activity has been completed, a follow-up task is created and added to the task list of an organizational role in charge of performing the task. A task is a planned activity waiting in a queue (task list) for being performed by a specific performer at a specific start time. An activity is either ongoing or has been performed in the past. In both cases, it has a specific performer and a specific start time.

The admissible sequences of activities are defined in a business process model that also defines, for each type of activity, the state changes of affected objects. For an IS without activity sequencing, such as for our example of a public library IS, we only need to define the state changes of affected objects, but we don’t need a full-fledged process model. This means that both for BookLending and BookTakeBack, we define their state changes of affected objects (the involved book copies) in their onActivityEnd event handler operations, as shown in the following activity class rectangles:

Even without an accompanying process model, an OE class model that includes activity types with onActivityEnd event handler operations already allows a business app (such as the library IS) to support business processes without task sequencing by providing activity APIs and activity user interfaces (UI) for performing business activities. An activity API allows performing the corresponding business activity programmatically (typically in the style of a remote procedure call), while an activity UI allows human resources to perform the corresponding business activity.

An OE class model, such as the library IS model above, specifies (1) a set of object types OT, (2) a set of instantaneous event types ET, and (3) a set of activity types AT. When an OE class model is accompanied by a DPMN process model, the process model specifies a set of event rules R for the event/activity types defined in the OE class model. Event rules specify state changes as well as follow-up events/activities, and can be implemented in the form of event handler operations. When no activity sequencing is needed, the event handler operations may be specified in the OE class model, as shown above, where event handlers are specified in the form of pseudo-code (alternatively, they could be specified in the form of OCL post-conditions).

OEM’s activity modeling approach allows integrating business rules in new ways. Consider the rule “A maximum of 50 book copies can be borrowed at one time”. This behavioral rule cannot be adequately operationalized in the form of a static integrity constraint (called invariant in UML). Rather, such a rule can only be implemented in the context of the type of activities to which it refers. If its condition (that the number of books lended to the given user is less than or equal to 50) is not fulfilled, the activity (BookLending) must not be performed.

Ross (2023) explains that there are two fundamental types of business rules: definitional rules and behavioral rules. While modeling the former is related to modeling object types, modeling the latter is related to modeling activity types. Thus, OEM can cater for both types of business rules.

We now sketch how an IS (or business app) can be generated from an OE class model ⟨OT, AT⟩ with onActivityEnd  event handler operations for all A in AT:

1. Create a main menu that contains
   • (a) the menu item “Manage data” that leads to a “Data management” menu;
   • (b) a menu item “A” for each activity type A in AT leading to a corresponding activity UI.
2. Create the “Data management” menu by creating a menu item “Manage O data” for each object type O in OT, leading to a “Create-Retrieve-Update-Delete (CRUD)” menu for O.
3. Create the CRUD menu for each O by creating the four menu items “Create an O record”, “Retrieve/list all O records”, “Update an O record”, and “Delete an O record”, leading to corresponding CRUD UIs (for brevity, we omit to sketch how CRUD UIs are rendered).
4. Create an activity UI for each A in AT by rendering
   • (a) a “Date” (or “Date/Time”) output field,
   • (b) a Select-Reference widget for each single-valued reference property of A,
   • (c) a Select-Multiple-References widget for each multi-valued reference property of A,
   • (d) an “OK” button that leads to the invocation of the onActivityEnd event handler of A.

While the automated generation of CRUD user interfaces based on a model of object types is a well-known approach in IS engineering, the automated generation of activity user interfaces based on a model of activity types is new. In today’s low-code platforms, see Section 6 below, activity user interfaces have to be created manually with the help of UI build tools.

OE class models allow a number of natural extensions, which we cannot further discuss in this short article:

1. Auditing: Indicate for which (sensitive) attributes of which object types changes are to be logged in an “audit trail”, which is an Update event table containing the following information items: user, object tobject ID, attribute, old value, new value (possibly complemented by a Create and a Delete event table).
2. History information: Indicate for which attributes of which object types historic values have to be kept/stored (e.g., the salaries of employees). If the events responsible for the changes have to be represented to allow understanding “why” a particular historic value exists, then a full change log is needed similar to an audit trail.
3. Role-based authorization: allows defining roles with specific permissions to (1) create/read/update/delete instances of specific object types or specific attributes, (2) perform activities of specific activity types.

For more on OEM, see also (Wagner 2023).

2 Introduction to OEMjs

The JavaScript app development framework OEMjs implements the OEM paradigm. It allows expressing an OE class model in a textual form using the JS data structure of maps (also called “JS objects”). For instance, the object type Book is defined in the following way:

class Book extends bUSINESSoBJECT {
  constructor ({isbn, title, year, publisher, authors, bookCopies}) {...}
}
Book.properties = {
  "isbn": {range:"String", isIdAttribute: true, label:"ISBN", fieldSize: 12, 
           pattern:/\b\d{9}(\d|X)\b/, 
           patternMessage:"A 10-digit string or a 9-digit string followed by 'X'!"},
  "title": {range:"NonEmptyString", label:"Title", min: 2, max: 50, fieldSize: 50},
  "year": {range:"Integer", label:"Year", min: 1459, 
           max: () => (new Date()).getFullYear() + 1},
  "authors": {range:"Person", minCard: 1, maxCard: Infinity, label:"Authors"},
  "publisher": {range:"Publisher", optional: true, label:"Publisher"},
  "bookCopies": {range:"BookCopy", inverseOf:"book", minCard: 0, maxCard: Infinity, 
                 label:"Book copies", fieldSize: 50}
}

The activity type BookLending is defined in the following way:

class BookLending extends bUSINESSaCTIVITY {
  constructor ({date, borrower, bookCopies}) {...}
  onActivityEnd() {
    for (const bc of Object.values( this.bookCopies)) {
      bc.status = BookCopyStatusEL.LENDED;
      app.storageManager.update( BookCopy, bc.id, {status: bc.status});
    }
  }
}
BookLending.properties = {
  "date": {range:"Date", label:"Date", derivationExpression: () => new Date()},
  "borrower": {range:"Person", label:"Borrower", 
               selectionRangeFilter: p => p.roles && p.roles.includes(1)},
  "bookCopies": {range:"BookCopy", label:"Lended book copies", 
                 minCard: 1, maxCard: Infinity,
                 selectionRangeFilter: bc => bc.status===BookCopyStatusEL.AVAILABLE}
}

Based on a set of such object and activity type definitions, OEMjs creates the menus, CRUD UIs and activity UIs according to the OE class model interpretation procedure sketched above. For instance, the generated activity UI for the activity type BookLending is shown in the following screenshot:

When the OK button is clicked after choosing a borrower and one or more book copies to be lended, the onActivityEnd event handler of the activity class BookLending is invoked. You can run the public library business app from the OEMjs GitHub website.

3 Adding a DPMN Process Model to an OE Class Model

In general, the business processes of an organization involve the sequencing of events (including activities and actions), as defined in a business process model. For illustrating business processes with event sequencing, we use a pizza service company as an example.

The Discrete Event Process Modeling Notation (DPMN) improves BPMN by replacing its official ad-hoc token-flow semantics with an ontologically well-founded transition system semantics (Wagner 2017) based on Event Graphs (Schruben 1983). With this semantics, BPMN’s ambiguous “Sequence Flow” arrows are turned into event flow or (resource-dependent) activity flow arrows. The following diagram shows a DPMN process model defining three consecutive activities connected with activity flow arrows:

Notice the special form of DPMN’s resource-dependent activity flow arrows, e.g., from TakeOrder to MakePizza: their arrowhead consists of three bars indicating that there is a queue of planned activities (or tasks) waiting for their required resources to become available. These required resources include their performer that is either a human resource or an artificial agent (such as a machine or a software system). For instance, when a TakeOrder activity is completed, a new MakePizza task is created and added to the task list of the PizzaMaker position such that all staff members holding this position can see the new task in their task list and start performing it as soon as they become available. The DPMN process model is based on the following OE class model:

Notice that in this OE class model, the participation associations that associate resources with activities have an association end designated with «rr» or «pr» standing for resource role or performer role, where the term “performer” denotes an active resource object. For instance, the MakePizza activity type has a pizzaMaker performer role with a resource cardinality constraint of “2” and an oven resource role with a resource cardinality constraint of “1”, implying that a MakePizza activity requires 2 pizza makers (as joint performers) and 1 oven (as an additional passive resource). In the OE class model, the association between MakePizza and Oven specifies both the resource cardinality constraint that exactly one oven is required for a MakePizza activity and the multitasking constraint that an oven can be involved in at most two MakePizza activities at the same time.

As can be seen in the class diagram above, an OE class model defines the types and numbers of resource objects required for performing an activity with the help of resource roles and performer roles. In particular, the performer roles of an OE class model provide the same information as the performer swimlanes of a BPMN process model. Although this model information is already provided by the underlying OE class model, it may be helpful to include it also in the DPMN process model, e.g., with the help of swimlanes.

In addition to the three resource objects, two further objects participate in a MakePizza activity: a customer and an order, as specified by the corresponding associations. In fact, the involved Order object is affected by TakeOrder and DeliverPizza activities through object creation and update: (1) when a TakeOrder activity is completed, a corresponding Order object is created with a status attribute value of “open”, (2) when a DeliverPizza activity is completed, the involved Order object is updated by setting its status attribute to “closed”. These IS state changes have to be specified in the process model in addition to event/activity sequencing, as shown in the following extended version of our DPMN process model:

The create/update/delete state changes specified in a DPMN process model can be coded within onActivityEnd event handlers, as methods of the corresponding activity classes of a framework such as OEMjs.

A DPMN process model does not only specify the (possibly conditional) sequencing of events together with their state changes of affected objects, but may also show the assignment of task types to organizational positions or roles, with the meaning that staff members holding a position or playing a role are in charge of performing tasks of the types assigned to them. These task assignments are shown with the help of performer swimlanes (and additional performer annotations if more than one position/role is in charge of a task type). They form the basis for automatically creating role-based authorizations for performing activities by accessing activity user interfaces.

In an IS/app that is based on a DPMN process model (with an underlying OE class model), all staff members, as app users, have a personal task list filled with tasks according to their position or roles. It is implied that they have the duty to perform these tasks (typically, as soon as possibe in the order of the task list). When they complete a task, the corresponding onActivityEnd event handler is executed by the app such that the state changes of the activity are applied and any follow-up activity is scheduled by adding corresponding tasks to the task lists of the performer roles concerned.

4 OE Modeling and Simulation

OEM has originally been developed for simulation modeling (Wagner 2018), but it’s equally suitable for IS modeling. Essentially, the same types of entities, and their associations, as well as the same types of processes, have to be modeled both for making a simulation model of, and for making a process-supportive IS model for an organization.

Since simulation engineering projects and IS engineering projects typically have different goals, they need different (but nevertheless overlapping) models. However, one important case is the simulation of an IS in the broader sense, including the interactions between the IS and its users, which can also be viewed as the simulation of an organization as a discrete dynamic system including the organization’s IS as a subsystem. In this case, the simulation model is an extension of the IS model and the steps needed for turning a process-supportive IS model into a simulation model can be sketched as follows:

1. For each activity type A, (a) for each attribute Attr of A, add a function getAttr that returns a random value for Attr; (b) add an activity duration function, which either returns a constant value representing the average duration of activities of this type or a value sampled from a probabilty distribution modeling the random variation of the duration of activities of this type. In a simulation run, when an activity is started, the simulator computes (a) a random value for each attribute Attr by invoking getAttr, (b) its duration by invoking the activity duration function.
2. Add a recurrence function to each start event type (such as the OrderCall event type in the pizza service example model above). This function either returns a constant value representing the average time in-between two consecutive start events of this type or a value sampled from a probabilty distribution modeling the random variation of this time. In a simulation run, the simulator computes the first and all successive occurrence times of start events of this type by invoking this function.
3. For each organizational position (such as for OrderTaker, PizzaMaker and DeliveryDriver in the model above), add a human resource pool consisting of a realistic number of resource objects representing staff required for performing activities.
4. For each passive resource object type (such as Oven and Scooter in the model above), add a resource pool consisting of a realistic number of corresponding resource objects.

5 UML Does not Support a General Concept of Events

The UML standardization effort has missed the modeling of events and the opportunity of modeling behavior/processes based on a general concept of events and their state changes. Instead, UML contributors have been obsessed with the computational concept of state machines requiring to name all relevant states, which is an approach that does not scale.

It’s rather strange that even in OMG’s new Kernel Modeling Language, the behavior/process modeling concepts of Behaviors and Interactions are defined without even mentioning the term “event”.

Olivé and Raventós (2006) presume that in UML, events have not been considered as first-class citizens (as instances of event classes), but rather in the limited form of operation invocations, due to the desire to separate “structural modeling” from “behavioral modeling”.

6 Other Low-Code Business App Frameworks

There are many other low-code frameworks/platforms for creating business apps. According to Vincent et al (2022), the leading products are Mendix and OutSystems, followed by MS Power Apps, Salesforce Platform and ServiceNow App Engine. While the information modeling approach of OutSystems and ServiceNow App Engine is based on Relational Database modeling (with tables representing object types and associations), the higher-level approach of Mendix supports, like OEMjs, the UML concept of associations with association end ownership and multiplicities. Neither Mendix nor OutSystems or ServiceNow support the OEMjs concept of activity types as the basis of activity user interfaces.

7 Related Work

OEM has been proposed for Discrete Event Simulation (DES) modeling in (Wagner 2018) and for IS modeling in (Wagner 2022). However, unlike in the field of DES, in the field of IS engineering the idea of modeling events as entities in information models and combining this with modeling objects is not new. Already Peter Chen (1976), in his seminal paper proposing Entity-Relationship (E-R) modeling, suggested that both objects and events should be modelled as entities: “A specific person, company, or event is an example of an entity”. Motivated by the importance of events such as sales, purchases, or cash reseipts, in accounting, McCarthy (1979) has proposed to model these events, along with objects, as entities in E-R models  However, neither Chen nor McCarthy considered the fundamental semantic differences between these two kinds of entities and treated them in the same way.

Independently of each other, Allen and March (2003) as well as Olivé and Raventós (2006) have proposed modeling events as entities in information models taking into consideration how they affect the state of objects.

Allen and March (2003) propose to include the events responsible for object state changes as entities in an E-R model arguing that this approach is preferable to temporal database approaches whenever temporality is needed. March and Allen (2009), by stating that “an information system must be conceptualized as an event-processing mechanism and an event as the cause of the transition from an initial state to a subsequent state via the application of its rules”, already have been aware of the concept of event rules as transition functions, which is the basis of the semantics of DPMN process models (Wagner 2017).

Olivé and Raventós (2006) propose modelling events as entities and event types as classes with a special effect() operation in UML class models. Their effect() operation essentially corresponds to the OEM concept of event rules, or the event handlers onEvent() and onActivityEnd() in OEMjs. Olivé and Raventós integrate information and behavior/process modeling in their extended form of UML class diagrams. However, it seems preferable to separate behavior/process modeling from information modeling. While the latter is in charge of defining the types of objects, events and activities (including their attributes, associations, operations and constraints), the former is in charge of defining event rules, which define the effects of events and the admissible sequences of events.

Neither Allen and March nor Olivé and Raventós have made a distinction between instantaneous events and activities.

References

• Allen, G.N., and S.T. March. 2003. Modeling temporal dynamics for business systems. Journal of Database Management, 14, 21–36.
• Casati, R., and A. Varzi, Events, in: E.N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy, 2015.
• Chen, P. 1976. The entity-relationship model – toward a unified view of data. ACM Transactions on Database Systems, 1(1):9–36.
• Vincent, P., K. Iijima, A. Leow, M. West, and O. Matvitskyy. 2022. Magic Quadrant for Enterprise Low-Code Application Platforms. Gartner Report G00759450.
• March, S., and G. Allen. 2009. Conceptual Modeling of Events for Active Information Systems. In Sugumaran, V. (Ed.). Distributed Artificial Intelligence, Agent Technology, and Collaborative Applications. IGI Global. https://doi.org/10.4018/978-1-60566-144-5
• McCarthy, W.E. 1979. An Entity-Relationship View of Accounting Models. The Accounting Review, Vol. LIV, No. 4.
• Olivé A., and R. Raventós. 2006. Modeling events as entities in object-oriented conceptual modeling languages. Data & Knowledge Engineering 58. 243–262.
• Ross, R.G. 2023. Rules: Shaping Behavior and Knowledge. Business Rule Solutions, LLC.
• Tauzovich, B. 1991. Toward Temporal extensions of the Entity-Relationship Model. Proceedings of the 10th International Conference on Entity Relationship Approach, San Mateo, California: E-R Institute, pp. 136-179.
• Wagner, G. 2017. An Abstract State Machine Semantics for Discrete Event Simulation. In Proceedings of the 2017 Winter Simulation Conference. Piscataway, NJ: Institute of Electrical and Electronics Engineers.
• Wagner, G. 2018. Information and Process Modeling for Simulation – Part I: Objects and Events. Journal of Simulation Engineering, vol. 1, 2018.
• Wagner, G. 2022. Object Event Modeling for DES and IS Engineering. Proceedings of the ER Forum 2022. In: Link, S., I. Reinhartz-Berger, J. Zdravkovic, D. Bork and S. Srinivasa (Eds.). volume 3211. CEUR Workshop Proceedings.
• Wagner, G. 2023. Object Event Modeling and Simulation.