A Semiotics-inspired Domain-Specific Modeling Language for Complex Event Processing Rules

by   Herbertt Diniz, et al.

Complex Event Processing (CEP) is one technique used to the handling data flows. It allows pre-establishing conditions through rules and firing events when certain patterns are found in the data flows. Because the rules for defining such patterns are expressed with specific languages, users of these technologies must understand the underlying expression syntax. To reduce the complexity of writing CEP rules, some researchers are employing Domain Specific Modeling Language (DSML) to provide modelling through visual tools. However, existing approaches are ignoring some user design techniques that facilitate usability. Thus, resulting tools eventually has become more complexes for handling CEP than the conventional usage. Also, research on DSML tools targeting CEP does not present any evaluation around usability. This article proposes a DSML combined with visual notations techniques to create CEP rules with a more intuitive development model adapted for the non-expert user needs. The resulting tool was evaluated by non-expert users that were capable of easily creating CEP rules without prior knowledge of the underlying expression language.



There are no comments yet.


page 1

page 2

page 3

page 4


Modeling Support for Domain-Specific Application Definition

In this paper we present the modeling support infrastructure for domain-...

A Generative Approach for User-Centered, Collaborative, Domain-Specific Modeling Environments

The use of low- and no-code modeling tools is today an established way i...

SchenQL -- A Domain-Specific Query Language on Bibliographic Metadata

Information access needs to be uncomplicated, users rather use incorrect...

Towards A Virtual Assistant That Can Be Taught New Tasks In Any Domain By Its End-Users

The challenge stated in the title can be divided into two main problems....

EQUS – helping to see formulae

Visualisation is often presented as a means of simplifying information a...

Complex System Design with Design Languages: Method, Applications and Design Principles

Graph-based design languages in UML (Unified Modeling Language) are pres...

Using DeepProbLog to perform Complex Event Processing on an Audio Stream

In this paper, we present an approach to Complex Event Processing (CEP) ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Nowadays many systems (e.g., enterprise systems, social networks) and devices (e.g., the Internet of Things) are producing data massively. Many techniques and tools are being developed to store and analyze these massive amounts of data being generated. There is also need to handle the continuous data almost at the same time it is being received, with fast responses in a very low latency. This introduces other techniques and tools for the processing of continuous flows of data [1]. The concepts of timeliness and flow processing are justifying new classes of systems to handle these flows, with two emerging models competing today: data stream processing and complex event processing [2].

In this article, we are particularly interested in Complex Event Processing (CEP). Through the usage of expression languages, CEP allows to capture data patterns in flows of information easily and to describe how rule engines can process data from these flows. It makes possible to trigger events out of complex relations from data flows. However, the fact of rules being expressed with query languages makes it a niche specialty. It becomes almost exclusive for specialists users, hindering the creation of solutions by a broader audience [3].

As observed by Roznyai et al. [3], there is a lack of tools that allow users to reconfigure a system easily or to refactor services and components in event-based systems such as the ones employing CEP. The Web-based interface approach of Chen et al. [4] for managing CEP engines and drawing rules with a flow-based approach, is an attempt to reduce the labor-consuming work of designing rules. However, one of the limitations of such approach is that it is coupled to particular CEP engines and technologies. Other efforts [5, 6, 7] provide an abstraction layer, relying on Model-Driven Development (MDD) and Domain Specific Modeling Language (DSML) to decrease the complexity of using CEP. With this approach it is possible to create rules with graphical and high-level textual definitions that can be transformed into lower level languages, avoiding syntax or typing mistakes.

However, a major issue with existing DSML approaches for CEP is that many of these tools become more complex for their own use than the conventional use of an event query language [8]. They abstract the problem of written language, but they introduce a usability issue on the composition of the concepts and diagrammatic theory. It is clear that no design or usability approach addressed to end users is applied to consider more robust visual concepts. For instance, semiotics [9], which is the study of signs, is very close to the study of models since these are made of signs and symbols [10]. What we found that the few existing DSML tools for CEP described in literature did not show any concerns with the creation of signs used in the tools neither present any validation with actual users. Therefore, user perception of the developer tools was not an important concern in existing research.

