About

RepoDoc is a powerful document generator for Sparx Systems Enterprise Architect able to produce a variety of document formats using templates written in any text editor. These include HTML, LaTeX, Markdown or AsciiDoc documents, but also CSV, XML or JSON files, GraphViz graphs, SVG diagrams and even source codes in different languages. With RepoDoc you can also generate PDF documents easily using the built in post-processing feature.

Installing and running

Download RepoDoc installer and follow the installation steps on the screen. Please note, that RepoDoc has following requirements for running:

  • Microsoft Windows 7 or later, (32/64 bit),

  • Microsoft .NET Framework 4.5 or later,

  • Enterprise Architect v1305 or later installed,

RepoDoc works with following repository types:

  • MySQL

  • PostgreSQL

  • MS SQL Server

  • Firebird (database repository or local *.feap filed base repositories)

  • Oracle

  • JET (local *.eap file based repositories)

For initial setup and configuration of connection to your repository, please follow the Sparx Systems Help.

Once you have finished the installation you can use RepoDoc either as an Enterprise Architect add-in or as a standalone application.

Add-in mode

Start the add-in from the ribbon by navigating to the ExtensionsRepoDocControl panel option

or

using the project browser by right-clicking on a package in the package browser and selecting ExtensionsRepoDocControl panel option.

The Add-in mode is not supported for EALite edition of Enterprise Architect.

Standalone mode

Standalone application can be started from the command line. When you have your Enterprise Architect installed and configured, you can run RepoDoc from Windows command line with the following command:

C:\Program Files (x86)\Archimetes\RepoDoc\RepoDoc.exe [ConnectionString]

Start the application with the connection string (or the full path to your .eap or .feap file) to connect to your repository.

Generating documents

RepoDoc follows the same principles as the default document generator included in the Enterprise Architect and as such needs two kinds of inputs to generate a document:

  1. Starting point in the repository determining the part of your model you wish to document i.e. a root package.

  2. Document template that tells RepoDoc what to take out from the repository and where to put it into a document.

RepoDoc comes with several pre-installed templates. These templates are stored in the C:\Program Files (x86)\Archimetes\RepoDoc\DocumentTemplates\Input directory or you can download the templates from our website. The document templates have rdt file extension.

To demonstrate the document generation we’ll use the standard EAExample.eap model that is shipped with every Enterprise Architect and is typically stored in the c:\Program Files (x86)\Sparx Systems\EA directory. To generate a document, based on this model, please follow these steps:

  1. Open the EAExample.eap model in Enterprise Architect and select the UML Modeling package in the Project browser.

  2. Right-click on the selected package and choose ExtensionsRepoDocControl Panel. RepoDoc starts and presents itself with the Document generator form.

  3. Select the About dialog and click the Download license key button if your are using RepoDoc for the first time. Then switch back to the Document generator.

  4. Click the …​ button in the first row and select the UML-model-documentation.html.rdt template from the dialog.

  5. Click the Generate document button. RepoDoc generates a HTML documentation for the UML Modeling package and outputs information similar to the one pictured below.

Document generator

The generated document is stored in the Documents directory (the path may differ based on your username) and should look like the one pictured below.

UML model documentation

Additional functionality of the document generator includes:

  • Verify template button starts template verification without generating a document. In this case the connection to the repository is not necessary.

  • Edit template button opens the selected template in a text editor defined by the user (please see the Application settings for further details).

  • Generator profile button >> navigates to the generator profile editor which allows you to modify the way the repository is processed or to set a document post-processing command.

  • Package browser button >> navigates to the Package browser which allows you to choose a different package to document without closing the RepoDoc. The name of the root package is displayed in the textbox together with the package GUID.

  • View document button opens the generated document in the associated application.

Editing templates

