Ready.
Event-modeling tells of a system in terms of what-event-may-happen-with-what-preconditions. The precondition may be a state of being. For example, when you are at the door of your house, the door-opening event may happen. The precondition may also be a time of clock. For example, when it is 17:00, some ring may bell.
When the event takes place, its effects may enable some other events to happen. For example, after you may turn the television on, you may start watching something on it. You can read the discussion on the page .
Event-modeling tells us the conditions that must be met for some event to occur. For example, before you wear your shoes, you must first go where they are. And unless it is in the open, you would also need to get them out of the place it is kept.
The process of is(walking) has the events do(Start_walking) and do(End_walking), that mark its end-points. The event do(Start-walking) may always require the precondition is(Being-on-foot), probably achieved as a result of some previous process is(Getting_up), that happened since the condition of is(Sitting).
A process and a condition may be interchangeable, and a general system for modeling should let this. For example, when walking, you are more likely to bump into something, then when sitting. If the modeling tool does not let a process be taken as a condition, then this cannot be represented. Likewise, having an orange in your lunch box may be a condition that lets the event do(Start_eating) but it is also a process that started with your putting that orang into that lunch box, until you get it out, and eat it.
Events can be employed, mainly, in two alternative ways: Explicit-event-sequencing and event-driven-activation (also called, interrupt-driven, or interrupt-based). In both cases, we call the resulting sequences of observed events, a simulation. An event-driven definition eventually also produces some sequence, but that sequence is only implicitly defined, and only observable at run time. In the explicit event-sequencing, you see nodes being connected with arrows, or the like, which tells you what may happen after what.
An interesting model usually may have more than one way of decision-making in it. For example, for eating, you may have many options. As a result, the process of eating may vary. Some days it is the eating of a pizza, sometimes it is bread with peanut butter.
Likewise, for any modeled system, we may observe the general behavior, maybe only after making several observations. Any particular sequence of events with a model, from start to finish, is a simulation process or a simulation run.
By making many simulation runs, we may obtain some statistics about the system. Unlike most real life examples of such repetitive work, the simulated models provide the ability to start again. In real life, you cannot play such what-if scenarios. For example, each match of a team may be considered a run and the stats are gathered, but the successive matches are not independent really. Both physically, and by taking lessons, the teams may also improve or fall behind their rivals, over the course of a season. The abilities and thinking need not be constant throughout a full season, even with the same set of players. Likewise, for your car, even if you have its regular check-ups. Over time, some basic performance level may degrade, unless you altogether change parts, which is another story.
The event do(Start_walking) needs the pre-condition is(On_foot), but it does not always need the precondition is(Shoes-on-feet). Knowing other details may make clear, whether the shoes will be on or off - in case you cared. If you do care, then, for example, the model may also include the precondition is(At-home), if that would differentiate. If you do not care, indeed, you may altogether remove anything about the shoes, from the event-modeling.
A long walk may have many smaller processes in it, or happening at the same time with it. The process is(Walking) may be interrupted by events like do(Buy_icecream, do(Tighten_shoestrings), or do(Saw_dentist_Must_climb_a_tree).
As long as you arrive at the destination, from the start place, you may choose to not model such interruptions. But if you also care to model some of them, then you are at the mercy of your particular modeling-tool.
For example, with Petri nets, a visual modeling method, you would have to have some
alternative walk, which already includes such paths in its graph. In programming languages,
or systems like the Petri-net extension Macro E-nets, you may instead define the
is(Walking) a module, and may be walking, then buying_icecream, then again walking.
The steps and all the details of walking are in the is(Walking) process, whereas
the container, full process may be a process named is(Walking_From_Home_to_Office).
The ability to define such macros and only use them with pointers (labels) to the
actual implementation is a useful feature.
You paid the price for the icecream. But how much did it cost? What size is the icecream? Does it only matter that your team has been the champion, or win a match? Or do you also care to learn the exact score and some of the stats? These may not relate to the condition is(Able_to_Eat_IceCream), but they may be significant for you. Indeed, it may be relevant to even that condition, if your money was very little, already before buying the ice cream. The sports team data, however, may be altogether irrelevant to the icecream issue, and that data may be kept altogether separate.
The numbers, and other data, is part of data-modeling. You can add them, store them, recall them, and unlike in the case of events-modeling, data-modeling does not ussually care what comes before what, except maybe, at the limit values if any such is defined. As long as you buy both bread and icecream, you only add their prices and/or calories - whichever is the important one. With probably any data-modeling system, you may flexibly represent such numbers, without care to event-sequencing.
In contrast, a purely event-sequencing tool still may represent data-values, but not always very conveniently. The boolean values, and even to some extent integer values may be readily included in process-modeling. Expecting further may be dependent on the particular modeling-tool used. With Petri nets, which uses reachability graphs to test some valued criteria, even the integer-handling is not standard. (I do not even know whetehr anybody does it. But it can be done as long as the range of integers is small. But that may still increase the run-time of the reachability-graph testing quite a bit.)
Data-manipulation, where we unite a sequence of events with data, may be at an individual-item level, or manipulating a whole set (group) at once. For example, at your home, you may ask every person whether he/she is hungry. Alternatively, you may also query aloud "Is there anyone hungry and would like to eat some orange?" When someone answers, that is a query-result at a group-lvel. The individual-asking may be less costly, in general - at home, a baby may be sleeping. Group-level query may be easier, if you can formulate the question in appropriate words, to be asked all the members, at once.