In the work we present here, we describe our DSML approach in the creation of a tool that uses many semiotics-based principles [11] to enhance the expressiveness of the elements used for visually composing CEP rules. The resulting tool allows users to model rules through visual elements that represent higher level abstractions and to generate queries for different CEP engines. Our approach followed the three-step metamodeling process proposed by Brambilla et al. [12]. We also employed Feature-Oriented Domain Analysis (FODA) [13] to help to model the language and a strong foundation [11] for visual representation to model the tool aiming to improve its usability and effectiveness. An empirical assessment was performed as part of the validation with actual users. The practical tests observed the success rate of non-specialists using our tool and an assessment through a Post-Study System Usability Questionnaire (PSSUQ) [14].

The major contributions that make our work different from existing literature is that: we provide a feature model describing the characteristics of the language; we apply semiotics principles to enhance the expressiveness of the visual language, and we provide concrete evidence of the visual tool being easy to use and intuitive. The remainder of this article is structured as follows. Section 2 presents theoretical background to better understand the context and concepts used in ou work; section 3 analyzes related work; section 4 introduces the proposal of this work; section 5 details the solution we implemented, followed by section 6, where is presented the assessment accomplished; and section 7 concludes the article.

2 Background

This section provides some contextualization on CEP as well as on semiotics applied to DSMLs, which are two of the main concepts behind the work presented in this paper.

2.1 Complex Event Processing

CEP uses an event-driven approach. It allows changes in state to be monitored as they happen, letting applications respond more time-efficiently than a batch approaches [15]. CEP is appropriate when there is a need to perform real-time or quasi-real-time processing of incoming information flows to produce new knowledge. It requires an expressive language to describe how incoming information has to be processed, allowing to specifying complex relationships among the information items that flow into the engine and are relevant to sinks. The CEP engine captures sequences of data involving complex ordering relationships, allowing to perform filtering, correlation, and aggregation of data [2].

CEP are specialists systems that support decision-making, where the specialized knowledge is encoded by experts on the domain [16]. Furthermore, this category of system uses ”rules” (or event patterns) to define if the established goals (conditions) was satisfied. Two important concepts in this context are presented in the next subsections: events and language for CEP.

2.1.1 Events

Bass [17] reinforces that an event is anything that happens or that might be considered an occurrence. For instance, a change of temperature, incoming messages or sensor readings. Therefore, the word event is overloaded, defining one the one hand the current meaning, and on the other hand the meaning related to information processing. The context of each event will set the meaning or destination. This paper will consider that an event is a change in the state of an object, or over the time slice[18].

2.1.2 Languages for CEP

Eckert and Bry[19] point out that the requirements for an event query language might be defined by the following four aspects illustrated below. The examples queries are written in the Event Processing Language (EPL) [15] , which defines CEP rules for Esper111http://www.espertech.com/ technology, being very similar to SQL database queries:

  1. Data Extraction: Events should have relevant data to decide if and how to react to them. The data access should be feasible regarding queries and capable of feeding other data sources, and should allow the creation of new events.

    select * from MyEvent.win:keepall()

  2. Composition: It should be viable to join many individual events, so their occurrences combined over the time can produce a complex event.

    select fraud.accountNumber as accntNum, fraud.warning as warn, withdraw.amount as amount, MAX(fraud.timestamp, withdraw.timestamp) as timestamp, ’withdrawlFraud’ as desc from FraudWarningEvent. win:keepall() as fraud, WithdrawalEvent. win:keepall() as withdraw where fraud.accountNumber = withdraw.accountNumber

  3. Temporal Relatioships: Query events that imply in temporal expressions conditions should be happening at a specific time window or in a specific order. Other relationships between events, such as causality, should also be considered.

    select * from Withdrawal.win:time(10 sec ) where amount >= 200

  4. Accumulation: Queries should involve the negation (lack) or aggregation of data events not caught in a stream. Since it is continuous flows, events could be correctly received when the stream ends. Thus, these queries need to be applied to a finite slice (a time slice or ”window”) of a stream, where their outcomes could be clearly well defined.

    select avg(price) from stockTickEvent.win:time(30 sec)

2.2 Model-Driven Development

The development of the proposed language was made using a Model-Driven Development (MDD) approach [20]. Typically, its implementation is (semi) automatically generated by metamodels [12]. With MDD it is possible to follow the paradigm both addressing a General-Purpose Languages(GPLs), as well following the implementation of a domain-specific language. A modeling language is defined based on three basics concepts [12]:

  • Abstract Syntax: Describes the structural language and how the different primitives can be joined, apart from any specific representation or encoding.

  • Concrete Syntax: Describes the specific representations of the modeling language, covering encoding and visual appearance problems. The concrete syntax can be both textual as well graphic. If the syntax is visual, the modeling will result in one or more diagrams.

  • Semantics: Describes the meaning of the elements defined in the language and the meaning of the differents ways of combining them.

