Creating Patterns

Event patterns are the highest-level parts of a model. Creating an effective model requires thinking carefully about the event patterns to create and their relationships to one another.

This section offers advice on how to plan models using event patterns, and how to create event patterns quickly and efficiently.

Starting in Hierarchial View

The hierarchical view is the first view a user encounters upon opening a project. This is meant to encourage both viewers and modelers alike to approach the subject of the project from a high level.

For modelers, starting a project by creating, naming, and arranging empty event patterns (that is, event patterns that do not have any logic defined inside them at first, and are used as placeholders) helps with planning and laying the foundations for the project. Users can also connect patterns during this planning process to establish input and output relationships between patterns.

Once an outline of the project is complete, the modeler may then take a deeper dive into each individual pattern to define additional pattern inputs, constraints, and computations.

When the modeler has completed a pattern and is ready to move on to another pattern, they navigate back to the hierarchical page to find a logical visual guideline that tells them what to work on next.

Providing Descriptive Names for Event Types and Event Patterns

One of the goals of the hierarchical tree and pattern views is to graphically represent the relationship between key factors. This way, someone unfamiliar with a project can easily grasp important context simply by viewing the hierarchical tree and patterns.

The project itself can become self-documenting with proper naming habits. Event types and logical operators are graphically represented in event patterns and hierarchical views solely by name. (A hierarchical view captures the relationship between event patterns, and one outcome can become the input of another event pattern.) Therefore, it is especially important to make them succinct and expressive.

When an event pattern needs to express a relationship between events of the same event type, the modeler should take advantage of the alias feature to provide some distinction between the different sub-groups.

Example

If a pattern is designed to extract email relationships between two employees, there may be a need to include two instances of an Employee event type. In this case, one instance may be given an alias Sender and the other Recipient. This way, it remains clear what each event type node represents.

Using Cloning for Repetitive Patterns

In some projects, it may be necessary to create near-identical patterns that differ only by a single input or output event type. In such cases, it is highly recommended that the user takes advantage of the "clone" feature for each pattern, especially for patterns that have complex constraints and computations.

Cloning a pattern creates a new pattern that contains identical references to input event types, constraints, computations, and output event types. In the clone, the modeler has the option to replace an existing event type with a new one if they share the same user data schema.

After clicking to select the event type to be replaced in the pattern, a dropdown menu appears to the right. There, the modeler may pick a new event type to replace it.

Experimenting Through Cloning

Another appropriate time to clone a pattern is when comparing solutions.

Instead of testing a pattern and editing over it to test a new approach, it is much easier to:

1. Clone the pattern.
2. Make changes to the cloned pattern.
3. After testing, delete the pattern that is no longer required.