RepoDoc templates are just plain text files and you can use any text editor to edit them. To make the authoring and reading of the templates easier, syntax highlighting and keyword autocompletion for RepoDoc templates is currently implemented for Notepad editor. Follow these instructions to install syntax highlighting for RepoDoc templates in Notepad:

  • start Notepad++,

  • select LanguageDefine Your LanguageImport and import the file RepoDocTemplateUDL.xml. You’ll find the file in c:\Program Files (x86)\Archimetes\RepoDoc\NppExtensions directory,

  • restart Notepad++ and after it a new Language "RepoDocTemplate" should appear inside the Language menu,

  • open any RepoDoc template, it should colour the syntax as on the screenshot above.

Follow these instructions to install keyword autocompletion for RepoDoc templates in Notepad++:

  • stop Notepad++ if it’s running,

  • copy RepoDocTemplate.xml c:\Program Files (x86)\Archimetes\RepoDoc\NppExtensions into <Notepad++ root folder>\plugins\API\ directory,

  • start Notepad++ and open any RepoDoc template. The output should look like the one pictured below.

Syntax in Notepad++

Change the path to your favorite editor in the Application settings. Your editor will be used to open the templates when clicking Edit template button in the Document generator form.

Package browser

The package browser lets you choose a root package from the model. Please note that the browser is visible only when you invoked RepoDoc with an opened project in the Enterprise Architect or with a ConnectionString argument (in case you are using it in standalone mode).

Package browser

Select a package you wish to start with, right click on it and choose Set as new root package.

License key

RepoDoc needs a valid license key for document generation. The About dialog shows product and license key information.

About dialog

Time limited license key is available for free and can be simply obtained by clicking the Download license key button. Please contact info@archimetes.com for further information.

Creating templates

RepoDoc comes with several pre-installed document templates. You can modify these templates or create new templates easily in any text editor. The RepoDoc template is just a text file with following instructions:

  1. which repository items to look for (packages, elements, diagrams etc.)

  2. what information about these items (name, notes, author, stereotype) to put into the document

For this purpose, the template is divided into one or more sections (which repository items to look for) whereby each section may contain (among some text) one or more variables (what information about these items to put into the document).

The RepoDoc makes use of the Enterprise Architect class model and being familiar with it is an advantage when writing templates.

A small template example follows:

This is our first RepoDoc template example, containing one Package section and one Element section.
[Package]
Package name is "$Package.Name"
[Element $Element.Type=="Class"]
Element name is "$Element.Name"
[/Element]
[/Package]

This template tells RepoDoc to do following:

  1. Put the name of each package you encounter in the repository into the document.

  2. Put the name of each element (that is type of Class) in each encountered package into the document.

Sections are written with an opening and a closing tag, with the content in between. Variables are marked with the $ (dollar) sign.

When iterating repository, RepoDoc begins always with the root package you’ve selected and then continues with all of its child packages. Long story short, taking the EAExample.eap model (that’s shipped with Enterprise Architect) and selecting XML Schema as the root package

repodocuserguide_eaexample-projectbrowser-example1

we get following document:

This is our first RepoDoc generated document based on our first template example.
Package name is "XML Schema"
Package name is "Schema"
Element name is "Account"
Element name is "LineItem"
Element name is "Order"
Element name is "ShoppingBasket"
Element name is "StockItem"
Element name is "Transaction"
Package name is "Schema_A"
Element name is "fName"
Element name is "lName"
Package name is "Schema_B"
Element name is "mName"
Element name is "Person"

The document contains the names of the packages and elements under the XML Schema package (including the root package itself). As you can see, the content of Package section has been evaluated (put into the document) for each package and the same applies to the Element section. This evaluation logic is the same for (almost) all sections RepoDoc works with. The content of the section is evaluated as many times, as there are corresponding items in the repository (in our example these items are the packages and elements). You can see the results of the evaluation procedure in the document below. It contains the packages (as in the Model) and the elements in each encountered package are also named. The OrderStatus element, being an Enumeration, is not in the document as we requested only Class type elements via a filter attribute (don’t worry, we’ll get to filter attributes later).