2.3 Visual Notation Foundations

Moody [11] claims that we have neither theory nor a systematic body of empirical evidence to guide us in the evaluation and construction of visual notation in Software Engineering. So, we take that work, strongly based on semiotics, as our theoretical foundation to guide us in the creation of useful and effective visual representations. According to Moody, the anatomy of a good visual notation consists of:

Visual Syntax    =
Graphical Symbols     +
(Visual Vocabulary)
Compositional Rules
(Visual Grammar)

A good notation should have cognitive effectiveness which defines the accuracy, ease and the speed with which the human mind can process a representation [11]. In order to provide a scientific basis for the assessment and design of visual notations, some base theories are needed, such as Descriptive Theory [21]. It points out how and why friendly visual notations can improve the capacity of communication, becoming a base to Prescriptive Theory which define principles on the transformation of visual notations projects. The Prescriptive Theory [22] is the basis for the construction of the concrete syntax in our proposition. The main principles we employed in our work are presented as follows:

Semiotic Clarity: There must be a one-to-one correspondence between constructs and symbols. Otherwise, one or more types of anomalies can occur, such as symbol redundancy, symbol overload, symbol excess and symbol deficit.

Complexity Management: proposes that a visual notation representing abstracted information should not generate overloading in the human mind. Figure 1 presents the concept of complexity management, from utilization of levels hierarchy to define abstraction and decomposition of models [11]. Modularization is another good strategy for reducing the complexity of large systems.

Graphic Economy: It is related to the degree of complexity of notation, defined by the number of graphic symbols or size of the visual vocabulary [23]. The use of more representative symbols generates graphic economy by the fact that fewer symbols necessary to transmit the information, reducing the notation complexity.

Cognitive Fit: The notations should be done addressed to users, considering mainly the difficulties and the means that the diagrams will be transmitted (computer program, paper, blackboard, etc.).

Perceptual Discriminability: The accurate discrimination on how symbols differ from each other is paramount for appropriate interpretation of diagrams.

Fig. 1: Complexity management over the hierarchy into levels [11]

3 Related Work

This section presents a brief analysis of the projects that are most similar to our proposition of DSML for CEP. We point out their main characteristics and limitations. The choice was the result of a systematic mapping following the recommendations of the guidelines suggested by Kitchenham [24]. Due to space constraints, the details of this selection process were left out of this paper but are available online222https://goo.gl/HdPYLf. The following three articles were the most emphasized according to the criteria of mapping analysis:

The work of Bruns et al. [5] present a domain specific language for event processing in machine-to-machine (M2M) platforms. It has a general vision of an event class architecture of three different types (Machine Events, Key Performance Indice Events, and Operation Events). Based on this structure they created a language following the essential concepts of the Object Management Group (OMG)333http://www.omg.com recommendations. The language is textual and presents Text-Text (T2T) transformation, using Backus-Naur Form (BNF) and the Xtext tool444https://eclipse.org/Xtext/, for the creation of abstract and concrete syntax of the language. It was focused on the solar energy industry domain, to increase the productivity of software development and to improve the quality of CEP systems. However, they do not provide a clear description of the metamodel or how it was developed. Moreover, the tool focuses on text-to-text transformations, which might be considered a disadvantage against visual approaches, since it provides a lower abstraction [25].

Thaer et al. [6] propose a solution using a model-driven approach to creating automatic adapters of incompatible web services interfaces. This solution uses model transformation in a graphical editor, which models interfaces with high-level abstraction and generates the suitable code for its adapters. The generated code is specific to the target complex event processing engine. Their approach has four main features: service interface modeling, compatibility test, incompatibility detection, adapter generation, and CCL code generation and deployment. The tool allows validation, model-model transformation and code generation using an MDD approach. The Graphic User Interface (GUI) employs an activity diagram notation. They GUI was built using the Epsilon tool 555http://www.eclipse.org/epsilon/, for semantical validation the Epsilon Validation Language (EVL) was used, and the Epsilon Generation Language (EGL) to generate the source code. Despite the fact that the activity diagram is a common notation to many users, cases where a more complex rule definition is required would demand the utilization of a large number of activities. It leads to a very cluttered graphical description, which may result in difficulties in the modeling of larger systems [8]. Besides, since this type of diagram is very homogeneous, it becomes less intuitive in the usage of different elements involved in a CEP rule. Thus, it is limited in regards to the perceptual discriminability [11] of the visual syntax.

