LDI#

The Lattix Data Import module allows you to create Lattix projects from an XML file in LDI format. The LDI file format is easy to understand and powerful. It is described in detail in this document. LDI files have either a .ldi or .ldi.xml (preferred) extension.

The LDI facility allows you to:

Integrate your own parsers for proprietary languages and systems into Lattix.
Create your own mapping which map module boundaries. For instance, you can establish mapping of code to database, or from one language to another.
Bring in additional data such as the mapping of tests and requirements to code into Lattix.
Analyze any system or project management data within Lattix.

Lattix provides a number of additional utilities that generate LDI files. These utilities are documented in the Additional Tools Manual.

LDI File Format#

An annotated DTD file for the LDI file format can be downloaded from here.

Here is an example LDI file that demonstrates the basic features of an LDI file:

<?xml version="1.0" ?>
<ldi>
    <element name="a">
        <uses provider="b"/>
    </element>
<element name="b"/>
</ldi>

LDM creates a 2 element DSM from this file, with “b” providing a dependency of strength 1 to “a”:

Attributes of the <ldi> tag#

By default, LDI separates levels of the namespace using ‘.’. For example, consider the name com.lattix.ldi.Module. This name has an outermost namespace of com, which contains an inner namespace lattix, which contains an inner namespace ldi, which contains an element Module.

However, if your namespace maps files, for example, ‘.’ is not the correct delimiter. Using ‘.’ as a delimiter for /user/include/stdio.h creates an element “h” whose namespace is “user.include.stdio”.

Use the delimiter attribute on the tag to configure the namespace delimiter. For example:

<ldi delimiter="/">
  <element name="/user/include/stdio.h" type="include file" />
</ldi>

This construct creates an element stdio.h in the namespace user.include.

Element Tag: <element>#

It is used to specify an element. The LDI contains elements and their inter-relationships with other elements.

Attributes of the <element> tag#

name: Name of element. This attribute is required. The name can specify a namespace using delimiters. The “.” is the default delimiter.

namespace: Optional attribute that specifies the namespace of the element.

type: Optional attribute that specifies the type of the element. Type can be used to filter atoms and dependencies in LDM. Type can also be the name of an <elementtype> node.

sourcefile: Indicates the source file associated with this element. This string is used in the “View Source” functionality, which is accessible in the context (right mouse) menu that appears when you select elements in the DSM.

codesize: If the element type supports codesize (see below), this contributes to the Lines of Code metric.

The following example <element> tags are equivalent:

<element name="a.b" type="mytype" />
<element name="a.b" namespace="a" type="mytype" />
<element name="b" namespace="a" type="mytype" />

<element> tags can be nested:

<element name="a" type="mytype">
  <element name="b" type="nested"/>
</element>

Creates a simple DSM with two elements: “a” and “a.b”. Element names can also be file names, with “" delimiters:

<element name="c:\tmp\foo.bar" type="file">

Element Type Tag: <elementtype> (optional)#

The <elementtype> tag is used to describe a type used in the LDI file.

Attributes of the <elementtype> tag#

type: Name of type.

display: Name of the type as it will be displayed in LDM. If it is not specified, value of the type attribute is displayed in LDM.

image: Name of the image file to display in LDM for elements of this type. image is either the name of a file or a well formed URL. The indicated image file must exist at the specified location when the LDM project is loaded in order for it to be displayed in LDM.

member: Indicates whether the element is of type member or not. It takes the value of “true” or “false”. If this attribute is not specified, it is assumed that the element is not of type member.

codesize: Indicates that this type supports the codesize or Lines of Code metric. It takes the value of “true” or “false”. If not specified, elements of this type do not support codesize.

For example, this LDI file

<?xml version="1.0" ?>
<ldi>
    <elementtype type="mytype" display="My Type" image="class.gif"/>
    <element name="aClass" type="mytype">
        <uses provider="b"/>
    </element>
    <element name="b"/>
</ldi>

Produces this LDM:

Uses Tag: <uses> (Nested within <element>)#

The <uses> tag creates dependencies between elements.

Attributes of <uses>#

provider: Fully qualified name of the element used by this element.

kind: Kind of the dependency. Kind is used in LDM by the user to filter dependencies.

strength: Indicates the strength of the dependency. If not specified, the strength of the dependency is 1.

create: Shorthand used to create the provider. The value of create is equivalent to the value specified using the type attribute.

