Frequently Asked Questions

The EA-Bridge is an API for UML-compliant (read and write) access to Enterprise Architect models. We developed this API to integrate Enterprise Architect seamlessly into existing tool chains.

The EA-Bridge offers a trial which is an extended Eclipse IDE. You might get the impression that this application is the EA-Bridge. But that’s not the case. The user interface with all its editors are offered by Eclipse projects. The EA-Bridge is the magic behind the user interface that automatically transforms the Enterprise Architect model into a UML model and vice versa. This allows existing Eclipse projects to access EAP files without being modified. The trial bundle is just a showcase of what can be done.

This depends strongly on what you modeled in Enterprise Architect. Often, a model is a software architecture or a system architecture. System architectures include not only software, but also other domains such as hardware or mechanic. Both architectures have in common, that they are on a higher abstraction level compared to the implementation. We strongly recommend to do the implementation in other, domain specific tools (e.g. an IDE for source code or an ECAD program for schematics) and not in Enterprise Architect. Consequently, there is a need to close the gap between the tools.

Often the generation of implementation artefacts is desired, because it saves a lot of effort and is less error-prone. To be able to generate artefacts requires that the model is syntactically and semantically correct. Thus a preprocessing step is usually to check the model before it is processed. This offers also the opportunity to check aspects of the model automatically which would be typically checked manually in a review.

The Enterprise Architect model might not be the only source of truth. Your architecture might be spread between several tools, e.g.:

• an Autosar tooling to define the static aspects of the architecture such as components, ports, interfaces and the scheduling
• a UML model in Enterprise Architect to define the dynamic aspects of the architecture and the detailed design
• a dedicated tool for modeling dynamic behavior such as itemis CREATE
• a tool for functional safety
• a tool for security such as itemis SECURE

Each tool offers a specific view to some parts of the model, but they all together should define one consistent overall model. Therefore, another typical use case is to implement model transformations to ensure that the model is in sync between all tools. The challenge is always to solve conflicts that occur when the same model element is modified in different tools at the same time. There are different solutions to deal with conflicts, the one you should take depends on your specific process and needs.

There are two ways how you can install and use the EA-Bridge:

1. Download the Trial Distribution which is an Eclipse bundle where the EA-Bridge is pre-installed.
2. Install the EA-Bridge into your own Eclipse installation from an Update Site as explained here.

The trial version of the EA-Bridge offers several examples:

• ‘Example Project’: A sample EAP file including an applied custom UML profile.
• ‘Live Validation Example Project’: A validation example to demonstrate how custom constraints can be checked on your models with the @EAValidation annotation.
• ‘Live Codegen Example Project’: A code generation example with project-specific code generation templates using the @EACodegen annotation.
• ‘Example Plugin Project’: A plug-in example project which can be used as starting point to develop a code generator as an individual Eclipse plugin.
• ‘JUnit Test Plugin Project’: A plug-in project that contains example JUnit tests which explain how to load and save EAP files and how to process them headlessly. It also demonstrates how to register programming language datatypes and UML profiles.

That is maybe easier than you think, assuming you application is compatible to the Eclipse UML format. The EA-Bridge registers the file extension ‘eap’ within Eclipse via EMF and provides a Resource implementation for EAP files. Therefore, maybe you do not have to modify the existing code at all. It is enough to add the EA-Bridge to your Eclipse product and load EAP files instead of UML files.

If you are unfamiliar with EMF, the following snippet shows how to open an EAP file.

// Open EAP file
URI uri = URI.createFileURI("C:/.../Example.eap");
ResourceSet rst = new ResourceSetImpl();
// the line below is only needed if you need write access
rst.getLoadOptions().put(EAResource.OPTION_READONLY, false);
Resource resource = rst.getResource(uri, true);
// Find instances of UML concepts
Model model = (Model) resource.getContents().get(0);
Package architecturePackage = model.getNestedPackage("SoftwareArchitecture");

Please observe that the only difference compared to opening a XMI file is, that the file extension in the URI is EAP instead of UML/XML. The only dependency to the EA-Bridge is line four - which is only needed if you also want to modify the EAP file. By default, EAP files are opened read-only with the EA-Bridge. Write access can also be enabled in general in the preferences (programmatically or via the UI). This avoids the dependency to the EA-Bridge.

The following snippet shows how to save an EAP file.

// Create a new component
architecturePackage.createOwnedType("Component3", UMLPackage.Literals.COMPONENT);
// Save changes
resource.save(Collections.emptyMap());

See also “Where can I find an Example about how to use the EA-Bridge?”.

The trial version of the EA-Bridge has two limitations:

1. It only allows to read models, write access is not possible.
2. It does not load large models with more than 1000 elements.

Other than that, the trial version is feature-complete. So you may test the EA-Bridge with a small representative model which covers all your needed concepts. If you want to evaluate the EA-Bridge for a large model, please purchase a full version or contact our sales team for an evaluation license without size limitation.