Boubeta-puig et al. [7] propose a solution also using a model-driven approach for CEP domain specialists and non-specialists, focused in the construction of event patterns using a graphic tool. It proposes the easier creation of patterns and generation of automatic code. The tool allows validation and model-model transformation, and the code is generated using an MDD approach. The GUI construction employs a notation that allows other EPL languages to be extended. It also used EVL for source code generation. As a consequence of using many detailed concepts, a diagrammatic visual language with high visual expressivity presents visual noise and low semiotic clarity [11]. Therefore, this approach reveals itself as little intuitive. Tasks with a large number of graphic resources have a confusing visual description.

None of the analyzed approaches provided any details on assessments or validation made with actual users. They also claim fewer lines of code, but this is natural with DSML, and more productivity, although no quantitative or qualitative data is presented. We also found that only two of them had a visual approach, but did not follow any guideline or foundation aiming to be intuitive or ease to use.

4 Proposal

As analyzed in the literature, there is a major gap in the visual notation background of existed DSML tools for writing CEP rules. Here we attempt to address that by bringing a strong background in the modeling and conception of the solution, both in the metamodeling approach and in the modeling of the visual tool’s elements. The DSML developed in this work followed the three-step metamodeling process proposed by Brambilla et al. [12] (Figure 2). The first step consists on the Domain Analysis Modeling, followed by the Language Design Modeling where the construction of the abstract syntax happens, and finally the Language Validation Modeling for the construction of the concrete syntax.

Fig. 2: Metamodeling process used in the DSML development [12]

4.1 Domain Analysis Model