Please observe that the lines containing section tags have not been put into the document. RepoDoc automatically removes lines consisting purely of section tags and whitespace characters. Following templates:

[Package]
Package name is "$Package.Name"
                [Element $Element.Type=="Class"]
Element name is "$Element.Name"
   [/Element]
  [/Package]
[Package]Package name is "$Package.Name"
[Element $Element.Type=="Class"]
Element name is "$Element.Name"
[/Element][/Package]

produce therefore the same output as our first template example.

By now, you have learned that using sections, you can control, what parts of the repository will be documented because section content is evaluated and put into the document for each corresponding item (package, element, diagram etc.) found in the repository.

Summarizing the above, you can document attribute names for each element. Looking at the sample EAExample.eap model

repodocuserguide_eaexample-projectbrowser-example2

you can see that many classes have some attributes defined. You can document those by adding an Attribute section to the template:

This is our second RepoDoc template example, containing one Package section, one Element section and one Attribute section.
[Package]
Package name is "$Package.Name"
[Element $Element.Type=="Class"]
Element name is "$Element.Name"
[Attribute]
Attribute name is "$Attribute.Name"
[/Attribute]
[/Element]
[/Package]

Using this template you get a slightly larger document.

This is our second RepoDoc generated document based on our second template example.
Package name is "XML Schema"
Package name is "Schema"
Element name is "Account"
Attribute name is "billingaddress"
Attribute name is "closed"
Attribute name is "deliveryaddress"
Attribute name is "emailaddress"
Attribute name is "name"
Element name is "LineItem"
Attribute name is "quantity"
Element name is "Order"
Attribute name is "date"
Attribute name is "deliveryinstructions"
Attribute name is "ordernumber"
Element name is "ShoppingBasket"
Attribute name is "shoppingbasketnumber"
Element name is "StockItem"
Attribute name is "author"
Attribute name is "catalognumber"
Attribute name is "costprice"
Attribute name is "listprice"
Attribute name is "title"
Element name is "Transaction"
Attribute name is "date"
Attribute name is "ordernumber"
Package name is "Schema_A"
Element name is "fName"
Element name is "lName"
Package name is "Schema_B"
Element name is "mName"
Element name is "Person"
Attribute name is "firstName"
Attribute name is "lastName"

As of now we have identified all three basic parts of a template that are summarized below.

Sections

Sections are part of the template written with an opening tag and a closing tag, with the content in between. A section tag is composed of the name of the section, surrounded by square brackets. A closing tag also has a slash after the opening bracket, to distinguish it from the opening tag. Each section may contain either ordinary text, variables or one or more subsections or combination of the former (of course there are some rules but we’ll get to them later). There are some special purpose sections, but typically the section names correspond to the classes in the Enterprise Architect class model. Following the class model and relationships defined for the classes, it’s clear that there must be some similar hierarchy of sections and rules exist on how the sections may be nested within each other. For example a package may contain one or more elements or diagrams, an element may have attributes or operations (which may in turn have parameters) and so on. Since there are many classes defined by the Enterprise Architect so there are many sections you may use. Have a look at Template syntax reference for all currently supported sections.

Sections with a corresponding class are evaluated for each corresponding item found in the repository. There are however some specific points to be addressed as how these items are found and what they can represent.

Packages

Package section is evaluated for each package found in the repository starting with the root package defined by the user. If a package has child packages, they are evaluated before evaluating following package on the same level. User may choose to exclude some packages from the final document by specifying one or more filter attributes for the Package section.

Elements

Element section is evaluated for each element contained in or associated with the package. At first, this is straightforward, but there’s more information in the model as the Project browser shows. Technically speaking, the element section contains:

  1. The associated element object (or so called package element) from the Package class.

  2. Element collection defined in the Package class.

Modifying our first example, we will document all elements (please note the filter attribute has been removed) with their types:

