To specify dependencies between classes or to external libraries, add the existing classes to a class diagram and import external libraries into your model first.

You can also use packages with Usage dependencies.

  • Whenever you model a Usage from a Package to a Class, it means that every Class in the package has a Usage to this Class.
  • When you model a Usage to a Package, it means that every Class in the Package is included.

You can now specify dependencies, by using either Dependency or Usage connectors between these elements. Code generation will add the appropriate include directives to the generated classes.

Version 2.1

By applying the stereotype global to an Usage connector the inlcude directive will be generated with brackets instead of quotes.


#inlcude <test.h> // with global stereotype

#inlcude "test.h" // without global stereotype

Include storage/generation

(available since 3.2)

You can influence to where the include shall be generated by changing the Generate includes in .c file setting (available since 2.0) or by using the IncludeStorage Stereotype and the Storage Tagged Value (available since 3.2).

The new IncludeStorage feature can be used on Packages, Class and/or Usage links.

Child or nested elements will inherit the Storage set from its parent but can be overwritten anytime. The IncludeStorage/Storage Tagged Value can also be directly used on a Usage links.

The current implementation will use the following generation strategy.

  1. By default all includes will be generated into the declaration file (.h)
  2. Then the Generate includes in .c file setting will be checked (if set)
  3. Then the IncludeStorage/Storage Tagged Value value will be checked
    and inherited as set in:
    1. Package
    2. Class
    3. Usage link

Order of dependencies/includes

By default, the dependencies are ordered as they are read from your Model. Usually the order is by date of creation, so the first dependency you model will also be the first dependency (#include line) in the generated source code.

To alter this behavior, you can name your dependencies. They will be sorted by their name alphanumerically from lowest to highest. In case of two dependencies with the same name, the internal ordering of your model is used:

You can also use the Order usings feature implemented in the diagram menu to help you see all the Usages linked to the current element and how they are ordered.


You can also use Realization dependencies between a class and an interface to implement the Interface in a class:

In this example, the class Mouse realizes the interface MouseHandler. In this case, the following files will be generated by Embedded Engineer:

Mouse.cContains the implementation of Mouse class.
Mouse.hContains the function declarations for the Mouse class, except for the HandleMouse function
MouseHandler.hContains the function declaration for the HandleMouse function

Because of the realization relation from Mouse to MouseHandler, the declaration of the realized function is used from the interface.

This also means that the name of the HandleMouse function will not be altered when generating code for the Mouse class. See Operations - Naming for more information.

Realization Example

Enterprise Architect


To create a realization and implement the functions of an existing Interface use the Realization link.

After this you will get the Overrides & Implementations dialog where you can select the operation for implementation.

This will result in a new operation with two Implemetation Tagged Values which link the Operation inside the Class with the Interface.

These Implementation Tagged Values are needed to flag the Operation so that it will keep its name/signature during code geneartion.

To create a realization and implement the functions of an existing Interface use the Realization link.

After this you can "reuse/copy" the needed function via dragging/dropping it with the Ctrl key pressed, into the Implementation Class.

Finally you will need to set the "Redefined Operation" of the Implementation Operation to refer to the original Interface Operation

See also

Operations (Naming)

  • No labels