The advantage of using the EA-Bridge is that it transforms the tuples in the relational database into instances of UML concepts and vice versa. But this is also a disadvantage, because Enterprise Architect does not help the user to come up with a valid UML model. A common mistake is for instance that UML states or actions are owned by a package. But this cannot be represented in UML. States must be owned by a state machine and actions by an activity. But Enterprise Architect encourages users who are not UML experts to model such nonsense. 

We usually implement additional checks executed in Enterprise Architect to ensure that the model can be processed with the EA-Bridge. Once this is possible, you get an almost complete check of the UML constraints for free thanks to the Eclipse UML 2 project.

The best way to figure out the compliance of your model is to open it with the trial of the EA-Bridge. The tool will report any errors and you can see directly which parts of your model are not completely loaded. And don’t get disappointed or frustrated if several hundreds or even thousands of errors are reported - that is normal because the Enterprise Architect misses plenty of UML constraints. Typically, unrelated packages can be ignored (and will thus not be loaded) because they do not contain model elements that should be processed with the EA-Bridge.

The easiest way to access a remote database with the EA-Bridge is to use Enterprise Architect to create a shortcut file. This is an EAP file which contains only the connection string describing how to access the remote database. If such a file is not available, the EA-Bridge offers alternative ways to specify the remote connection.

The following databases are currently supported:

• JET 3/4 (eap/eapx file extension)
• Microsoft SQL Server
• MySQL (on request)
• Oracle (on request)
• PostgreSQL (on request)
• Firebird (on request, feap file extension)

If you plan to use a different remote database, feel free to contact us. We will find a solution to support that database as well.

You may know that Enterprise Architect uses a relational database to persist the model. An EAP file for instance is powered by the Microsoft Jet database engine. So it is legal to ask what are the advantages of using the EA-Bridge instead of a specific database driver (e.g. JDBC/ODBC).

The answer is simply that you avoid to reverse engineer the database schema of Enterprise Architect. You’re implementation will be based on the Eclipse UML 2 project which offers an EMF based implementation of the UML standard. The EA-Bridge itself offers an EMF specific Resource implementation for EAP files. If you have already an application based on the Eclipse UML 2 project, you do not have to modify it it in order to process EAP files. All you have to is to add the EA-Bridge to your Eclipse product and maybe to adjust the file handling. Please observe that you can use the EA-Bridge also in pure Java applications as long as you are willing to integrate also the dependencies to the Eclipse UML 2 project and EMF.

We would like to visualize the difference between working with a database driver and the EA-Bridge with the following example that shows a typical application with a sender component that publishes content to two connected receiver components.

The following three screenshots show how the content is queried in Enterprise Architect with help of an SQL select query:

Feel free to reverse engineer the foreign keys to re-build the model. Please observe that each table has more columns and that many more tables are needed in realistic examples. Furthermore, nearly each UML concept has its specific persistence handling in Enterprise Architect. So you have to reverse engineer all UML concepts used in your model.

The following screenshots shows as alternative how the model is visualized to the user by the editor offered by the Eclipse UML 2 project. Instead of inspecting tuples in a table, the UML concepts are instantiated. This allows one to navigate along the hierarchy (editor ‘ComponentExample.EAP’’) and to inspect all properties of the selected instance (view ‘Properties’).

The programmatic handling of the instances is really convenient. Each implementation of a UML concept offers methods to read and modify its content and to create new child elements.

Please observe that the EA-Bridge does not only avoid to get the knowledge from the reverse engineering of Enterprise Architect’s database schema. It also avoids to implement it. We spend a lot of effort to optimize the read and write performance of the EA-Bridge to be able to process really large models.

The main ingredient of a code generator are templates that transform model elements into source code. A first step is therefore to iterate over the model and to collect all elements for which source code should be generated.

It is best practice that a template always generates the same content for the same given element. We recommend to use Xtend as programming language because of its powerful template expressions. The next step is then to merge the generated code with existing code. Please observe that existing code might have been modified since the last generation. It is therefore required to parse the source code. Eclipse is well suited for that, because it is an IDE for common programming languages such as Java, C/C++, and Python. Therefore, the parsers are already implemented. If Eclipse itself is also used as IDE, it is guaranteed that the manually written source code can be parsed by a code generator (as long as it does not contain any compiler errors). The strategy to define parts in the modified source code which should be preserved by a re-generation depends on your needs.

Initially, we developed the EA-Bridge for complex code generators that are implemented once and reused in the entire company. An Autosar RTE generator is a good example for that. We usually integrate such generators directly into Enterprise Architect or Eclipse via menu items for convenience reasons.