This is 3rd RepoDoc template example, containing one Package section and one Element section without the filter attribute.
[Package]
Package name is "$Package.Name"
[Element]
Element name is "$Element.Name" and element type is "$Element.Type"
[/Element]
[/Package]

we get following document:

Package name is "XML Schema"
Element name is "XML Schema" and element type is "Package"
Package name is "Schema"
Element name is "Schema" and element type is "Package"
Element name is "" and element type is "Note"
Element name is "Account" and element type is "Class"
Element name is "LineItem" and element type is "Class"
Element name is "Order" and element type is "Class"
Element name is "OrderStatus" and element type is "Enumeration"
Element name is "ShoppingBasket" and element type is "Class"
Element name is "StockItem" and element type is "Class"
Element name is "Transaction" and element type is "Class"
Package name is "Schema_A"
Element name is "Schema_A" and element type is "Package"
Element name is "fName" and element type is "Class"
Element name is "lName" and element type is "Class"
Package name is "Schema_B"
Element name is "Schema_B" and element type is "Package"
Element name is "" and element type is "Note"
Element name is "mName" and element type is "Class"
Element name is "Person" and element type is "Class"

The result is now slightly different and shows not only how the sections work, but also how the information about elements within Enterprise Architect is stored:

  1. The document contains the associated element for each package. It has the same name as the package itself, but has a distinct type (see the Type property of the Element class). The package element is always documented before other elements contained in the package on the same level.

  2. The document contains elements with empty name of type "Note". This is because Notes in the diagrams are internally represented as nameless elements and Enterprise Architect does not show them directly in the Project browser.

Simply use filter attributes to filter out the package element or other elements you do not need, like those representing Notes in the diagrams.

Elements containing elements (child elements)

Some elements may have child elements representing sub components, ports or interfaces. There is no special section for child elements in RepoDoc instead the Element section evaluates not only the element contained in the package but also all of its child elements before evaluating next element (in the package). Looking at the model below.

repodocuserguide_eaexample-projectbrowser-example4

You can see that three elements in the Components package have one child element (in this case it’s a Port). Starting from the highlighted Components package and using the third template you get following document:

Package name is "Components"
Element name is "Components" and element type is "Package"
Element name is "Charging Unit - ADP2291" and element type is "Class"
Element name is "charger" and element type is "Port"
Element name is "Codec with Amplifier - TLV320AIC3107" and element type is "Class"
Element name is "Li-Ion Battery Monitoring System - AD7230" and element type is "Class"
Element name is "chargeMonitor" and element type is "Port"
Element name is "Memory - MT42L32M64D2KH-25" and element type is "Class"
Element name is "Panasonic Li-Ion CGR18650AF" and element type is "Class"
Element name is "chargeIndicator" and element type is "Port"
Element name is "Processor - TMS320VC5507" and element type is "Class"
Element name is "RS232" and element type is "Class"
Element name is "Touch-screen" and element type is "Class"
Element name is "USB - PL-2528" and element type is "Class"

You can see that the charger child element has been evaluated before Codec with Amplifier element, because charger is child element of Charging Unit element. The same applies for child elements chargeMonitor and chargeIndicator.

Diagrams

Diagrams can be documented using the Diagram section. Diagrams may be contained in a package or in an element and the same applies to the Diagram section.

Diagram images

Diagram images may be obtained in two ways:

  • Using the $Diagram.ImagePng variable which evaluates to a base64 encoded diagram image in PNG format.

  • Using an empty Diagram section. Normally empty sections (containing only opening and closing tag) do nothing, but for Diagram section, this is different. An empty Diagram section ([Diagram][/Diagram]) causes the image (in PNG format) to be written directly to a file. The file is stored in the same directory as the document and its name follows this naming convention: Diagram_<DiagramID>.png.

Diagram objects

