How to Validate your Enterprise Architect BPMN Models

The BPMN notation is a good way to specify processes, may it be the workflow for a specific task or entire business processes. Such models may grow very large and you can easily lose track of certain details such as model correctness. 

Figure 1 shows an example for a BPMN model (using the BPMN 2.0 MDG Technology), a process for resolving problems which are reported via a ticket system.

Fig 1: BPMN Process example modelled with the Enterprise Architect (example source: OMG).

Do you see the Error?

Maybe you’ve noticed that the final node of the model does not have any incoming control flow edges but instead has an outgoing control flow edge.

Also the Activity ‘Insert issue into product backlog’ is not reachable, because it has no incoming edge. This leads us to the problem that the Enterprise Architect may (only) ensure that every BPMN model is syntactically valid: it prohibits modelling actions which would result in syntactically invalid BPMN models, e.g. a control flow to an element that does not belong to activities, like an Interface.

What the Enterprise Architect does not ensure is semantic correctness.

Formal Validation with OCL

A formal way to validate semantic restrictions on (BPMN) models is to use the Object Constraint Language (OCL) to define constraints the models must fulfill in order to be correct.

In our case we could define the following constraint to ensure that a final node does not have any outgoing control flow edge:

context a:Activity inv:

a.nodes -> forAll(node | not(node.oclIsTypeOf(FlowFinalNode)) or node.outgoing -> isEmpty())

But then an unconnected final node would still be valid and we also do not cover the unreachable activity. With another constraint we can ensure that every node in the model (except for initial nodes) has an incoming edge:

context a:Activity inv:

a.nodes -> forAll(node | node.oclIsTypeOf(InitialNode) or not(node.incoming -> isEmpty()))

Unfortunately, the Enterprise Architect has no feature yet to evaluate any formal constraints like OCL.

To evaluate the constraints on our model we use other tools to load our Enterprise Architect models and run OCL constraints on it.

Semantic Validation of BPMN Models in Eclipse

To show what is possible, we use the YAKINDU EA-Bridge to load our models and evaluate them with the OCL Console.

Once the Enterprise Architect model is loaded with the YAKINDU EA-Bridge, it can be browsed in a simple tree-based editor (as seen in Figure 2), element details are shown in the ‘Properties’ view.

Fig 2: Our Enterprise Architect model loaded with the YAKINDU EA-Bridge in Eclipse

 

Now we want to select the activity ‘BPMN 2.0 Business Process View’ and open the OCL Console (open the ‘Console’ View in Eclipse and select the ‘OCL Console’ in the drop-down toolbar icon of the view).

There we can enter our constraints and observe the evaluation result (Figure 3).

Please note that the plain constraint must be entered, the context of our invariants above is the currently selected element in the editor!

Fig 3: The OCL Console in Eclipse

 

Once we have run our evaluation and got the result that the model violates the constraints, we can fix our BPMN model and run the OCL evaluation on the corrected model (see Figure 4) again.

 

Fig 4: Semantically valid Model, because the Final Node has no outgoing control flow but instead has an incoming control flow.

 Also the Activity ‘Insert issue into product backlog’ has an incoming control flow and is therefore reachable.

This time our constraints evaluate to ‘true’:

To conclude, the usage of additional tools like the YAKINDU EA-Bridge and an OCL Interpreter enables further use cases like validation of BPMN Models by a predefined set of OCL constraints.

There are already projects working on such predefined sets of OCL constraints for BPMN models, for example, ‘OPEN-BPMN-OCL’. The next step would then be to implement automatic model validation.

Try it yourself

Do you want to try it out yourself? 

First download the YAKINDU EA-Bridge Trial Eclipse Distribution, which is free to download. Unpack and start it, select a workspace location, and go to ‘Help’ -> ‘Install New Software’. The following dialog should appear. Copy ‘https://download.eclipse.org/modeling/mdt/ocl/updates/releases/latest’ into the field ‘Work with’.

You should now be able to select the ‘OCL’, ‘OCL build’, and ‘OCL tests’ items:

Click ‘Next >’ and finish the installation. Once it is finished, restart Eclipse to complete the installation.

