The Event package defines a set of meta-model elements whose purpose is to represent high-level behavior of applications, in particular event-driven state transitions. Elements of the KDM Event package represent states, transitions and event. States can be concrete, for example, the ones which are explicitly supported by some state-machine based runtime framework or a high level programming language, such as CHILL. On the other hand, KDM Event model can represent abstract states, for example, states which are associated with a particular algorithm, resource or a user interface.
The EventModel class diagram follows a uniform pattern for KDM models to extend the KDM framework with specific meta-model element related to event-driven state transition behavior.
The class diagram shown in See - EventModel Class Diagram. captures these classes and their relations.
The EventModel is a specific KDM model that represents entities and relations describing events and responses to events in an enterprise application.
The EventInheritances class diagram defines how classes of the Event package inherit core meta-model classes from KDM Core package. The classes and associations that make up the EventInheritances diagram are shown in See - EventInheritances Class Diagram..
The EventResources class diagram defines specific event elements. The class diagram shown in See - EventResourcesClass Diagram. captures these classes and their relations.
The EventResource is the generic AbstractEventElement that can be instantiated in KDM instances.
The Event is the generic AbstractEventElement that can be instantiated in KDM instances.
The State class represents a state associated with certain behavior. This can be a concrete state, for example, supported by a state-machine runtime framework. This can also be an abstract state associated with some process, algorithm, component, or resource, discovered during the analysis of the software system. An example of an abstract state is the step of the protocol that involves a messaging resource. An abstract state may not have any direct and tangible manifestation in the artifacts of the software system. On the other hand, a concrete state may be implemented in a tangible way, for example, using a variable or as a class provided by the application framework. States can be nested.
The InitialState class is a subclass of the State class. It represents a default initial state.
The Transition class represents a transition that is performed when a certain event is consumed is a certain state. Transition element should be owned by some state element. Transition can be associated with the corresponding Event by using the "ConsumesEvent" resource relation. A transition element can also own some Event elements. Transition does not have an "implementation" group. Instead, it is considered as some sort of a trigger. The association between the transition and corresponding behavior is achieved through the "abstraction" action container of the transition. Usually, this is a Calls action relation. For more complex situations, the "CodeGroup" capability of the "abstraction" action element can be used.
The OnEntry class represents specific transitions that are configured to be performed by the runtime framework when a certain state has been entered.
The OnExit class represents specific transitions that are configured to be performed by the runtime framework when a certain state has been exited.
EventAction class follow the pattern of a "resource action" class, specific to the event package. The nature of the action represented by a particular element is designated by its "kind" attribute. Descriptions of the common platform action kind are provided in Appendix 2. Resource Layer actions.
EventRelations diagram defines meta-model relationship elements which represent several structural properties of event-driven systems. The class diagram shown in See - EventRelations Class Diagram. captures these classes and their relations.
The NextState class represents the knowledge that upon completion of the behavior associated with a certain transition element, the corresponding behavior will enter the given state. For example, in statically configured state-machine based frameworks this information can be derived from the initialization of framework specific data structures. When there exists several NextState relations originating from a given transition, this means that an unspecified choice is made by the behavior associated with the transition. More precise "abstraction" can be provided by using the "abstraction" action containers associated with various elements involved.
The ConsumesEvent class represents the knowledge that a certain transition element, is associated with a certain event. For example, in statically configured state-machine based frameworks this information can be derived from the initialization of framework specific data structures.
The EventActions class diagram defines basic KDM relations between The class diagram shown in See - EventRelations Class Diagram. captures these classes and their relations.
ReadsState class follows the pattern of a "resource action relationship". It represents various types of accesses to the state-based runtime framework that provides a concrete implementation of states, where access is made to a particular state (for example, accessing the current state, setting the next state). ReadsState relationship is similar to Addresses relationship from Action Package. The nature of the operation on the resource is represented by the "kind" attribute of the EventAction that owns this relationship through the "abstracted" action container property.
ProducesEvent class follows the pattern of a "resource action relationship". It represents various types of accesses to the state-based runtime framework where the application produces the event. ProducesEvent relationship is similar to Writes relationship from Action Package. The nature of the operation on the resource is represented by the "kind" attribute of the EventAction that owns this relationship through the "abstracted" action container property.
HasState class follows the pattern of a "resource action relationship". HasState is a structural relationship. It does not represent resource manipulations. HasState relationship uses the "abstracted" action container mechanism to provide certain capabilities to other Resource Layer packages. "HasState" relationship makes it possible to associate an element of an event model with any resource.
The ExtendedEventElements class diagram defines two "wildcard" generic elements for the event model as determined by the KDM model pattern: a generic event entity and a generic event relationship.
The classes and associations of the ExtendedEventElements diagram are shown in See - ExtendedEventElements Class Diagram..
The EventElement class is a generic meta-model element that can be used to define new "virtual" meta-model elements through the KDM light-weight extension mechanism
An event entity with under specified semantics. It is a concrete class that can be used as the base element of a new "virtual" meta-model entity types of the event model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.
The EventRelationship class is a generic meta-model element that can be used to define new "virtual" meta-model elements through the KDM light-weight extension mechanism
from:AbstractEventElement[1] |
The event element origin endpoint of the relationship |
to:KDMEntity[1] |
the target of the relationship |
An event relationship with under specified semantics. It is a concrete class that can be used as the base element of a new "virtual" meta-model relationship types of the event model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.