The Cumbia Project


Cumbia is a research project developed at the Software Construction Group of Uniandes which is mainly related to the topics of Model-Driven Engineering (MDE), model execution and behavioral semantics, workflow languages, and workflow engines development.

This website provides information about the Cumbia project and its main components (the Cumbia framework for workflow language development and the Cumbia Kernel for model execution), and also about the case studies that we have developed.

To request further information, or to send us feedback, please send us a mail!

Cumbia is a model-based platform that leverages executable models. The idea of Cumbia is to combine the power of a model driven engineering (MDE) approach, to create execution environments for languages in a variety of contexts. In most of our case studies, we have focused on the application of Cumbia to the workflow context, and we have constructed a number of engines for well-known languages such as BPEL, BPMN, IMS-LD, and YAWL, and also for in-house workflow specification languages (XPM, PaperXpress).

By using this architecture, the development of engines for new workflow languages does not have to start from scratch. Instead, engines are built on top of a reusable workflow kernel that can be configured to support different workflow languages. Furthermore, the engines built using this kernel are more adaptable and more extensible than currently available engines.

More recently, we have started applying Cumbia to the context of Enterprise Architecture Analysis. In this case, we are developing a tool for simulating enterprise architecture, which strives to offer extreme capabilities for flexibility and evolution.

There are four key ingredients to the proposal of Cumbia.

  1. A metamodeling platform for modeling workflow definitions
  2. Modularized workflow definitions using concern specific workflow languages
  3. Run time coordination of executable workflow models
  4. A platform based on Open Objects

A metamodeling platform for modeling workflow definitions

Cumbia offers the means to separate the implementation of the languages from the implementation of complementing functionalities. By doing so, the people in charge of implementing the semantics of the languages, do not have to implement those other functionalities, the implementation artifacts become more coherent, and the languages are more easily replaceable and modifiable. The following provides a graphical representation of the main elements in Cumbia that support the definition and enactment of workflow specification languages.

An execution platform based on metamodels

Since this is a metamodeling approach, the first element to consider is the metamodeling framework. It defines the abstractions to build metamodel definitions and represent the structures and semantics of the languages.

The second element in the proposal is a component called Execution Kernel (EK). The most important of its multiple responsibilities is to enact model definitions. To support this, the EK offers the means to load model definitions, instantiate them, and coordinate the runtime behavior and interaction of instance elements. The EK is generic and it requires access to the information contained in the metamodel definition to be aware of the elements, the structure, and the semantics of the enacted language. Additionally, the EK holds responsibilities, such as managing persistence, doing basic conformance verifications, offering interfaces to allow external interactions with the running model instances, and generating events to facilitate monitoring.

By using the EK as the foundation of every engine, the features it offers do not have to be redeveloped for each new language. Thus, the effort required to support a new workflow language is considerably reduced and makes the development of domain specific workflow languages more likely.

Another advantage to using a single workflow kernel to implement many workflow engines is making the reuse of complementary tools is more likely to occur. This is because workflow engines are typically developed in an ad hoc fashion and there are no commonalities between them at the code level. Therefore, the associated tool chains are also developed in an ad hoc way, and thus are difficult to reuse. On the contrary, if the same kernel is shared among various workflow engines, complementary tools can be developed against a common interface and be independent of the specific workflow language used.

Modularized workflow definitions using concerns pecific workflow languages

Currently, most workflow languages, and especially generic workflow languages, are monolithic and tend to include a large number of elements, which are not always closely related. Also, these languages offer only simple modularization strategies that are generally restricted to the hierarchical decomposition of processes.

Concern specific workflow languages and definitions

The approach that we propose employes a modularization strategy based on concern separation and inspired on multimodeling techniques. This strategy has two sides to consider. The first one, is that workflow definitions can be decomposed according to concerns. The second one, is that concern specific languages can be used to specify each part of an assembly. Therefore, these languages can be very expressive and employ high level elements adapted to each concern.

Run time coordination of executable workflow models

When concern specific workflow languages are used to describe a workflow, one or more models are built for each involved concern. Afterwards, these models have to be assembled to reconstruct the semantics of the complete workflow. In the Cumbia approach, workflow definitions are never combined. Instead, lightweight links are established between model instances, and these are used to coordinate their execution.

This strategy keeps concern specific models related in such a way that they can interact, while at the same time they are recognizable and have well defined borders and structures. The weaving between model instances is established after creating them, but before starting their execution, and it serves to coordinate their execution.

Additionally, the links established between model instances are modifiable at run time. This additional degree of flexibility complements the possibility of changing the structure of model instances at run time.

Coordination of workflow concerns

In order to coordinate a set of models, information additional to the models’ structure has to be provided. In Cumbia, this information is a weaving program written in a language called CCL (Cumbia Composition Language). This language is independent of the concern specific languages and thus a new composition language is not required when new languages are introduced.

A platform based on Open Objects

In order to implement a platform with the characteristics previously mentioned, we developed a notion called open objects. Open objects are the main modeling abstractions to build and implement the metamodels, and they encapsulate the structure of the elements and the behavior that they should have when used in models. Open objects also externalize their interaction with other elements in order to make this interaction flexible.

Basic components of an open object

In this website we have compiled all the information about the Cumbia project and about some of the relevant case studies that we have developed.

Complete information about Cumbia and about the open objects can be found in the publications section, in the theses section, and especially in the Ph.D. dissertation of Mario Sánchez (here).

To request further information, or to send us feedback, please send a mail!

You can write to Mario Sánchez at