The next thing to do is creating a new 'General Project', this can be done via the ‘File’ Menu:

After creating the project, please download the attached zip file, which contains the BPMN example and an XML file (which defines a slightly adapted version of the BPMN 2.0 MDG Technology). Copy these two files into the newly created project. Finally, change the preferences for the YAKINDU EA-Bridges to look for EA profiles in the same folder (in Eclipse: 'Window' -> 'Preferences' -> 'YAKINDU EA-Bridge' -> 'UML' -> 'Profile Locations').

Once this is done you can start experimenting with the example as shown in the screenshot above.

unsplash-logoMr Cup / Fabien Barral

Have you ever wanted to generate code from your Enterprise Architect UML or SysML models? Have you tried to customize Enterprise Architect’s code template framework? Do not give up the dream of project-specific code generators and read how easily they can be implemented.

The Need for a Code Generator

A good software or system architecture is on a higher abstraction level compared to the implementation. It should be a consistent model that documents decisions and neglects unnecessary, often technical, details. Consider, for instance, the class diagram in Figure 1. It shows a domain model that defines the data structure needed for a shop to allow customers to order articles. The properties of each class are modeled in detail, but other unnecessary aspects like operations to access properties are left out.

If the software architecture/design is made upfront before starting with the implementation, a lot of cumbersome and error-prone work can be avoided by code generation. Commercial out-of-the-box code generators often do not change the degree of abstraction. That’s why they often do not match the needs of the project.

The code template framework of Enterprise Architect can be tailored according to the project-specific needs. But this requires some initial training. And often the expected outcome is hard to achieve as described in Eclipse-based Code Generation for Enterprise Architect Models.

A Simple Project-specific Code Generator

I prefer a general-purpose programming language such as Java or Xtend to implement code generators. In particular Xtend is well suited to implement templates because of its template expressions. They allow one to embed executable code inside the text to be generated. It feels like programming PHP, JSP, or JSX. The code in Listing 1 shows a code generation template written in Xtend. It generates Java classes for the classes declared in the class diagram of Figure 1.

package com.yakindu.ea.examples.orderingsoftware.template

import com.yakindu.bridges.ea.examples.runtime.codegen.EACodegen
import org.eclipse.uml2.uml.Class
import org.eclipse.uml2.uml.NamedElement

class ClassTemplate {
   @EACodegen("Java")
   def String generate(Class element) '''
      package «element.package.javaQualifiedName»;
      
      «val superType = element.generals.findFirst[true]?.name»
      «val extends = '''«IF !superType.isNullOrEmpty» extends «superType»«ENDIF»'''»
      public«IF element.isAbstract» abstract«ENDIF» class «element.name»«extends» {
         
         «FOR attribute : element.ownedAttributes SEPARATOR System.lineSeparator»
            «val type = attribute.type?.javaQualifiedName»
            «IF 1 != attribute.upper»
               «val defaultValue = '''new java.util.LinkedList<«type»>()'''»
               private final java.util.List<«type»> «attribute.name» = «defaultValue»;
            «ELSE»
               private «type» «attribute.name»; 
            «ENDIF»
         «ENDFOR»
         
         «FOR attribute : element.ownedAttributes SEPARATOR System.lineSeparator»
            «val type = attribute.type?.javaQualifiedName»
            «IF 1 != attribute.upper»
               public List<«type»> get«attribute.name.toFirstUpper»() {
                  return «attribute.name»;
               }
            «ELSE»
               public «type» get«attribute.name.toFirstUpper»() {
                  return «attribute.name»;
               }
            «ENDIF»
            «IF 1 == attribute.upper»
               
               «val params = '''«type» «attribute.name»'''»
               public void set«attribute.name.toFirstUpper»(«params») {
                  this.«attribute.name» = «attribute.name»;
               }
            «ENDIF»
         «ENDFOR»
      }
   '''
   
   protected def String getJavaQualifiedName(NamedElement element) {
      element.qualifiedName.replace("::", ".")
   } 
}

The generated Java code shown in Listings 2, 3 and 4 does not look like handwritten, because qualified names are used instead of imports. This will be improved later in Figure 4 by methods collectImports and printImports.