These are equivalent:

<element name="a" type="mytype">
    <uses provider="b" create="btype" kind="My Dependency Kind"/>
</element>

<element name="a" type="mytype">
    <uses provider="b" kind="My Dependency Kind"/>
</element>
<element name="b" type="btype"/>

Property Tag: <property> (Nested within <element>)#

The <property> tag attaches properties to elements.

These properties are visible in LDM when a single element is selected:

<element name="a">
    <property name="myproperty">My property value</property>
</element>

Produces:

Dependency Property Tag: <property> (Nested within <uses>)#

You can specify properties for dependencies in DSM.

These properties are visible when a dependency cell in DSM is selected:

<uses provider="SystemB.method1" kind="Method Invocation" strength="3">
    <property name="linenumber">15</property>
</uses>

The special property “#tag” can be used to set a tag on the partition containing the atom for with the #tag property.

The following example tags the element System1 with the tag FrontEnd:

<element name="System1">
    <property name="#tag">FrontEnd</property>
</element>

The following example tags the element System2 with the tags BackEnd and Critical:

<element name="System2">
    <property name="#tag">BackEnd || Critical</property>
</element>

The special property “#description” can be used to set the description on a partition containing the atom with the #description property. For example:

<?xml version="1.0" ?>
<ldi>
    <elementtype type="mytype" display="My Type" image="class.gif"/>
    <element name="aClass" type="mytype">
        <uses provider="b"/>
        <property name="#description">This is aClass.  Should have a nice class icon.</property>
    </element>
    <element name="b"/>
</ldi>

Produces this DSM:

External Names and Undefined References#

Use external names to generate dependencies between elements using logical or “external” names. To do this:

Add an “externalname” <property> to the target element

Create a <uses> on the source <element>

Set the unresolved attribute to true
Set the provider attribute to the external name of the target

For example, loading these two LDI files into Architect:

--------------------
a.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ldi delimiter="." ordering="original">
  <element name="A">
    <uses unresolved="true" provider="global_b" strength="1"/>
  </element>
</ldi>

--------------------
b.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ldi delimiter="." ordering="original">
  <element name="B">
    <property name="externalname">global_b</property>
  </element>
</ldi>

… yields this DSM:

Namespace Delimiters#

By default, LDI separates levels of the namespace using ‘.’. For example, consider the name com.lattix.ldi.Module. This name has a outermost namespace of com, which contains an inner namespace lattix, which contains an inner namespace ldi, which contains an element Module.

Use the delimiter attribute on the tag to configure the namespace delimiter. For example:

<ldi delimiter="/">
  <element name="/user/include/stdio.h" type="include file" />
</ldi>

This construct creates an element stdio.h in the namespace user.include.

Example LDI Files#

Here are a few example LDI files that you can use to get started:

This is a very simple LDI file that shows you how to set up subsystems and dependencies along with their strengths: example1.ldi.xml.
This LDI file shows you how to specify elements that show up organized in a hierarchy: example2.ldi.xml.
This LDI file shows you how to specify elements organized in a hierarchy with dependency strengths of different kinds: example3.ldi.xml.

LDI Member Level#

The LDI plugin supports member level.

You can specify that an element is a member level type by setting the member attribute in the elementtype tag.

A sample of an LDI file with member level is as follow:

<?xml version="1.0" encoding="UTF-8" ?>
<ldi delimiter=".">

   <elementtype type="class" display="Class" member="false" />
   <elementtype type="classmethod" display="Method" member="true" />
   <elementtype type="classfield" display="Field" member="true" />

   <element name="SystemA" type="class">
    <property name="#description">This is SystemA</property>
    <uses provider="SystemB" kind="Class Reference" strength="5"/>
   </element>

   <element name="SystemA.method1" type="classmethod">
    <uses provider="SystemB" kind="Method Invocation" strength="3"/>
   </element>

   <element name="SystemA.field1" type="classfield"/>

   <element name ="SystemB" type="class"/>
</ldi>

In the example above, SystemA is a class element type with its member attribute set to “false”, so System A is not a member level element. SystemA.method1 and SystemA.field1 are member level because their member attribute is set to “true”. The example above generates the following DSM, showing only the parent elements, by default:

You can then expand the member level by right-click on the $root and select Expand Members, which will expand the parent elements, if there are any member elements associated with it (See figure below).

LDI

Contents