Each diagram typically has one or more objects. These diagram objects may be documented using the DiagramObject section. The DiagramObject section is evaluated for each diagram object in the diagram. The variables defined in the DiagramObject section (and its subsections) are (almost) identical to the variables defined for the Element section. This is because each diagram object is in fact just an element modelled somewhere in the repository. Additionally the object contains position information. Example below documents diagram object names in all diagrams and in all packages (starting from the root package).

This is RepoDoc template example containing one Package section and one Diagram section.
[Package]Package name is "$Package.Name"
[Diagram][DiagramObject]DiagramObject (i.e. Element) name is "$DiagramObject.Name" and DiagramObject type is "$DiagramObject.Type"
[/DiagramObject][/Diagram][/Package]

Other repository items

Other repository items like attributes, operations, operation parameters etc. have their corresponding section and variables. For full reference see Template syntax reference for all possible sections in RepoDoc and Enterprise Architect Object Model.

Variables

Variables identify properties of repository items that will be documented (i.e. became part of the document). They are marked with the $ (dollar) sign and correspond (in most of the cases) to the properties (sometimes called Attributes in the official Enterprise Architect documentation) of the repository classes that the user wishes to document. Their name is composed of the Class name and Property name delimited with . (dot) i.e. <ClassName>.<Property>. Since each section corresponds to a specific class it’s only logical that the variable is defined and its value is known only within its section or within the subsection(s) of the section for which it is defined. Long story short, have a look at following examples.

This is a valid template.
[Package]List of elements for package: $Package.Name
[Element]$Element.Name
[/Element][/Package]
This is also a valid template.
[Package]List of elements:
[Element]Element $Element.Name is within package $Package.Name
[/Element][/Package]
This template is not valid. Variable $Element.Name is misplaced because $Element.Name is only defined within the Element sections (or its subsection(s)).
[Package]List of elements for package: $Package.Name
[Element][/Element]
$Element.Name
[/Package]

The properties for each class (or variables for section if you like) may be found in the Enterprise Architect documentation e.g. Element class properties. Have a look at Template syntax reference for a quick overview of all possible variables.

Text

Text is literally everything being not a variable or a section tag.

Advanced topics

Notes format

Notes for various items may contain format information, like font or colour information. RepoDoc provides two variables when dealing with notes and formatting.

  • $<ClassName>.Notes returns notes in plain text (without formatting). The colour or font format information is lost, however the lists are preserved using indents and newlines.

  • $<ClassName>.NotesHtml returns notes in html format with all the formatting expressed using html tags.

Filter attributes

Filter attributes are means to exclude some items (packages, elements, diagrams, etc.) from the final document. By default, RepoDoc puts content of each section that has a corresponding item in the repository into the document. In some cases, it may be useful to exclude some items from the repository and not document them. These may include items with some special stereotype(s) or name(s). The names of filter attributes have the same format as variables and they are specified in the section opening tag, together with a comparison operator and a value. The same restrictions apply for attributes as for variables regarding their placement.

This RepoDoc template puts all elements with type Class into the document.
[Package][Element $Element.Type=="Class"]$Element.Name
[/Element][/Package]
This RepoDoc template puts only packages with at least one element into the document.
[Package $Package.ElementCount!="0"]$Package.Name
[/Package]
This RepoDoc template puts only packages with at least one element and one diagram into the document.
[Package $Package.ElementCount!="0" $Package.DiagramCount!="0"]$Package.Name
[/Package]

If you specify multiple filter attributes they must be separated by a single space. Multiple attributes are always evaluated using AND logical operators i.e. all must be true, otherwise the item will be filtered out.

RepoDoc supports currently four comparison operators:

  • == acts like a string comparison operator and evaluates to "true", if the specified attribute is equal to the value specified by the user in between quotes,

  • != acts like a negated string comparison,

  • =~ acts like a regex matcher and evaluates to "true" if the specified attribute matches the regular expression specified by the user in between quotes,

  • !~ acts like a negated regex matcher.

Using reserved characters