package com.example.orderingsoftware;

public abstract class AbstractIDObject {

   private java.util.UUID id; 

   public java.util.UUID getId() {
      return id;
   }
   
   public void setId(java.util.UUID id) {
      this.id = id;
   }
}

package com.example.orderingsoftware;

public class OrderItem extends AbstractIDObject {

   private java.math.BigInteger amount; 
   
   private com.example.orderingsoftware.Article article; 

   public java.math.BigInteger getAmount() {
      return amount;
   }
   
   public void setAmount(java.math.BigInteger amount) {
      this.amount = amount;
   }
   
   public com.example.orderingsoftware.Article getArticle() {
      return article;
   }
   
   public void setArticle(com.example.orderingsoftware.Article article) {
      this.article = article;
   }
}

package com.example.orderingsoftware;

public class Order extends AbstractIDObject {

   private java.util.Date date; 
   
   private com.example.orderingsoftware.Customer customer; 
   
   private final java.util.List<OrderItem> items = new java.util.LinkedList<OrderItem>(); 

   public java.util.Date getDate() {
      return date;
   }
   
   public void setDate(java.util.Date date) {
      this.date = date;
   }
   
   public com.example.orderingsoftware.Customer getCustomer() {
      return customer;
   }
   
   public void setCustomer(com.example.orderingsoftware.Customer customer) {
      this.customer = customer;
   }
   
   public java.util.List<com.example.orderingsoftware.OrderItem> getItems() {
      return items;
   }
}

If you look carefully at the template in Listing 1, you will realize that it does not know anything about Enterprise Architect. Instead, it handles instances of the UML metamodel which is available in Eclipse thanks to the Eclipse UML 2 project. The missing connection between Enterprise Architect and UML is the YAKINDU EA-Bridge. It is an API that offers UML-compliant read and write access to Enterprise Architect UML and SysML models. The database behind an Enterprise Architect project is automatically transformed into instances of the UML metamodel. This has three major advantages for you as a developer: 

• Your code is compatible with other tools that are based on the UML 2 project such as Papyrus.
• Highly performant read and write access to Enterprise Architect models without the need to reverse engineer the database schema of Enterprise Architect.
• You do not have to learn anything about the API of the YAKINDU EA-Bridge. It is completely hidden for you as a developer, because the YAKINDU EA-Bridge integrates itself into the ecosystem of the Eclipse Modeling Framework (EMF).

The YAKINDU EA-Bridge comes with an optional Eclipse IDE integration which allows one to implement project-specific code generators. Those code generators are often prototypically developed and are executed only within a certain context. Thus, it is crucial that the development effort is less compared to  manual coding. To implement a project-specific code generator, all you have to do is to place the EAP file in an Eclipse project and to annotate methods in the code generation template with @EACodegen. Annotated methods should accept the UML element for which code should be generated as the only parameter and return the generated text. If your Enterprise Architect model is hosted by a remote database such as Microsoft SQL Server, you can use a shortcut file instead of an EAP file.

When the project is built, e.g. automatically or manually via the main menu item ‘Project, Clean…‘, the template is launched for all UML classes declared in all EAP files. Of course, only EAP files stored in the template’s project are considered. The generated code is saved in a file specified by the qualified name of the class. The file extension is specified by the argument of the @EACodegen annotation. The structure of the Eclipse project can be seen in Figure 2.

Please observe that the YAKINDU EA-Bridge is an API. It allows you to process the Enterprise Architect model in any way. Indeed, the original use case were comprehensive code generators such as an Autosar RTE generator based on UML architectures. 

Generating More than one Artefact per Model Element

Let’s make the example more exciting by implementing a product line with two different persistence approaches: One that uses JPA to store data in a relational database and one that uses HBase as a big data store.

I suggest implementing a persistence manager which can be used to load and save instances. Only the product based on JPA should allow one to start and complete transactions. Furthermore, I would like to place JPA specific annotations in the Java classes. Figure 3 shows the methods offered by the persistence manager.

The consequence is now, that the implementation of all six classes is slightly different in both products. The Java code in Listings 5, 6, 7 and 8 shows an excerpt of the code to be implemented.

