Entity Event Modeling (EEM)
An entity event model not only relates entity types, but also specifies events that affect the entities, and so provides a more comprehensive ontology for a system of interest.
This article outlines a method for modeling a system as a set of entities affected by a set of events, relevant to Discrete Event Simulation (DES), and Object-Event Modeling,
The method
An entity is affected by one or more events. An event has effects on one or more entities. An event is a discrete state change that moves one or more entites in a system from a prior state to a successor state. The effect of one event on one entity resolves the many-to-many relationship betwween entities and events.
Ashby set out a three step method for cyberneticians to define a deterministic system.
Systems analysis and design methods for entity and event modelling (EEM), including SSADM in the UK, and MERODE in France, loosely correspond to Ashby's method.
In the 1990s, such methods were squashed by “object-oriented” methods, which underplayed the concept of the discrete event. Today however, there is discussion of Discrete Event Simulation (DES), and Object-Event Modeling, which define the object and event types of a problem domain.
The basic ideas of EEM in the UK government's Structured Systems Analysis and Design Method are outlined below with reference to an employee management system.
The method: first illustration
Step 1: The state vector
Form the state vector of a system by definng and relating the entities of interest to your aim
Entity: a structure, a stateful thing that persists and may be affected by one or more events. Think of an actor, object, product, facility, component, or application.
You begin by defining the entities of interest, and relating them in a concept graph or entity, attribute relationship model. MERODE draws a UML class diagram. SSADM relates stateful entity types in a logical data model.
Given such a structural model, you can model the behavior of the system from two perspectives - entity oriented and event-oriented.
Step 2: Entity-oriented view of behavior
For each entity, define the events that change it from state to state.
Event: a behavior, something that happens and may affect one or more entities. An event is a discrete state change that moves a system from a prior state to a successor state. Think of an activity, operation, process, method or transaction.
You mightly simply list the events that create, update and delete the state of an entity.
You might document the sequence of events and state changes in the life history of an entity. (Or two or more parallel life histories if need be.) MERODE (and most comparable methods) document the events and states using UML state charts. SSADM shows the events and their effects in an entity life history diagram. See the second illustation below for an example.
Step 3: Event-oriented view of behavior
Define each event's effects on the entities.
Effect: the state change that happens when an event affects an entity. For example, the effect that a business event (such as order, invoice, payment, or complaint) has on a business entity (such as customer, order, product type, or warehouse).
Causal analysis looks backwards. Effect analysis looks forwards, to define the effects of one or more events on a given set of entities.
For each entity affected by an event, identify the business rules. What state must the entity be in for this event to be accepted (a precondition)? What changes does this event make to the state of the entiy (a post condition)(?.
You may document the results of this analysis in either of two ways, declarative and procedural..
Declare the overall effect of each event in a contract
You may declare the effects of an event on the entities in system in a contract that hides the step-wise procedure needed to complete a state change. The contract will likely include the event type name and
The inputs and outputs can be parameters, messages and larger data structures. The pre and postconditions refer to the state of entities inside the system, before and after the event.
Define each event as a rule-bound procedure
领英推荐
The diagram below shows how Peirce's idea of a "sign relation" may be represented in an effect diagram notation, and connecting one instance of the relation to another in sequence.
Effect analysis identifies the effects of defined events on defined entities. I am not familiar with the techniques in MERODE. Using SSADM, you first define an effect diagram, and then an event procedure.
First, you model each event in terms of the effects it has one or more entities. The diagram below illustrates how the cause-effect relatonship can be singular, multiple, optional or shared.
For any given event, an effect diagram shows its effects on the entities of interest in the system of interest. For example, you can model a Resignation event as having a cancellation effect on all an employee’s assignments to projects, and all the tasks on each assignment.
A diagram of this kind serves to outline a procedure to implement the effects of an event on the entities.
Comparison with OOAD
The object-oriented approach is to definie for each entity, the "operations" that refer to and update the entity's state vector. The operations resemble the "effects" of events on entities in EEM, but the two paradigms are somewhat different. This article does not explore the object-oriented approach.
Documenting the shared effects of events
Keith Robinson refined the EEM technique, by identifying where events share a common effect or group of effects, and drawing a diagram for a system that shows the network of events and their effects.
For example, in the employee management system (called Hi Ho), the diagram below shows several of the events share common effects (which Robinson called super events).
The method: second illustration
Suppose we model a game of “five-card draw” poker as a system. We can describe it in terms of the
The game starts with 1 dealer, a pack of 52 cards in a particular sequence (there are more possible sequences than atoms on Earth) and N players, each with no cards in hand and no bet placed. As the game proceeds, state changes incrementally change the cards in the pack, the cards in each hand, the patterns detectable in each hand, the money bet per hand, and the overall game state.
Step 1: The state vector
Form the state vector of a system by definng and relating the entities of interest to your aim
Stateful entities and variables may include:
Step 2: Entity-oriented view of behavior
For each entity, define the events that change it from state to state.
In the real world, events may happen in any sequence, or in parallel. In modeling systems, we often identify sequential dependencies between events. In this case, we can sequence all the events in the life history of a poler game.
The events that affect an entity during its life may be documented in various ways. Most people draw state charts to show event/state sequences. Below, insteaad, I have used a regular expression (aka "Jackson structure").
The leaves of the tree structure are the events that occur in the progress of the game. Some pairs of events are repeated N times, where N is the number of players.
Step 3: Event-oriented view of behavior
Define each event's effects on the entities.
To proceed to model the effect of each event on each entity would occupy many pages. A player’s role involves finding patterns in cards, then making decisions about placing bets and discarding cards. A software engineer might randomize the decisions, or base them on the statistical probability of any pattern found in a hand being a winning pattern.
Related articles
If you want to read this article in the context of a book on the philosophy that underpins how we describe the world, and systems, then watch this space, because this is a draft of a chapter in that.