RepoDoc uses some reserved characters that have special meaning during template processing and document generation, namely:

  • characters [ and ] and / mark the opening and closing section tags,

  • character $ (dollar) is used as a variable marker,

  • character " (double quotes) is used to denote the filter attribute value.

There are some rules to follow if you want to use these characters in your templates and suppress their original meaning.

In ordinary text:

  • characters [, ], and $ must not stand alone and may be escaped as [[, ]] and $$.

  • character " may stand alone and does not need to be escaped.

In filter attribute values:

  • character $ must not stand alone and may be escaped as $$.

  • characters [, ] may stand alone and do not need to be escaped.

  • character " must not be used.

Convenience variables

RepoDoc follows Enterprise Architect class model and therefore many variables are easy to understand for someone being familiar with Enterprise Architect. Beside these variables RepoDoc provides some "convenience" variables, that are not directly defined in the class model. Some of these are described below:

  • $<ClassName>.<AnotherClassName>Count variables return number of items in child collections. Typically the content of these collections is documented using sections e.g. elements in a package are documented using the Element section. Nevertheless, in some cases it may be useful to document the number of items in those collections, e.g. to document the number of attributes for each class or number of methods in a component. For this purpose the item count in collections (see the class model for full extent) are accessible using $<ClassName>.<AnotherClassName>Count variables i.e. $Package.ElementCount, $Element.OperationCount etc.

  • $<ClassName>.IndexOf returns the index of the item in parent’s collection of items of the same type. For example, if the item is an Element, then IndexOf returns either the index of the element in the Elements collection from the parent package or the the index from the collection of child elements of the parent element if the currently evaluated element is a sub/embedded element.

  • $<ClassName>.CountOf returns the number of items in parent’s collection of items of the same type. In most of the cases, this value is directly related to the structure of the repository as seen in the Project browser. For example, if the item is an Element, then CountOf returns either the number of elements in the parent package (including the package element) or the number of child elements of the parent element if the currently evaluated element is a sub/embedded element.

  • $DG.PackagePath global variable that returns a backslash delimited list of package names starting with the root package and ending with the currently evaluated package.

  • $DG.PackageDepth global variable that returns the depth for the currently evaluated package in the tree of packages. The root package has always a depth equal to zero.

Multiple repository iterations

RepoDoc allows you to iterate all items in the repository more than once using a single template. For example, you may wish first to output a list of packages in the repository and then a list of elements for each package. The template syntax allows you to put a section more than once into the template as long as the section relationships are obeyed. The following template makes the described above possible:

List of packages:
[Package]
Package name is "$Package.Name"
[/Package]

List of elements for each package:
[Package]
List of elements for package "$Package.Name":
[Element]
$Element.Name
[/Element]
[/Package]

Using sections in the manner described above you’ll be able to document different parts of repository with a single template. Following template uses filter attributes to output the requirements and then the use cases in two different packages into a single document.

List of requirements:
[Package $Package.Name=="Requirements"]
Requirement name is "$Package.Name"
... Put your element or diagram section here ...
[/Package]

List of use cases:
[Package $Package.Name=="Use cases"]
Use case name is "$Package.Name"
... Put your element or diagram section here ...
[/Package]

Custom queries

While the sections corresponding to Enterprise Architect classes and their variables should provide all information necessary for the document, there may be cases when information beyond these sections is required. For such cases RepoDoc offers the RDQuery section which offers a Statement attribute for the user’s custom SQL query. The following example demonstrates the usage of custom queries.

[RDQuery $RDQuery.Statement="SELECT package_id, name FROM t_package"]
[RDQueryRow]
PackageID=$RDQueryRow.Column1
Name=$RDQueryRow.Column2
[/RDQueryRow]
[/RDQuery]

The query results are accessible in the RDQueryRow subsection using the Column variables. This subsection is evaluated for each row returned by the query. The example demonstrates just the concept, in this case it would be easier to access the information using simply the Package section.