In this initial analysis we employed Feature-Oriented Domain Analysis (FODA)[13], which helped identify the main characteristics and the relationships between the main components of the solution. The domain analysis was performed by analyzing the literature and CEP languages (Esper and Drools Fusion666http://drools.jboss.org/drools-fusion.html), and interviewing CEP specialists.

The feature model developed in this first phase was the output of the domain analysis, as illustrated in Figure 3. It presents the necessary components to model and compose a CEP rule. In the following topics the description of each component defined in the feature model is presented:

  • Rule: Represents a CEP rule. It has necessarily an Event, and can optionnaly have a Window, an event group (StdGroup), an EventPattern, an outcome event (EventOutput) or a (Constraint);

  • Event: They are the events of a CEP rule, with properties described through Attribute components.

  • EventPattern: Defines a logical composition for rules.

  • EventOutput: Output of a triggered rule.

  • Window: Represents the concept of a time window used in CEP rules. It can be temporal (Timer) or quantitative (Counter)

  • StdGroup: It represents the concept of grouping, in simple events in the rules of CEP.

  • Constraint: Logical restrictions that can be established in a CEP rule. They can be of two types: GroupBy which represent constraints by grouping and Condition type that set constraints through condition operators.

  • Attribute: Defines event attributes or the structure of the elements of an event.

  • Condition: It has conditional operators: they can be a simple value (ValueOperator), an attribute type operator (Operator) or an aggregation function (Avg, Sum, Max, etc).

  • PatternOperators: Represents pattern operators, which can be AND, OR, NOT or FollowedBy, to define logical relationship between events.

  • PatternTimer: Defines temporal conditions in event patterns. They can be of type WithIN and WithINMAX.

  • RepetitionsPattern: Defines repetitions patterns in programming, which can be of type Every, Every_Distinct, Range, While and Until.

  • ValueOperator: Defines free values to compare with operators.

  • Operator: Defines attributes to compare with logical operators.

  • AggregationFunction: Defines aggregation fuctions of type: Avg, Sum, Max, Min and Count, to compare with logical operators.

Besides being a typical output of the domain analysis, we chose the usage of a feature model because it is an approach with good expressivity and also able to remove ambiguities [26]. For instance, it is possible to express optional or mandatory components in a much cleaner way than in UML, which is the approach of other tools.

4.2 Language Design Modeling

The second step of the metamodeling process was broken down into two phases:

  • Metamodel definition: After the feature model was defined, the metamodel was specified to refine the concepts of the feature model and to formalize the conceptual model, creating the necessary basis for its implementation.

  • Object Constraint Language: This phase defines the basic constraints based on the defined model, preserving their integrity.

Fig. 3: Feature model of a CEP rule

4.3 Language Validation Modeling

In the third step of the metamodeling process, the concrete syntax was built. The graphical representation of the metamodel was omitted to preserve space, but can be accessed online 777https://goo.gl/D16esS. The metamodel was created with the intention of facilitating the use of the tool, through the incorporation of semiotics principles (Complexity Management, Graphic Economy, Cognitive Fit) [11] in two concepts:

Modularization: The concept of logical grouping developed in the language is based on the principle of Modularization, which establishes channels with greater representativity for variables to be defined in a compartmentalized way. It can be seen that clusters are decomposed according to their purpose in the structure of the language of event processing languages (e.g., Esper). Thus, the rule component (Rule) has its scope defined into four logical groups:

  • Bring Group: Represents all logic, to appear in a query of the CEP code language.

  • Target: Groups logic related to CEP events. In addition to the concept of modularization, Target, is also present in the concept of complexity management through hierarchies, which is the key part in this composition. It is possible to group all logic related to events related to this component.

  • ConditionGroup: Groups the conditioning logic so that an event occurs or information is brought in according to what has been established.

  • GroupbyCondition: Grouping the conditioning logic, by grouping specific attributes, for an event to occur or for information to be brought in accordance to what has been established.

Hierarchy: The hierarchical diagramming feature concentrates the definition of the event logic (Events), event patterns (EventPatterns), event windows (Windows), and groupings in events (StdGroup). The hierarchical model structures the logic of action rules of the diagrammatic model. The Target component is the representation of the concept of ”boxes-within-boxes” based on Simon[27], representing an abstraction of the components that bind to it.

5 Solution

This section presents details of the solution we implemented. We also discuss many of the concepts taken from Moody’s work [11] and applied in the construction of the DSML CEP tool. The tool is freely available for download on GitHub888https://github.com/herbertt/DSMLCEP. The Graphic User Interface(GUI) was built with Epsilon999http://www.eclipse.org/epsilon/ tool, the validation of the language with Epsilon Validation Language (EVL) and Epsilon Generation Language (EGL) for code generation.

The tool allows creating graphically-defined rules to be converted to other CEP code languages automatically. Figure 4 illustrates an example of the diagrammatic visual language showing a textual query in Esper’s EPL and the corresponding visually modeled query. The current implementation can make transformations to EPL. We are currently implementing the transformation to Drools Fusion.

Fig. 4: Example of model rule for a Pluviometer

5.1 Tool Overview

Figure 5 shows a general perspective on the tool. The screen is divided into draw area (1); constructors palette (2); properties and export (3); and export button (4). The draw area is where the user composes the visual diagrams representing the rules that originate the CEP queries. The constructors palette is discussed in more details on the next subsection since it involves many of the visual concepts from Moody [11]. In the properties and export tab it is possible to establish input values for instantiated component properties in the drawing area of the diagram, the export is responsible for displaying the text template transformation code. The save button saves the template and sends the rule to the message broker to deploy the generated query. The export button activates the Model-to-Text transformation (M2T), displaying results in the export tab.

Fig. 5: General perspective of the DSML CEP tool

5.2 Visual Language Constructs

In the constructor palette, described in Figure 5, components are arranged so as to assemble the entire diagrammatic context. According to a logic of mnemonic association, we intentionally induce users to create their rules using components following an intuitive top-down sequence in the palette. The higher abstractions (e.g., objects) necessary for a rule are placed in the upper sections, and the more fine-grained details (e.g., operators) to build a rule are in the lower part of the palette. In this way, for any rule being modeled, a user starts naturally following this sequence of sections (top-down) to use the language constructs. It has symbols with a graphic representation, textual description and different formats to obtain a greater Graphic Economy and Perceptual Discriminability. The palette is organized into the following sections:

Objects: Establishes the main components of the drawing area.

Ensembles. Sets the grouping components, BringGroup, ConditionGroup, GroupbyCondition, Target, to segment the rule’s structural logic in the concept of modularization [11].

Target Connector. Has a LinkTarget component which is responsible for connecting to target type groups. The dotted lines, depicted in Figure 1 and in Figure 4 attempt to represent a 3D vision of what a LinkTarget represent in 2D, implementing the concept of Cognitive Fit [11].

Operational Components. Holds the operational components that perform the logic built into the groupings.

Operational Connectors. The Comparison, Arithmetic and LogicalConnector components represent the relationships of their binary logical types, between grouping components and operational components, except for the NOT component.

Pattern Components. Holds the connectors and components which perform the logical operations built inside EventPattern.

Fig. 6: Detail of the constructors sections.

6 Solution Assessment

Trying to address the lack of assessments or validation made with actual users in other DSML tools for CEP, we performed an experiment to evaluate the usability of the tool presented in this paper. This section presents the detailed assessment of the proposed solution in this work.

6.1 Methodology

The methodology we employed to evaluate the usability of the tool was based on: (1) the observation of the success rate of users visually modeling rules and generating correct queries; and (2) the analysis of the results of a Post-Study System Usability Questionnaire (PSSUQ) [14] applied to participants.

We ultimately intended to evaluate if the tool was easy and intuitive. The former concerns the solution allowing programmers not specialized in CEP to create rules patterns easily. The latter concerns the usability of the GUI, allowing any user, independent of their ability or programming knowledge, to be able to understand all the information and interact with the tool. We defined one-hour training, involving basic CEP content and usage of the tool, for leveling and presentation of content necessary to be used. The evaluation was organized as follows:

  • Experimental Group: Nine participants (students from our university department) were involved in this experiment. Except for one participant who had previously worked with MDD and CEP in a different setting, the rest of the group had no previous experience with CEP, and only two of them had some prior experience with MDD. The data from a tenth participant was discarded to avoid bias because he was a beta tester that already knew the tool.

  • Example Definition: Two situations of CEP usage were describe as natural language in plain text in a generic domain (banking withdrawals). Participants had to read and understand the problem and visually model two rules (R1 and R2) using the tool.

  • Solution Evaluation: Following the two examples, to be graphically modeled. The participants of the experimental group executed each rule they defined comparing the result of its transformation with the respective correct responses in pre-defined queries written in EPL and made available to them only after both tasks being finished.

6.2 Results and Discussion

The outcomes of the assessment are summarized in Table I, detailing the profile of each participant and which rules they successfully built using the tool:

  • 1 PhD student: Already worked with MDD tool and has used CEP tools sporadically. He did not complete the visual rules correctly.

  • 4 BSc students: Never worked with MDD tools and with CEP tools. All finished R1 correctly. In R2, two did not complete, and two completed correctly.

  • 2 MSc students with MDD experience: They had limited contact with MDD tools but have never used CEP tools. They completed all visual rules correctly.

  • 2 MSc students without MDD experience: Never worked with MDD and never used CEP tools. They completed all visual rules correctly.

Level Rules Experience in MDD Experience in CEP
R1 R2 None Low High None Low High
TABLE I: Results and profiles of participating students

As observed on Table I, most participants did not have knowledge in MDD and CEP tools. Nevertheless, all of the eight subjects who are non-experienced with CEP could finish the first rule (R1) correctly. Among those, only two (25%) of the non-experienced could not finish the second rule (R2). R2 is slightly more complex than R1. Therefore a smaller success rate was more likely. The surprising result was the experienced Ph.D. not being capable of finishing correctly. We suspect his previous knowledge may be a strong bias that affects his understanding of the tool. However, we have no concrete evidence to support that claim.

Concerning the questionnaire, we merged two original PSSUQ questions into Q3 due to strong similarity of terms when translated into Portuguese (effectively versus efficiently). The questionnaire consists of a 1-7 Likert scale where one (1) stands for ”Strongly Agree” and 7 for ”Strongly Disagree.” Grades greater than three (3), were considered as a good perception of the tool, four (4), was seen as neutral, and values greater than five (5) consisted of disapproval. When analyzing the Likert scale responses as intervals and applying descriptive statistics to it (Table

II), we see a central tendency toward a positive perception of the tool. The only exception is Q11, which is a rather neutral response. Q18 provides an overall positive user perception of the tool. Therefore, the observation and the usability questionnaire results show evidence of good usability of the tool. Without much training, users could easily learn how to make CEP rules, intuitively and without help.

Question Mean St.Dev Median Mode
Q1. Overall, I am satisfied with how easy it is to use this system 2,8 1,6 2 2
Q2. It is simple to use this system 2,9 1,6 3 4
Q3. I can effectively complete my work using this system 2,7 1,3 3 3
Q4. I am able to complete my work quickly using this system 3,1 1,4 3 3
Q5. I feel comfortable using this system 3,2 1,6 3 2
Q6. It was easy to learn to use this system. 3,0 1,5 3 2
Q7. I believe I became productive quickly using this system. 2,4 1,2 2 2
Q8. The system gives error messages that clearly tell me how to fix problems. 3,9 2,1 3 3
Q9. Whenever I make a mistake using the system, I recover easily and quickly. 2,7 1,3 3 3
Q10. The information (on-line help, on-screen messages, documentation) provided with this system is clear 3,4 1,9 3 2
Q11. It is easy to find the information I need 3,6 1,4 4 4
Q12. The information provided with the system is easy to understand 3,3 1,6 3 3
Q13. The information is effective in helping me complete my work 2,9 1,3 3 2
Q14. The organization of information on the system screens is clear 2,4 1,7 2 1
Q15. The interface of this system is pleasant 1,9 1,4 1 1
Q16. I like using the interface of this system 2,2 1,3 2 2
Q17. This system has all the functions and capabilities I expect it to have 3,1 1,8 3 4
Q18. Overall, I am satisfied with this system 2,7 2,1 2 1
TABLE II: Statistics of responses (1-7 Likert scale) of the usability questionnaire [14]

6.3 Threats to Validity

A significant point that can raise questions about the validity of the experiment is linked to the fact that the evaluation was done with students and not with professionals. However, according to Salman et al., [28], students and practitioners tend to perform similarly in software engineering experiments that evaluate development approaches in which participants do not have prior experience. Therefore, the use of only students in the analysis was considered little relevant. Another validity issue is how to objectively calculate if the solution developed is intuitive, the degree of intuition is purely subjective and can not be determined only by objective metrics. Also, the complexity and level of difficulty of the rules the participants had to model are limited. A scenario with more elaborate rules resulting in more advanced queries would be required for a deeper study. The empathy of some participants toward the authors of the tool may have influenced the responses. However, the subjects were instructed to be honest in their opinions.

7 Conclusions and Future Work

Complex Event Processing is emerging as a critical approach to analyzing flows of information. It allows to capture patterns in such flows easily and to describe how rule engines can process flow data or fire events. However, there is a lack of tools supporting the easy construction of CEP rules. Existing DSML approaches for CEP trying to tackle that issue have cluttered metamodels for describing them and tools more complicated than the conventional use of an event query language. In part, this is due to a lack of foundation or guidelines in the construction of metamodels and the modeling tools. The lack of validation with actual users was another limitation found with existing approaches.

We followed a metamodeling process [12] and a set of semiotics-based visual guidelines [11] for the construction of a CEP DSML tool that takes usability principles into account. The assessment we performed with non-experienced users show evidence of good usability of the tool. With little training, users could easily learn how to make CEP rules, intuitively and without help.

The major contributions are a feature model describing the characteristics of the language; the demonstration of semiotics principles to enhance the expressiveness of the visual language, and the concrete evidence of a visua DSML tool for CEP being easy to use and intuitive. As future work, we plan to do evaluations with more complex queries and integrate the tool into an event-based distributed platform.


  • [1] C. P. Chen and C.-Y. Zhang, “Data-intensive applications, challenges, techniques and technologies: A survey on big data,” Information Sciences, vol. 275, pp. 314–347, 2014.
  • [2] G. Cugola and A. Margara, “Processing flows of information: From data stream to complex event processing,” ACM Computing Surveys (CSUR), vol. 44, no. 3, p. 15, 2012.
  • [3] S. Rozsnyai, J. Schiefer, and A. Schatten, “Concepts and models for typing events for event-based systems,” in Proceedings of the 2007 inaugural international conference on Distributed event-based systems.   ACM, 2007, pp. 62–70.
  • [4] C. Y. Chen, J. H. Fu, P.-F. Wang, E. Jou, and M.-W. Feng, “Complex event processing for the internet of things and its applications,” in 2014 IEEE International Conference on Automation Science and Engineering (CASE).   IEEE, 2014, pp. 1144–1149.
  • [5] R. Bruns, J. Dunkel, S. Lier, and H. Masbruch, “Ds-epl: domain-specific event processing language,” in Proceedings of the 8th ACM International Conference on Distributed Event-Based Systems.   ACM, 2014, pp. 83–94.
  • [6] Y. Taher, J. Boubeta-Puig, W.-J. van den Heuvel, G. Ortiz, and I. Medina-Bulo, “A model-driven approach for web service adaptation using complex event processing,” in European Conference on Service-Oriented and Cloud Computing.   Springer, 2013, pp. 346–359.
  • [7] J. Boubeta-Puig, G. Ortiz, and I. Medina-Bulo, “A model-driven approach for facilitating user-friendly design of complex event patterns,” Expert Systems with Applications, vol. 41, no. 2, pp. 445–456, 2014.
  • [8] J. White, D. C. Schmidt, A. Nechypurenko, and E. Wuchner, “Reducing the complexity of modeling large software systems,” Designing Software-Intensive Systems: Methods and Principles: Methods and Principles, 2008.
  • [9] D. Chandler, “Semiotics for beginners,” 1994.
  • [10] J.-M. Favre, “Foundations of model (driven)(reverse) engineering: models–episode i: stories of the fidus papyrus and of the solarus,” in Dagstuhl Seminar Proceedings.   Schloss Dagstuhl-Leibniz-Zentrum für Informatik, 2005.
  • [11] D. Moody, “The “physics” of notations: toward a scientific basis for constructing visual notations in software engineering,” IEEE Transactions on Software Engineering, vol. 35, no. 6, pp. 756–779, 2009.
  • [12] M. Brambilla, J. Cabot, and M. Wimmer, “Model-driven software engineering in practice,” Synthesis Lectures on Software Engineering, vol. 1, no. 1, pp. 1–182, 2012.
  • [13] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson, “Feature-oriented domain analysis (foda) feasibility study,” DTIC Document, Tech. Rep., 1990.
  • [14] J. R. Lewis, “IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use,” International Journal of Human-Computer Interaction, vol. 7, no. 1, pp. 57–78, 1995.
  • [15] O. Etzion and P. Niblett, Event processing in action.   Manning Publications Co., 2010.
  • [16] P. Vincent, “What is Complex Event Processing. The CEP Blog,” 2010. [Online]. Available: http://www.thetibcoblog.com/2010/03/12/the-return-of-the-expert-system(visitedfebruary2,2016)
  • [17] T. Bass, “What is Complex Event Processing. The CEP Blog,” 2007. [Online]. Available: http://www.thecepblog.com(visitedfebruary2,2016)
  • [18] D. Luckham, “The power of events: An introduction to complex event processing in distributed enterprise systems,” in International Workshop on Rules and Rule Markup Languages for the Semantic Web.   Springer, 2008, p. 3.
  • [19] M. Eckert and F. Bry, “Complex event processing (cep),” Informatik-Spektrum, vol. 32, no. 2, pp. 163–167, 2009.
  • [20] C. Atkinson and T. Kuhne, “Model-driven development: a metamodeling foundation,” IEEE software, vol. 20, no. 5, pp. 36–41, 2003.
  • [21] C. Shannon and W. Weaver, “The mathematical theory of communication,” Urbana:Univ. of Illinois Press, vol. 29, pp. 104–107, 1949.
  • [22] S. Gregor, “The nature of theory in information systems,” MIS quarterly, pp. 611–642, 2006.
  • [23] J. C. Nordbotten and M. E. Crosby, “The effect of graphic style on data model interpretation,” Information Systems Journal, vol. 9, no. 2, pp. 139–155, 1999.
  • [24] B. Kitchenham and S. Charters, “Guidelines for performing Systematic Literature Reviews in Software Engineering,” Keele Univ. and Durham Univ. Joint Report, Tech. Rep. EBSE 2007-001, 2007.
  • [25] L. Engelen and M. van den Brand, “Integrating textual and graphical modelling languages,” Electronic Notes in Theoretical Computer Science, vol. 253, no. 7, pp. 105–120, 2010.
  • [26] D. Beuche and M. Dalgarno, “Software product line engineering with feature models,” Overload Journal, vol. 78, pp. 5–8, 2007.
  • [27] H. A. Simon, The sciences of the artificial.   MIT press, 1996.
  • [28] I. Salman, A. T. Misirli, and N. Juristo, “Are students representatives of professionals in software engineering experiments?” in Proceedings of the 37th International Conference on Software Engineering-Volume 1.   IEEE Press, 2015, pp. 666–676.