package com.example.orderingsoftware;

public class Article extends AbstractIDObject {

   private String name; 

   public String getName() {
      return name;
   }
   
   public void setName(String name) {
      this.name = name;
   }
}

package com.example.orderingsoftware;

import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name = "ArticleTable")
public class Article extends AbstractIDObject {

   private String name; 

   public String getName() {
      return name;
   }
   
   public void setName(String name) {
      this.name = name;
   }
}

public class PersistenceManager implements AutoCloseable {

   private final Table articleTable;

   public static final byte[] MODEL_FAMILY = "Model".getBytes();

   public static final TableName ARTICLE_TABLE_NAME = TableName.valueOf("ArticleTable");

   public Article getArticle(UUID id) {
      try {
         if (id != null) {
            Get get = new Get(id.toString().getBytes());
            if (articleTable.exists(get)) {
               Result r = articleTable.get(get);
               Article result = new Article();
               result.setId(id);
               result.setName(Bytes.toString(r.getValue(MODEL_FAMILY, ARTICLE_NAME_QUALIFIER)));
               return result;
            }
         }
         return null;
      } catch (Exception e) {
         throw new RuntimeException(e.getMessage(), e);
      }
   }

   // ...
}

public class PersistenceManager implements AutoCloseable {

   private EntityManager entityManager; 

   public Article getArticle(UUID id) {
      if (id != null) {
         return entityManager.find(Article.class, id);
      } else {
         return null;
      }
   }

   // ...
}

Feasible solutions to realize the product line are: 

• To use inheritance. That would require an interface definition with the public API for each class and to implement it for JPA and for HBase. The consequence would be that the rest of the application must be adjusted to operate only on the interfaces and never on the concrete classes. 
• To copy, paste, and modify the implementation for both products would avoid the need to modify the rest of the application. Maintaining two variants might sound reasonable. But is this still the case with an increasing amount of variants? You should think carefully about the pros and cons of copy and paste.
• To use a code generator which generates the product specific code. The classes realizing code generation templates could be based on a common implementation and each subclass could adjust the product-specific parts. 

I prefer the last solution. The outline in Figure 4 shows the refactored class template of Listing 1. Each introduced method generates a specific member of a Java class. This allows me to override these methods in the product-specific templates. In Listing 9 for instance can be seen, that JPA specific annotations are placed before the class definition.

class JPAClassTemplate extends ClassTemplate {
   @EACodegenFile
   def IFile path(Class element, IFile ^default) {
      val path = "com/example/orderingsoftware/" + ^default.name
      return getTargetFilePath("jpa", path)
   }
   
   @EACodegen("java")
   override generate(Class element) {
      return super.generate(element)
   }
   
   override printClassDeclaration(Class element) '''
      «IF element.isAbstract»
         @MappedSuperclass
      «ELSE»
         @Entity
         @Table(name = "«element.name»Table")
      «ENDIF»
      «super.printClassDeclaration(element)»'''

   // ...
}

The method path(Class, IFile) in the template subclasses annotated with @EACodegenFile is used to define the target location at which the generated code should be saved. It has two parameters. The first one is the UML element for which code should be generated. The second is the default location where the generated code should be stored. The return value of the annotated method is the adjusted location at which the generated code should be stored.

The screenshot in Figure 5 shows all templates. The arrows point to the files that are generated by each of them. In addition to the production code, also the test code is generated.

Conclusion

Modern general-purpose programming languages such as Xtend are well suited to implement complex code generators. The input could be a UML model, possibly modeled in Enterprise Architect. The YAKINDU EA-Bridge transforms the relational database behind an Enterprise Architect model on the fly, and completely hidden, into instances of the UML metamodel. There is no need to learn the proprietary code generation language provided by Enterprise Architect or to reverse engineer the database schema of Enterprise Architect. 

The Eclipse IDE integration of the YAKINDU EA-Bridge allows one to implement project-specific code generators at low costs in a short time. In this way, you can save a lot of cumbersome, error-prone, and mindless implementation work.

If you want to see and run the full example for yourself, try out the YAKINDU EA-Bridge. The presented example is one of the examples shipped with the YAKINDU EA-Bridge.