The alternative are project specific code generators. They are usually prototypically written and maybe used only once. The EA-Bridge also supports this use case. In an Eclipse IDE with an installed EA-Bridge, it is possible to maintain the productive source code and the code generator at the same time. All that needs to be done is to place the EAP file and the code generator templates into the same project. A special builder detects changes on the model or the templates and automatically re-executes the code generation. The templates can be written in Java or Xtend. All that needs to be done is to create a class with @EACodegen and @EACodegenFile annotated methods. The annotation @EAValidation can further be used to implement project-specific model checks. See also “Where can I find an Example about how to use the EA-Bridge?”.

The EA-Bridge covers most of the structural UML concepts, most behavioral concepts are partially covered.

Full Support:

• Packages
• Simple & Structured Classifiers (incl. Classes, Components, Interfaces, Data Types, Ports, Associations, Connectors, Relationships, etc.)
• Use Cases
• Profiles

Partial Support:

• Deployments (Devices, Nodes, etc.)
• Objects (Instance Specifications)
• State Machines
• Activities
• Interactions (Sequence diagrams)

We recommend to open a small representative model which you plan to process in the trial of the EA-Bridge (for larger models, you need an evaluation license which can be requested from our sales team). This allows you to find out if needed UML concepts are missing. If UML concepts are missing, feel free to contact us. We will find a solution to make the missing concepts available. But please understand that the UML defines too many concepts. The EA-Bridge supports up to now only those concepts that are used in customer projects.

Besides UML 2.5, the EA-Bridge supports also SysML 1.3, SysML 1.4/1.5 and the built-in requirements of Enterprise Architect.

If your need another language, like BPMN or ArchiMate, please contact us and we will find a solution.

Yes. There are several ways to use UML profiles in the Enterprise Architect. They can either be embedded individually (via the Resources view), or they can be provided via MDG-Technologies. If the MDG-Technology or only the UML profile is embedded in the Enterprise Architect project, the EA-Bridge is able to derive the UML profile on the fly.

Usually, we deploy MDG-Technologies as part of an add-in, because this ensures that the version of the add-in and the MDG-technology is always compatible. For stability reasons, and because Enterprise Architect’s UML profiles are not 100% compliant to the UML standard, we recommend to define the UML profile manually and to register it in Eclipse using the extension point org.eclipse.uml2.uml.dynamic_package. See also “Where can I find an example about how to use the EA-Bridge?”.

Enterprise Architect adds sometimes additional properties to UML concepts. Examples are properties ‘Complexity’, ‘Phase’, or ‘Status’ of most EA classifiers which do not exist in the UML. The EA-Bridge uses instances of EAnnotation to make this data available. It also offers the class EASpecifics for convenient programmatic access.

Also user defined tagged values that do not belong to a stereotype are available as EAnnotation instances. Please observe, that if a tagged value belongs to a stereotype, it will be accessible as a property of the applied stereotype.

It is possible in Enterprise Architect to define so called Programming Language Datatypes. They usually represent built-in types of a programming language like ‘char’ and ‘unsigned int’ for language C. If custom language datatypes are declared in the Enterprise Architect project, the EA-Bridge automatically creates PrimitiveType instances in UML for them and loads them on the fly.

Otherwise, you can use the extension point com.yakindu.bridges.ea.uml.primitiveTypesLibrary to provide a UML model which declares your specific primitive types. See also “Where can I find an Example about how to use the EA-Bridge?”.

Add-ins are implemented in .NET and allow one to extend the functionality of Enterprise Architect. Enterprise Architect also offers an API to access model elements. But this API is a really slow access to the database tuples with some convenience methods.

We recommend to implement your application based on the EA-Bridge in Java and maybe Xtend. It is easy to deploy the Eclipse product as a console application. This application can be launched from an add-in even without the need to close EAP files. The console of the launched application can be suppressed and launching a minimal Eclipse product is really fast. A user will never realise what's going on behind the scenes and has the impression that everything happens in Enterprise Architect.

Enterprise Architect uses MDG Technologies not only to define UML profiles, but also to deploy everything related to a language. This includes tool boxes, diagram types, quick linker entries, code modules with the programming language datatypes and much more.

In addition, add-ins can be implemented to realize new functionality that is triggered manually by the user via menu items or automatically on events (e.g. creation, deletion or modification of elements/connectors). An add-in offers direct access to the database via SQL (INSERT, UPDATE, DELETE, SELECT) or to the in memory model. 

The code template framework and document reports of Enterprise Architect can be tailored to produce source code and reports according to your needs. You will find out quickly that this infrastructure is not sustainable to implement complex and maintainable transformations. That’s why we implemented the EA-Bridge.

To tailor enterprise architect, you need an MDG technology to cover domain specific concepts, to implement add-ins to increase the productivity of users and the EA-Bridge to implement transformations such as code generators. We have experience in all areas and would like to share it with you in forms of trainings, consulting, or doing!