Use the sections corresponding to repository items like Package, Element or Diagram whenever possible. Use RDQuery only in cases when you need some extra information not covered by RepoDoc’s sections.

Generator profiles

Generator profile changes the way the repository is processed and/or contains a document post-processing command. It solves easily problems that arise when some repository items contain content that is problematic from the output format point of view. For example a package with name <MyPackage> breaks formatting when your template is intended for generating a HTML document. Clearly the characters < and > in the name need to be replaced (in other words escaped) with correct HTML entities &lt; and &gt;. This can be done automatically during document generation by using dedicated document generator profile with defined escape sequences. The profile editor lets you choose and edit a document generator profiles.

Profile Editor

RepoDoc comes with pre-installed profiles, but you are free to create new profiles to meet your needs. You’ll find sample profiles in the installation directory C:\Program Files (x86)\Archimetes\RepoDoc\GeneratorProfiles. The generator profiles have rdg file extension.

Escape sequences

Each profile may contain a list of characters and a corresponding escape sequence for each character. During document generation RepoDoc uses this list to escape the characters in Name, Alias and Notes variables.

Enter 0x09, 0x0a or 0x0d in character column to define escape sequences for the tab, line feed and carriage return characters.

Post-processing

Post-processing command in the profile allows you to define a command and its arguments that will be started upon successful document generation. This may be any command like archivation, transformation into a different format or simply an upload of the document to your company document store.

Use the global variables like $DG.TemplateFileName or $DG.DocumentFileName to simplify your post-processing commands.

Template syntax reference

Global variables

Global variables may be used at any place in the template regardless of the section.

Table 1. Table of global variables
Variable name Variable description

$DG.DocumentDirPath

Document file directory path. If the full document path is C:\MyDir\MyDocument.html then the variable evaluates to C:\MyDir).

$DG.DocumentFileName

Document file name. If the full document path is C:\MyDir\MyDocument.html then the variable evaluates to MyDocument.html).

$DG.DocumentFileNameWE

Document file name without extension. If the full document path is C:\MyDir\MyDocument.html then the variable evaluates to MyDocument).

$DG.DocumentFilePath

Document file path e.g. C:\MyDir\MyDocument.html.

$DG.PackageDepth

Depth of the currently evaluated package related to the root package. The root package has always depth equal to 0, its child package has depth equal to 1 and so on.

$DG.PackageGUIDPath

Backslash delimited list of package GUIDs starting with the root package and ending with the currently evaluated package.

$DG.PackagePath

Backslash delimited list of package names starting with the root package and ending with the currently evaluated package.

$DG.RootPackageGUID

GUID of the root package.

$DG.RootPackageName

Name of the root package.

$DG.TemplateDirPath

Template file directory path. If the full template path is C:\MyDir\MyTemplate.html.rdt then the variable evaluates to C:\MyDir).

$DG.TemplateFileName

Template file name. If the full template path is C:\MyDir\MyTemplate.html.rdt then the variable evaluates to MyTemplate.html.rdt).

$DG.TemplateFileNameWE

Template file name without extension. If the full template path is C:\MyDir\MyTemplate.html.rdt then the variable evaluates to MyTemplate.html).

$DG.TemplateFilePath

Template file path e.g. C:\MyDir\MyTemplate.rdt.

Sections

Most of the sections are named after the corresponding classes that exist in the Enterprise Architect class model. Notable exceptions are the RD prefixed sections, that do not have a corresponding class. Variables represent the properties of repository items that can be documented and are marked with the $ (dollar) sign. Almost all variables correspond to the properties defined in the Enterprise Architect class model. For these, the descriptions are taken from the official documentation for Enterprise Architect and are provided here for convenience.

Section relationships follow the Enterprise Architect class model i.e. the Package section may contain an Element or a Diagram section and so on. All possible parent-child relationships are pictured below whereby the dark highlighted sections may be used as top level sections.