12. Code Package

The Code package defines a set of meta-model elements whose purpose is to represent implementation level program elements and their associations. This facet of knowledge about existing software systems corresponds to the logical view. It is determined by one or more programming languages used in the design of the particular existing software system. Code package includes meta-model elements which represent common program elements supported by various programming languages, such as data types, data items, classes, procedures, macros, prototypes, and templates.

As a general rule, in a given KDM instance, each instance of the code meta-model element represents some programming language construct, determined by the programming language of the existing software system. Each instance of a code meta-model element corresponds to a certain region of the source code in one of the artifacts of the existing software system. Exceptions to this rule are:

instances of the CodeModel meta-model element which are parts of the KDM infrastructure. This meta-model element is a container for other code element instances.
instances of code element that explicitly represent certain abstractions provided by a programming language, such as primitive datatypes, and predefined datatypes.

Organization of the Code Package

The Code package consists of the following 24 class diagrams:

CodeModel
CodeInheritances
Modules
ControlElements
DataElements
Values
PrimitiveTypes
EnumeratedTypes
CompositeTypes
DerivedTypes
Signature
DefinedTypes
ClassTypes
Templates
TemplateRelations
ClassRelations
TypeRelations
InterfaceRelations
PreprocessorDirectives
PreprocessorRelations
Comment
Visibility
VisibilityRelations
ExtendedCodeElements

The Code package depends on the following packages:

Source

Core

kdm

CodeModel Class Diagram

The CodeModel class diagram follows the uniform pattern for KDM models and extends the KDM framework with specific meta-model elements related to implementation-level program elements and their associations.

The CodeModel diagram defines the following classes determined by the KDM model pattern:

CodeModel – a class representing a model for CodeElement.
AbstractCodeElement – a class representing an abstract parent class for all KDM entities that can be used to model code.
AbstractCodeRelationship – a class representing an abstract parent of all KDM relationships that can be used to represent code

The CodeModel diagram also defines several key abstract classes which determine the KDM taxonomy for program elements:

CodeItem
ComputationalObject
Datatype
Module

The class diagram shown in See – CodeModel Class Diagram. captures these classes and their relations.

– CodeModel Class Diagram

CodeModel Class

The CodeModel is the specific KDM model which corresponds to the logical view of the implementation of the existing software system. CodeModel is the only model of the Program Elements Layer of KDM. CodeModel follows the uniform pattern for KDM models.

Superclass

KDMModel

Associations

codeElement:AbstractCodeElement[0..*] {ordered}

The set of the top-level elements that are defined in this code model. The CodeModel element is the owner of such CodeElement. This property subsets the ownedElement property of KDMModel derived union.

Constraints

Semantics

CodeModel is a container for code elements. It is the implementer’s responsibility to arrange code elements into one or more code models. KDM import tools should not make any assumptions about the organization of code elements into code models.

AbstractCodeElement Class (abstract)

The AbstractCodeElement is an abstract class representing any generic determined by a programming language.

Superclass

KDMEntity

Associations

codeRelation:CodeRelation[0..*]	The set of code relations owned by this code model.
source: SourceRef[0..1]	Link to the physical artifact for the given code element.

Constraints

Semantics

AbstractCodeElement is an abstract class that is used to constrain the owned elements of some KDM containers in the Code model.

AbstractCodeRelationship Class (abstract)

The AbstractCodeRelationship is an abstract class representing any relationship determined by a programming language.

Superclass

KDMRelationship

Constraints

Semantics

AbstractCodeRelationship is an abstract class that is used to constrain the subclasses of KDMRelationship in the Code model.

CodeItem Class (abstract)

CodeItem class represents the named elements determined by the programming language (the so-called “symbols,” “definitions,” etc.). There are AbstractCodeElements that are not CodeItems, for example ActionElements that are defined in the Action package.

Superclass

AbstractCodeElement

Semantics

CodeItem is an abstract class that is used to constrain the owned elements of some KDM containers in the Code model.

ComputationalObject Class (abstract)

ComputationalObject class represents the named elements determined by the programming language which describe certain computational objects at the runtime, for example, procedures, and variables.

Superclass

CodeItem

Datatype Class (abstract)

Datatype class represents the named elements determined by the programming language which describe datatypes.

Superclass

CodeItem

CodeInheritances Class Diagram

The CodeInheritances class diagram define how classes of the Code package inherit from the Core package. The class diagram shown in See – CodeInheritances Class Diagram. captures these relations.

– CodeInheritances Class Diagram

Modules Class Diagram

The Modules class diagram defines meta-model elements that represent packaging aspects of programming languages, such as compilation units, shared files, and binary components. The class diagram shown in See – Module Class Diagram. captures these classes and their associations.

– Module Class Diagram

Module Class (generic)

The Module class is a generic KDM modeling element that represents an entire software module or a component, as determined by the programming language and the software development environment. A module is a discrete and identifiable program unit that contains other program elements and may be used as a logical component of the software system. Usually modules promote encapsulation (i.e. information hiding) through a separation between the interface and the implementation. In the context of representing existing software systems, modules provide the context for establishing the associations between the programming language elements which are owned by them, especially when the same logical component of a software product line is compiled multiple times with different compilation options and linked into multiple executables. Instances of the Module class represent the logical containers for program elements determined by the programming language. Modules may be further related to other KDM items, for example to KDM Inventory items of the Inventory model; or to KDM deployment elements of the Platform model. In the situation of modeling a complex software product line, logical Modules may need to be duplicated, because the exact relationships determined by the particular software component may depend on the engineering context.

The Module is an abstract KDM container that provides a common parent for several concrete classes.

Superclass

CodeItem

Associations

codeElement:AbstractCodeElement[0..*] {ordered}

The list of owned CodeElement.

Constraints

Module class and its subclasses should not own SourceRef elements

Code Model can not directly own any code elements other than the subclasses of the Module class
Every code element should be owned by some instance of the Module class or its subclasses
Instance of the Module element should have at least one stereotype
No other code element should own Module elements and its subclasses.

Semantics

Module is a logical container for program elements. Subclasses of Module element define semantically distinct flavors of Module, representing common categories of containers.

It is the implementer’s responsibility to select an appropriate subclass of the Module element.

CompilationUnit Class

The CompilationUnit class is a meta-model element which represents a logical container which owns program elements. A compilation unit is an logical part of the existing software system which is sufficiently complete to be processed by the corresponding software development environment. Compilation unit is usually related to some artifact of the existing software system, for example, a physical source file. Compilation units are supported by the selected programming languages of the existing software system and as determined by the corresponding engineering process.

Superclass

Module

Semantics

CompilationUnit is a stand-alone named container for program elements. Usually a CompilationUnit corresponds to a SourceFile in the InventoryModel.

SharedUnit Class

The SharedUnit class is a meta-model element which represents a shared source file as supported by the selected programming languages of the existing software system and as determined by the engineering process.

Superclass

Module

Semantics

SharedUnit is a subclass of CompilationUnit, which emphasizes the ability of the program elements owned by the SharedUnit to be shared among stand-alone program elements through some form of inclusion mechanism.

LanguageUnit class

The LanguageUnit class is a meta-model element which represents predefined datatypes and other common elements determined by a particular programming language.

Superclass

Module

Constraints

PredefinedType class and its subclasses can only be contained in a LanguageUnit container.

Semantics

LanguageUnit is a logical container that owns definitions of primitive and predefined datatypes for a particular language, as well as other common elements for a particular programming language. LanguageUnit may or may not correspond to a SourceFile in the InventoryModel. Some of the predefined program elements are defined in standards system files. It is the implementer’s responsibility to add such files to the InventoryModel. Primitive datatypes usually do not have any corresponding files, in this situation the LanguageUnit does not have a counterpart in the InventoryModel.

CodeAssembly Class

The CodeAssembly represents a logical container for the program elements that were built together (for example, compiled and linked into an executable, so that all variant selection during the compilation and static linking was resolved in a certain coordinated fashion). The same collection of logical entities has to be analyzed together. Same source files may produce a different logical model (for example, when compiled and linked for a different hardware platform, or for a different operating system). The CodeAssembly represents a collection of entities that have been analyzed together. A different variant of the conceptual family of software systems (even involving same compilation units) may need to be cloned into a separate CodeAssembly.

Superclass

Module

Semantics

CodeAssembly is a logical container that provides the context for entities and relationships for a collection of program elements. CodeAssembly may correspond to an ExecutableFile elements of the InventoryModel.

Package Class

The Package class is a subtype for Module that logical collections of program elements, as directly supported by some programming languages, such as Java..

Superclass

Module

Semantics

A Package is a logical container for program elements as well as Modules. Packages can be nested.

ControlElements Class Diagram

The ControlElements class diagram defines basic meta-model elements to represent callable computational objects, such as procedures, functions, methods, etc. The class diagram shown in See – ControlElements Class Diagram. shows these classes and their relations.

– ControlElements Class Diagram

ControlElement class (generic)

The ControlElement class is a common superclass that defines attributes for callable code elements. In the meta-model it has the role of an endpoint for some KDM relations.

Superclass

ComputationalObject

Attributes and Associations

type:Datatype[0..1]	Optional association to the datatype of this control element
codeElement:AbstractCodeElement[0..*] {ordered}	Represents owned code elements, such as local definitions and actions.

Constraints

ControlElement should have at least one stereotype

ControlElement should own a Signature

Semantics

ControlElement is a generic element with under specified semantics that can be used as an extension point to define new “virtual” meta-model elements that represent specific named control constructs that do not fit into semantic categories of the concrete subclasses of ControlElement.

ControlElement represents named items of software system which describe certain behavior that can be performed by demand, through the invocation mechanism, such as a call-return mechanism, directly supported by many processor units and high-level programming languages.

ControlElement owns other program elements, which can include nested ControlElements.

CallableUnit Class

The CallableUnit represents a basic stand-alone element that can be called, such as a procedure or a function.

Superclass

ControlElement

Attributes

kind:CallableKind

Indicator of the kind of the callable unit

Semantics

A CallableUnit represents a named unit of behavior that can be invoked through a call-return mechanism. This is a subclass of a ControlElement. From the runtime perspective, a CallableUnit element represents a single computational object which is identified directly (using the name) or indirectly (using a reference). More precisely, the call-return mechanism implies an invocation stack, since a CallableUnit may call itself, and there may be multiple instances of the behavior represented by the CallableUnit, at various stages of completion, each corresponding to an entry in the invocation stack.

A CallableUnit represents global or local procedures and functions.

CallableKind Data Type (enumerated)

CallableKind enumerated data type specifies some common properties of the CallableUnit.

Literal values:

regular	specifies a regular definition of a procedure or function
external	specifies an external procedure (a prototype, definition is elsewhere)
operator	specifies a definition of an operator
stored	specifies a stored procedure in DataModel
unknown	properties are unknown

MethodUnit Class

The MethodUnit represents member functions owned by a ClassUnit.

Superclass

CallableElement

Attributes

kind:MethodKind	Indicator of the kind of the method represented by this element
export: ExportKind	represents the visibility of the method (public, private, protected)

Semantics

The MethodUnit represents member functions owned by a ClassUnit, including user-defined operators, constructors and destructors.

From the runtime perspective, each MethodUnit element represents a computational object that exists in the context of some class instance, therefore there exist multiple instances of such objects, each identified by the method name as well as the reference to the corresponding class instance. A class instance is identified either directly (by name) or indirectly (by reference).

MethodKind data type (enumeration)

MethodKind enumerated data type defines additional specification of the kind of method, defined by a MethodUnit model element.

Literal Values

method	the MethodUnit represents a regular member function
constructor	the MethodUnit represents a constructor
destructor	the MethodUnit represents a destructor
operator	the MethodUnit represents an operator
virtual	the MethodUnit represents a virtual method
abstract	the MethodUnit represents an abstract method or member of an Interface
unknown	the kind of the MethodUnit is none of the above

Example (C language):

int main(int argc, char* argv[]) {

printf(“Hello, World\n”);

}

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

<kdm:Segment xmi:version="2.1"

xmlns:xmi="http://www.omg.org/XMI"

xmlns:action="http://kdm.omg.org/action"

xmlns:code="http://kdm.omg.org/code"

xmlns:kdm="http://kdm.omg.org/kdm"

xmlns:source="http://kdm.omg.org/source" name="HelloWorld Example">

<model xmi:id="id.0" xmi:type="code:CodeModel" name="HelloWorld">

<codeElement xmi:id="id.1" xmi:type="code:CompilationUnit" name="hello.c">

<codeElement xmi:id="id.2" xmi:type="code:CallableUnit"

name="main" type="id.5" kind="regular">

<source xmi:id="id.3" language="C" snippet="int main(int argc, char* argv[]) {}"/>

<entryFlow xmi:id="id.4" to="id.12" from="id.2"/>

<codeElement xmi:id="id.5" xmi:type="code:Signature" name="main">

<source xmi:id="id.6" snippet="int main(int argc, char * argv[]);"/>

<parameterUnit xmi:id="id.7" name="argc" type="id.25" pos="1"/>

<parameterUnit xmi:id="id.8" name="argv" type="id.9" pos="2">

<codeElement xmi:id="id.9" xmi:type="code:ArrayType">

<itemUnit xmi:id="id.10" type="id.19"/>

</codeElement>

</parameterUnit>

<parameterUnit xmi:id="id.11" type="id.25" kind="return"/>

</codeElement>

<codeElement xmi:id="id.12" xmi:type="action:ActionElement" name="a1" kind="Call">

<source xmi:id="id.13" language="C" snippet="printf(&quot;Hello, World!\n&quot;);"/>

<codeElement xmi:id="id.14" xmi:type="code:Value"

name="&quot;Hello, World!\n&quot;" type="id.19"/>

<actionRelation xmi:id="id.15" xmi:type="action:Reads" to="id.14" from="id.12"/>

<actionRelation xmi:id="id.16" xmi:type="action:Calls" to="id.20" from="id.12"/>

<actionRelation xmi:id="id.17" xmi:type="action:CompliesTo"

to="id.20" from="id.12"/>

</codeElement>

</codeElement>

</codeElement>

<codeElement xmi:id="id.18" xmi:type="code:LanguageUnit">

<codeElement xmi:id="id.19" xmi:type="code:StringType" name="char *"/>

<codeElement xmi:id="id.20" xmi:type="code:CallableUnit" name="printf" type="id.21">

<codeElement xmi:id="id.21" xmi:type="code:Signature" name="printf">

<parameterUnit xmi:id="id.22" name="" type="id.25" kind="return" pos="0"/>

<parameterUnit xmi:id="id.23" name="format" type="id.19" pos="1"/>

<parameterUnit xmi:id="id.24" name="arguments" kind="variadic" pos="2"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.25" xmi:type="code:IntegerType" name="int"/>

</codeElement>

</model>

<model xmi:id="id.26" xmi:type="source:InventoryModel" name="HelloWorld">

<inventoryElement xmi:id="id.27" xmi:type="source:SourceFile"

name="hello.c" language="C"/>

</model>

</kdm:Segment>

DataElements Class Diagram

The DataElements class diagram defines meta-model constructs to represent the named data items of existing software systems, for example, global and local variables, record files, and formal parameters. The class diagram at See – DataElement Class Diagram. shows these classes and their associations.

– DataElement Class Diagram

DataElement class (generic)

The DataElement class is a generic modeling element that defines the common properties of several concrete classes that represent the named data items of existing software systems, for example, global and local variables, record files, and formal parameters. KDM models usually use specific concrete subclasses. The DataElement class itself is a concrete class that can be used as an extended code element, with a certain stereotype. As an extended element DataElement is more specific than CodeElement.

Superclass

ComputationalObject

Attributes

ext:String	optional extension representing the original representation of the data element
size: Integer	specifies the optional constraint on the number of elements any value of the storable element may contain according to the semantics of the base datatype. Size attribute corresponds to the maximum-size bound in a size-subtype of the base datatype.

Associations

codeElement:Datatype[0..*]	anonymous datatypes used in the definition of the datatype of the current DataElement
type:Datatype[1]	the datatype of the DataElement, that describes the values of the DataElement

Semantics

DataElement represents computational objects of existing software system which are associated with a value of a particular datatype. DataElement class is an extended meta-model element, that can be used to represent variables of an existing software system, that do not fit into more precise semantics of the subclasses of DataElement.

Constraints

DataElement class should have at least one Stereotype.

StorableUnit class

StorableUnit class is a concrete subclass of the StorableElement class that represents variables of the existing software system.

Superclass

DataElement

Attribute:

kind:StorableKind

optional attribute that specifies the common details of a StorableUnit (see StorableKind enumeration datatype).

Semantics:

StorableUnit represents a variable of existing software system – a computational object to which different values of the same datatype can be associated at different times. From the runtime perspective, a StorableUnit element represents a single computational object which is identified either directly (by name) or indirectly (by reference).

StorableUnit represents both global and local variables.

StorableKind data type (enumeration)

StorableKind enumeration data type defines several common properties of a StorableUnit related to their life-cycle, visibility and memory type.

Literal values:

global	specifies a global variable
local	specifies a local variable
static	specifies a global variable with restricted scope
external	specifies an external variable (a prototype)
register	specifies a temporary variable
unknown	properties are unknown

ExportKind data type (enumeration)

ExportKind enumeration data type defines several common properties of a MemberUnit and MethodUnit related to their visibility and other properties.

Literal values:

public	specifies a public member or method
private	specifies private member or method
protected	specifies a protected member or method
final	specifies final member or method
unknown	properties are unknown

ItemUnit class

ItemUnit class is a concrete subclass of the DataElement class that represents anonymous data items that are parts of complex datatypes, for example, record fields, pointers, and arrays. Instances of ItemUnit class are endpoints of KDM data relations that describe access to complex datatypes.

Superclass

DataElement

Semantics

An ItemUnit represents a data element that exists in the context of another data element. From the runtime perspective, each ItemUnit represents a family of data elements, each of which is identified not only by the identity of the ItemUnit, but also by the identity of the owner element.

IndexUnit class

IndexUnit class is a concrete subclass of the DataElement class that represents an index of an array datatype. Instances of IndexUnit class are endpoints of KDM data relations that describe access to arrays.

Superclass

DataElement

Semantics

IndexUnit represents an index of an ArrayType. IndexUnit is an optional element.

MemberUnit class

MemberUnit class is a concrete subclass of the DataElement class that represents an member of a class type. Instances of MemberUnit class are endpoints of KDM data relations that describe access to classes. MemberUnit is similar to an ItemUnit. The difference between a ItemUnit and a MemberUnit is that a ItemUnit usually represents a part of a certain existing computational object, while the computational object corresponding to a MemberUnit is usually determined by the class instance. In case of accessing structures via pointers, this distinction becomes more subtle. MemberUnit defines some additional attributes.

Superclass

DataElement

Attributes

export:ExportKind

represents the visibility of the member (public, private, protected)

Constraints

MemberUnit can be owned only by a ClassUnit

Semantics

MemberUnit represents a member of a class. From the runtime perspective, each MemberUnit element represents a family of computational objects, each of which is a part of some class instance.Each MemberUnit is identified by the name of the MemberUnit, as well as by the direct of indirect identity of the corresponding class instance.

ParameterUnit class

ParameterUnit class is a concrete subclass of the DataElement class that represents an formal parameter, for example a formal parameter of a procedure. ParameterUnits are owned by the Signature element. Instances of ParameterUnit class are endpoints of KDM data relations that describe access to formal parameters.

Superclass

DataElement

Attributes

kind:ParameterKind	optional attribute defining the parameter passing convention for the attribute
pos:Integer	position of the attribute in the signature

Constraints

return parameter of a signature does not have a pos attribute

return ParameterUnit is a signature should have a kind=”return”
there can be at most one ParameterUnit within a certain Signature with a return kind

Semantics

ParameterUnit is a data element that from the runtime perspective represents a computational object that exists in the context of an instance of some ControlElement “in the process of execution”.

Instances of ParameterUnit class are owned by a instances of a Signature class. ParameterUnits within a Signature are ordered. The value of the pos attribute of a ParameterUnit should correspond to the position of the parameter in the Signature. The return ParameterUnit is distinguished by the value of the kind attribute. To represent signatures of programming languages that allow named parameters (binding of actual parameters by name rather than by a position), the producer of the KDM model is responsible for computing correct positions of the named parameters and determining appropriate ParameterUnits as targets for relations to named parameters. ParameterKind enumeration datatype is described in section “Signature class diagram”.

ValueElements class diagram

ValueElements class diagram defines meta-model elements that represent data values which are used in the artifacts of the existing software system.

The classes and associations of the ValueElements class diagram are shown at See – ValueElements Class Diagram..

– ValueElements Class Diagram

ValueElement class (abstract)

ValueElement class is an abstract meta-model element that represents values used in the artifacts of existing software systems. This abstract class defines the common properties of the concrete subclasses, for which more precise semantics is provided. KDM model of an existing software system usually uses concrete subclasses of the ValueElement class.

Superclass

DataElement

Constraints:

ValueElement and its subclasses not have owned code elements

ValueElement and its subclasses can not be used as the target of relations Writes, and Addresses

Semantics

A value element is a data element which represents a single value of the corresponding datatype.

ValueElement class and its subclasses correspond to ISO/IEC 11404:1996 literals and values. The datatype of the value is represented by the type property (defined for its superclass DataElement class).

Value class

Value class is a meta-model element that represents values used in the artifacts of existing software systems.

Superclass

ValueElement

Semantics

Value class corresponds to ISO/IEC 11404:1996 literals of primitive types, such as boolean-literal, state-literal, enumerated-literal, character-literal, ordinal-literal, time-literal, integer-literal, rational-literal, scaled-literal, real-literal, void-literal, pointer-literal, bitstring-literal, string-literal.

The name attribute of the ValueClass represents the name or a string representation of the value.

ValueList class

The ValueList class is a meta-model element that represents values of aggregated datatypes.

Superclass

ValueElement

Associations

valueElement:ValueElement[0..*]

component values

Semantics

A ValueList is a data element associated with a single value of some non-primitive datatype. The value of the complex datatype is represented as a tuple of values for each subcomponent of the complex datatype.

Value class corresponds to ISO/IEC 11404:1996 values for aggregated datatypes such as choice-value, record-value, set-value, sequence-value, bag-value, array-value, table-value.

Data representation of KDM is aligned with ISO/IEC 11404 (Language-Independent datatypes) standard. In particular, KDM provides distinct meta-model elements for “data elements” (for example, global and local variables, constants, record fields, parameters, class members, array items and pointer base elements) and “datatypes”. Each data element has an association “type” to its datatype. KDM distinguishes primitive datatypes (for example Integer, Boolean), complex user-defined datatypes (for example, array, pointer, sequence) and named datatypes (for example, a class, a synonym type). KDM meta-model elements corresponding to datatypes are subclasses of a generic class Datatype. KDM meta-model elements corresponding to data elements are subclasses of a generic class DataElement.

KDM model elements represent existing artifacts determined by a programming language. KDM meta-model elements provide sufficient coverage for most common datatypes and data elements, common to programming languages. KDM also provides several powerful generic extensible elements that can be further used with stereotypes to represent uncommon situations.

In addition to the type association, KDM relationship “HasType” is used to track named datatypes. Anonymous datatypes can be owned by the data element that uses it.

Concrete examples of datatypes, data items and the use of the type association and the HasType relationship are provided further in the text of the specification.

PrimitiveTypes Class Diagram

The PrimitiveTypes class diagram defines meta-model elements which represent predefined types common to various programming languages. The classes and association of the PrimitiveTypes diagram are shown in See – PrimitiveTypes Class Diagram..

– PrimitiveTypes Class Diagram

PrimitiveType class (generic)

The PrimitiveType is a generic meta-model element which represents primitive data types determined by various programming languages.

Superclass

Datatype

Constraints

PrimitiveType should have at least one stereotype

Semantics

PrimitiveType element has under specified semantics. It can be used as an extension point to define new “virtual” meta-model elements to represent specific primitive types that do not fit into semantic categories defined by concrete subclasses of PrimitiveType class.

BooleanType Class

The BooleanType is a meta-model element which represents Boolean data types common to various programming languages. A Boolean is a mathematical datatype associated with two-valued logic.

Superclass

PrimitiveType

Semantics

The KDM BooleanType class corresponds to ISO/IEC 11404:1996 Boolean datatype.

CharType Class

The CharType is a meta-model element which represents character data types common to various programming languages. Character is a family of datatypes whose value spaces are character-sets

Superclass

PrimitiveType

Semantics

The KDM CharType class corresponds to ISO/IEC 11404:1996 Character datatype.

OrdinalType Class

The OrdinalType class is a meta-model element that represents ordinal datatypes available in some programming languages. Ordinal is the datatype of the ordinal numbers, as distinct from the quantifying numbers (datatype Integer). Ordinal is the infinite enumerated type.

Superclass

PrimitiveType

Semantics

The KDM OrdinalType class corresponds to ISO/IEC 11404:1996 Ordinal datatype.

The EnumeratedTypes class diagram defines meta-model elements that represent enumerated types, which are common to various programming languages. The classes and associations of the EnumeratedTypes diagram are shown in See – EnumeratedTypes Class Diagram..

– EnumeratedTypes Class Diagram

EnumeratedType Class

The EnumeratedType is a meta-model element that represents user-defined enumerated data types. EnumeratedType datatype defines the set of enumerated literals. Enumerated datatype is a user-defined datatype, which has a finite number of distinguished values.

Superclass

Datatype

Associations

value:Value[0..*] {ordered}

The list of enumerated literals defined for the given EnumeratedType.

Semantics

EnumeratedType corresponds to ISO/IEC 11404:1996 Enumerated and State families of datatypes. Enumerated datatype is a family of datatypes, each of which comprises a finite number of distinguished values having and intrinsic order. State is a family of datatypes, each of which comprises a finite number of distinguished but unordered values. KDM does not make distinction between these two families.

Values of the Enumerated and State datatypes are represented by a Value meta-model element which is owned by the EnumeratedType.

CompositeTypes Class Diagram

The CompositeTypes class diagram defines meta-model elements which. represent common composite datatypes provided by various programming languages, for example records, structures, and unions. Composite datatypes is a broad category of user-defined datatypes that includes situations, in which the value of the datatype is made up of values of multiple component datatypes

The classes and associations of the StructuredTypes diagram are shown in See – CompositeTypes Class Diagram..

– CompositeTypes Class Diagram

CompositeType Class (generic)

The CompositeType is a meta-model element that represents user-defined composite datatypes, such as records, structures and unions. This element is further subclassed by more specific KDM classes. CompositeType class defines common properties for its specific subclasses, each of which has distinct semantics. CompositeType class is a KDM container. KDM models of existing software systems usually use the concrete subclasses of CompositeType class. CompositeType class itself is a concrete class and can be used as an extended meta-model element, with a stereotype. CompositeType class is a more specific meta-model element than CodeElement.

Superclass

Datatype

Associations

itemUnit:ItemUnit[0..*] {ordered}

the list of named items that represent components of the composite datatype, for example representing the individual fields of a record.

Constraints

CompositeType class should be used with a stereotype

Semantics

CompositeType class corresponds to ISO/IEC 11404:1996 generated datatypes each of whose values is made up of values of component datatypes. In particular, KDM CompositeType class corresponds to aggregate datatypes that involve a field list in their definition, and choice datatype. The Name attribute of each ItemUnit owned by the CompositeType represents the name of the field-type. The datatype of the field-type is represented by the type attribute of the ItemUnit.

CompositeType class is an extended meta-model element, that can be used to represent generated datatypes of an existing software system, that do not fit into more precise semantics of the subclasses of CompositeType.

Any anonymous datatype used by a ItemUnit of the CompositeType should be owned by that ItemUnit.

ChoiceType Class

The ChoiceType class is a meta-model element that represents choice datatypes: user-defined datatypes in existing software systems, each of whose values is a single value from any of a set of alternative datatypes. An example of a choice datatype is a Pascal and Ada variant record, and a union in the C programming language. In the KDM representation, each alternative datatype is represented as an ItemUnit..

Superclass

CompositeType

Constraints

Semantics

The ChoiceType corresponds to ISO/IEC 11404:1996 choice generated datatype. KDM representation does not explicitly represent the field-identifier. Name attribute of each ItemUnit owned by the ChoiceType represents either the field-identifier of the alternative datatype or a single select item that identify the variant. The datatype of the alternative is represented by the type attribute of the ItemUnit owned by the ChoiceType.

RecordType Class

The RecordType class is a meta-model element that represents record datatypes: user-defined datatypes in existing software systems, whose values are heterogeneous aggregations (tuples) of values of component datatypes, each aggregation having one value of each component datatype. Component datatypes are keyed by a fixed “field-identifier”, which is represented by the Name attribute of the ItemUnit owned by the RecordType. Examples of record datatypes include a structure in C, a record in Cobol..

Superclass

CompositeType

Constraints

Semantics

The RecordType corresponds to ISO/IEC 11404:1996 record aggregate datatype. The Name attribute of each ItemUnit owned by the RecordType represents the field-identifier. The datatype of the field is represented by the type attribute of the ItemUnit owned by the ChoiceType.

Example (Cobol):

01 StudentDetails.

02 StudentId PIC 9(7).

02 StudentName.

03 FirstName PIC X(10).

03 MiddleInitial PIC X.

03 Surname PIC X(15).

02 DateOfBirth.

03 DayOfBirth PIC 99.

03 MonthOfBirth PIC 99.

03 YearOfBirth PIC 9(4).

02 CourseCode PIC X(4).



MOVE "Doyle" To Surname

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

<kdm:Segment xmi:version="2.1"

xmlns:xmi="http://www.omg.org/XMI"

xmlns:action="http://kdm.omg.org/action"

xmlns:code="http://kdm.omg.org/code"

xmlns:kdm="http://kdm.omg.org/kdm" name="Record Example">

<model xmi:id="id.0" xmi:type="code:CodeModel">

<codeElement xmi:id="id.1" xmi:type="code:CompilationUnit">

<codeElement xmi:id="id.2" xmi:type="code:StorableUnit"

name="StudentDetails" type="id.3">

<codeElement xmi:id="id.3" xmi:type="code:RecordType" name="StudentDetails">

<itemUnit xmi:id="id.4" name="StudentID" type="id.23" ext="PIC 9(7)"/>

<itemUnit xmi:id="id.5" name="StudentName" type="id.6">

<codeElement xmi:id="id.6" xmi:type="code:RecordType" name="StudentName">

<itemUnit xmi:id="id.7" name="FirstName" type="id.24" ext="PIC X(10)" size="10"/>

<itemUnit xmi:id="id.8" name="MiddleName" type="id.24" ext="PIC X" size="1"/>

<itemUnit xmi:id="id.9" name="Surname" type="id.24" ext="PIC X(15)" size="15"/>

</codeElement>

</itemUnit>

<itemUnit xmi:id="id.10" name="DateOfBirth">

<codeElement xmi:id="id.11" xmi:type="code:RecordType" name="DateOfBirth">

<itemUnit xmi:id="id.12" name="DayOfBirth" type="id.23" ext="PIC 99" size="2"/>

<itemUnit xmi:id="id.13" name="MonthOfBirth" type="id.23" ext="PIC 99" size="2"/>

<itemUnit xmi:id="id.14" name="YearOfBirth" type="id.23" ext="PIC 9(4)"

size="4"/>

</codeElement>

</itemUnit>

<itemUnit xmi:id="id.15" name="CourseCode" type="id.24" ext="PIC X(4)" size="4"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.16" xmi:type="action:BlockUnit">

<codeElement xmi:id="id.17" xmi:type="action:ActionElement">

<codeElement xmi:id="id.18" xmi:type="code:Value"

name="&quot;Doyle&quot;" type="id.24"/>

<actionRelation xmi:id="id.19" xmi:type="action:Addresses" to="id.2" from="id.17"/>

<actionRelation xmi:id="id.20" xmi:type="action:Reads" to="id.18" from="id.17"/>

<actionRelation xmi:id="id.21" xmi:type="action:Writes" to="id.9" from="id.17"/>

</codeElement>

</codeElement>

</codeElement>

<codeElement xmi:id="id.22" xmi:type="code:LanguageUnit" name="Cobol common definitions">

<codeElement xmi:id="id.23" xmi:type="code:DecimalType"/>

<codeElement xmi:id="id.24" xmi:type="code:StringType"/>

</codeElement>

</model>

</kdm:Segment>

DerivedTypes Class Diagram

The DerivedTypes class diagram defines meta-model elements that represent derived types, which are common to various programming languages. Examples of derived types include pointers, arrays, and sets. Derived datatypes is a broad category of user-defined datatypes that include situations, in which the value of the datatype is made up of values of a single component datatype, usually referred to as the element datatype.The classes and associations of the DerivedTypes diagram are shown in See – DerivedTypes Class Diagram..

– DerivedTypes Class Diagram

DerivedType Class (generic)

DerivedType class defines common properties for its specific subclasses, each of which has distinct semantics. DerivedType class is a KDM container. KDM models of existing software systems usually use the concrete subclasses of DerivedType class. DerivedType class itself is a concrete class and can be used as an extended meta-model element, with a stereotype. DerivedType class is a more specific meta-model element than CodeElement.

Superclass

Datatype

Associations

itemUnit:ItemUnit[1]

The ItemUnit that represents the base class of the derived type.

Constraints

DerivedType class should be used with a stereotype

Semantics

DerivedType class corresponds to several ISO/IEC 11404:1996 aggregated datatypes, whose values are made up of values of a single component datatype. DerivedType class is an extended meta-model element, that can be used to represent aggregated datatypes with a single base datatype of an existing software system, that do not fit into more precise semantics of the subclasses of DerivedType. The name attribute of the ItemUnit can be omitted. The datatype of the element-type is represented by the type attribute of the ItemUnit owned by the DerivedType.

Any anonymous datatype used by ItemUnit of the DerivedType should be owned by that ItemUnit.

ArrayType Class

The ArrayType is a meta-model element that represents array datatypes.

Superclass

DerivedType

Attributes

size:Integer

the size of the array (the maximum number of elements)

Associations

indexUnit:IndexUnit[1]

the index of the array

Constraints

Semantics

ArrayType corresponds to ISO/IEC 11404:1996 array datatype. The name attribute of the ItemUnit can be omitted if the element type is anonymous. The datatype of the element-type is represented by the type attribute of the ItemUnit owned by the ArrayType. The IndexItem represents the index of the array. The name attribute of the IndexUnit can be omitted.

KDM ArrayType supports a single index. Multidimensional arrays can be represented where an ItemUnit is referencing an anonymous ArrayType that represents internal dimensions(s). The IndexItem of the ArrayType that owns an internal anonymous ArrayType precedes the IndexItem of the owned ArrayType.

Any anonymous datatype used by IndexUnit of the ArrayType should be owned by that IndexUnit.

PointerType Class

The PointerType is a meta-model element that represents pointer datatypes whose values constitutes a means of reference to values of another datatype, designated the element datatype.

Superclass

DerivedType

Constraints

Semantics

PointerType corresponds to ISO/IEC 11404:1996 pointer generated datatype. From ISO perspective the pointer datatype is not an aggregated datatype, which leads to some mismatch with the semantics of the superclass. The Name attribute of the ItemUnit owned by the PointerType can be omitted. The datatype of the element-type is represented by the type attribute of the ItemUnit owned by the PointerType.

Example (C):

struct tlist {

struct tlist * next;

int value;

} * phead, * pcurrent;

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

<kdm:Segment xmi:version="2.1"

xmlns:xmi="http://www.omg.org/XMI"

xmlns:code="http://kdm.omg.org/code"

xmlns:action="http://kdm.omg.org/action"

xmlns:kdm="http://kdm.omg.org/kdm" name="LinkedList Example">

<model xmi:id="id.0" xmi:type="code:CodeModel">

<codeElement xmi:id="id.1" xmi:type="action:BlockUnit">

<codeElement xmi:id="id.2" xmi:type="code:StorableUnit"

name="phead" type="id.3" kind="unknown">

<codeElement xmi:id="id.3" xmi:type="code:PointerType">

<itemUnit xmi:id="id.4" type="id.5">

<codeElement xmi:id="id.5" xmi:type="code:RecordType" name="tlist">

<itemUnit xmi:id="id.6" name="next" type="id.3"/>

<itemUnit xmi:id="id.7" name="value" type="id.8">

<codeElement xmi:id="id.8" xmi:type="code:IntegerType" name="int"/>

</itemUnit>

</codeElement>

</itemUnit>

</codeElement>

</codeElement>

<codeElement xmi:id="id.9" xmi:type="code:StorableUnit"

name="pcurrent" type="id.3" kind="unknown"/>

</codeElement>

</model>

</kdm:Segment>

RangeType Class

RangeType is a meta-model element that represents user-defined subtypes of any ordered datatype by placing new upper and/or lower bounds on the value space.

Superclass

DerivedType

Attributes

lower: Integer	The optional lower boundary of the range
upper: Integer	The optional upper boundary of the range

Constraints

At least one boundary value attribute should be present

Semantics

RangeType corresponds to ISO/IEC 11404:1996 range subtype. From ISO perspective the range subtype is not an aggregated datatype, which leads to some mismatch with the semantics of the superclass. The Name attribute of the ItemUnit owned by the RangeType can be omitted. The datatype of the base type is represented by the type attribute of the ItemUnit owned by the RangeType.

When a boundary value attribute is omitted, this means that the corresponding value is unspecified.

BagType class

BagType class is a meta-model element that represents bag types in existing software systems: the user-defined datatypes, whose values are collections of instances of values from the element datatype. Bag types allow multiple instances of the same value occur in a given collection; the ordering of the value instances in not significant.

Superclass

DerivedType

Semantics

BagType corresponds to ISO/IEC 11404:1996 bag aggregated datatype. The Name attribute of the ItemUnit owned by the BagType can be omitted. The datatype of the element type is represented by the type attribute of the ItemUnit owned by the BagType.

SetType class

SetType is a meta-model element that represents set types in existing software systems: the user-defined datatypes, whose value space is the set of all subsets of the value space of the element datatype, with operations appropriate to the mathematical set.

Superclass

DerivedType

Semantics

SetType corresponds to ISO/IEC 11404:1996 set aggregated datatype. The Name attribute of the ItemUnit owned by the SetType can be omitted. The datatype of the element type is represented by the type attribute of the ItemUnit owned by the SetType.

SequenceType class

SequenceType class is a meta-model element that represents sequence types in existing software systems: the user-defined datatypes, whose values are ordered sequences of values from the element datatype. The ordering is imposed on the values and not intrinsic in the element datatype; the same value may occur more than once in a given sequence.

Superclass

DerivedType

Semantics

SequenceType corresponds to ISO/IEC 11404:1996 sequence aggregated datatype. The Name attribute of the ItemUnit owned by the SequenceType can be omitted. The datatype of the element type is represented by the type attribute of the ItemUnit owned by the SequenceType.

Signature Class Diagram

The Signature class diagram defines meta-model elements which represent the signature concept common to various programming languages. The classes and associations of the Signature diagram are shown in See – Signature Class Diagram..

– Signature Class Diagram

Signature Class

The Signature is a meta-model element which represents the concept of a procedure signature which is common to various programming languages.

Superclass

Datatype

Associations

parameterUnit:ParameterUnit[0..*]

The list of parameters of the current Signature.

Constraints

Semantics

A Signature meta-model element has a dual role in KDM models. First, it corresponds to a procedure-type family of datatypes, corresponding to the procedure-type of ISO/IEC 11404 standard. Second, it corresponds to a specific data element as part of a computational object represented by a ControlElement. In this second sense, the Signature element corresponds to the mechanism of formal and actual parameters.

ParameterKind enumeration datatype

ParameterKind datatype defines the kind of parameter passing conventions.

Literals

byValue	parameter is passed by value
byName	parameter is passed by name
byReference	parameter is passed by reference
variadic	parameter is variadic
return	this is a return parameter
throws	parameter represents an exception thrown by the procedure
exception	parameter to a catch block
catchall	special parameter to a catch block
unknown	the parameter passing convention is unknown

Semantics

If the parameter kind is omitted then the corresponding parameter is passed byValue. Return parameter is only distinguished by the parameter kind return value. If no parameters of a Signature have parameter kind value return, this means that the Signature does not define a return value.

DefinedTypes Class Diagram

DefinedTypes class diagram defines meta-model constructs to represent defined datatypes (datatypes defined by a type declaration). The capability of defining new type identifiers is supported in many programming languages.

The classes and associations involved in the definition of KDM DefinedTypes are shown in See – DefinedTypes Class Diagram..

– DefinedTypes Class Diagram

DefinedType Class (abstract)

The DefinedType class is an abstract class that defines the common properties of several concrete classes that are used to represent type declarations in existing software systems.

Superclass

Datatype

Associations

codeElement:Datatype[0..*]	anonymous datatypes used in the definition of the datatype
type:Datatype[1]	the datatype of the DefinedType, that describes the values of the corresponding datatype

Semantics

DefinedType element represents a named element of existing software system which corresponds to a user-defined datatype.

TypeUnit class

The TypeUnit meta-model element represents the so-called new datatype declarations. New datatype declarations define the value-space of a new datatype, which is distinct from any other datatype.

Superclass

DefinedType

Semantics

TypeUnit corresponds to ISO/IEC 11404:1996 New datatype declaration and New generator declarations.

SynonymUnit class

The Synonym meta-model element represents the so-called renaming declarations. Renaming declarations declare the type name to be a synonym for another datatype.

Superclass

DefinedType

Semantics

SynonymUnit corresponds to ISO/IEC 11404:1996 Renaming declarations.

ClassTypes Class Diagram

The ClassTypes class diagram defines meta-model elements that represent common composite datatypes provided by various programming languages. The classes and association of the ClassTypes diagram are shown in See – ClassTypes Class Diagram..

– ClassTypes Class Diagram

ClassUnit Class

The ClassUnit is a meta-model element that represents user-defined classes in object-oriented languages. A class datatype is a named datatype that represents a class: an ordered collection of named elements, each of which can be another CodeItem, such as a MemberUnit or a MethodUnit.

Superclass

Datatype

Attributes

isAbstract:Boolean

The indicator of an abstract class.

Associations

codeElement:CodeItem[0..*]{ordered}

The list of class members

Constraints

Semantics

ClassUnit is a named container for an ordered collection of named elements, each of which can be another CodeItem, such as a MemberUnit or a MethodUnit. Program elements owned by a ClassUnit may also include other (nested ClassUnits), internal datatype definitions, etc. From the runtime perspective, ClassUnit represents a family of computational objects, called class instances. MemberUnits and MethodUnits of a certain ClassUnit are identified both by the name of the member or method, as well as by a direct or indirect identification of the corresponding class instance.

InterfaceUnit Class

The InterfaceUnit is a meta-model element which represents the interface concept common to various programming languages.

In the meta-model InterfaceUnit is a subclass of Datatype. InterfaceUnit is a KDM container. InterfaceUnit owns a list of code items which represent data types as well as MethodUnits or CallableUnits. MethodUnit elements owned by an InterfaceUnit may be targets of Calls relations.

Superclass

Datatype

Associations

codeElement:CodeItem[0..*] {ordered}

The list of TypeElements which correspond with the target Interface.

Constraints

Semantics

InterfaceUnit is a logical container for code items. InterfaceUnit corresponds to a compile time descriptions of the capabilities, that can be implemented by computational objects. InterfaceUnit owns datatype definitions as well as ControlElements, which in the representation of an existing software may be the targets of certain relationships, since the binding between the interface and the actual computational objects may occur at runtime.

Templates Class Diagram

The Templates class diagram provide basic meta-model constructs to define templates, parameters, instantiations of template and their relationships. See – Templates Class Diagram. shows these classes and their associations.

– Templates Class Diagram

TemplateUnit Class

The TemplateUnit is a meta-model element that represents parameterized datatypes, common to some programming languages, for example, Ada generics, Java generics, C++ templates.

Superclass

Datatype

Associations

codeElement:CodeItem[1]

template formal parameters and the base datatype or computational object

Constraints

TemplateParameter should be first in the list of code element owned by the TemplateUnit

Semantics

The TemplateUnit class corresponds to a type declaration with formal type parameters from the ISO/IEC 11404. TemplateUnit owns the corresponding datatype definition. Formal type parameters are represented by TemplateParameter elements owned by the TemplateUnit.

TemplateParameter Class

TemplateParameter is a meta-model element that represents parameters of a TemplateUnit. In the meta-model, TemplateParameter is a subclass of TypeElement.

Superclass

Datatype

Constraints

Semantics

TemplateParameter represents a formal parameter of a type declaration with formal parameters (corresponding to ISO/IEC 11404). TemplateParameter are owned directly by a certain TemplateUnit. Correspondence between actual and formal parameters is positional.

TemplateType class

TemplateType class is a meta-model element that represents references to parameterized datatypes. The TemplateType class owns the actual parameters to the datatype reference, represented by “ParameterTo” relationships. The TemplateType class also owns the “InstanceOf” relationship to the TemplateUnit that represents the referenced parameterized datatype. TemplateType has the role of a Datatype.

Superclass

Datatype

Constraints:

TemplateType class should be the origin only to template relations “InstanceOf” and “ParameterTo”

Semantics:

The TemplateType class corresponds to a type-reference with actual type parameters to a type declaration with formal type parameters from the ISO/IEC 11404. The type declaration with formal parameters is represented by a TemplateUnit, which ones the corresponding datatype definition. Formal type parameters are represented by TemplateParameter elements owned by the TemplateUnit. The association between the type reference and the type declaration is represented by the “InstanceOf” relationship.

Relationship “ParameterTo” represents the actual type parameter. The association between the actual and formal type parameters is positional.

TemplateRelations Class Diagram

The TemplateRelations class diagram defines KDM relationships that are related to the concept of an template. See – InterfaceRelations Class Diagram. shows these classes and their associations.

– TemplateRelations Class Diagram

InstanceOf Class

The InstanceOf is a meta-model element that represents “instantiation” relation between a AbstractCodeElement (for example, a ClassUnit) and a TemplateUnit. In the meta-model InstanceOf is a subclass of AbstractCodeRelationship.

Superclass

AbstractCodeRelationship

Associations

from:AbstractCodeElement[1]	The AbstractCodeElement which represents the instantiation of a template.
to:TemplateUnit[1]	The TemplateUnit which is being instantiated.

Constraints

The to- and from- endpoints of the relationship should be different

Semantics

InstanceOf relationship represents an association between a reference to a parameterized datatype or a parameterized entity (for example, a generic method), to the corresponding declaration of the parametrized class.

ParameterTo Class

The ParameterTo is a meta-model element that represents an actual type parameter in the context of a reference to a parameterized entity. ParameterTo is “parametrization” relation between an AbstractCodeElement (for example, a TemplateType or an ActionElement) and a CodeItem.

Superclass

AbstractCodeRelationship

Associations

from:AbstractCodeElement[1]	the reference to the parameterized entity (the context of the actual type parameter)
to:CodeItem[1]	actual parameter to template instantiation.

Constraints

ParameterTo relationship should be owned only by TemplateType or ActionElement

The to- and from- endpoints of the relationship should be different

Semantics

Reference to a parameterized datatype is represented by a TemplateType element. Another situation is an ActionElement that references a parameterized entity, for example a call to a generic method. In this situation the ActionElement provides the context of the reference and owns the ParameterTo and InstanceOf relationships.

Example (Java):

class foo {

static <T> void fromArrayToCollection(T[] a, Collection<T> c) {

for (T o : a) {

c.add(o);

}

}

void demo() {

String[] sa = new String[100];

Collection<String> cs = new ArrayList<String>();

fromArrayToCollection(sa, cs);// T inferred to be String

}

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

<kdm:Segment xmi:version="2.1"

xmlns:xmi="http://www.omg.org/XMI"

xmlns:action="http://kdm.omg.org/action"

xmlns:code="http://kdm.omg.org/code"

xmlns:kdm="http://kdm.omg.org/kdm" name="Template Example">

<model xmi:id="id.0" xmi:type="code:CodeModel">

<codeElement xmi:id="id.1" xmi:type="code:ClassUnit" name="foo">

<codeElement xmi:id="id.2" xmi:type="code:TemplateUnit"

name="fromArrayToCollection&lt;T>">

<codeElement xmi:id="id.3" xmi:type="code:TemplateParameter" name="T"/>

<codeElement xmi:id="id.4" xmi:type="code:MethodUnit"

name="fromArrayToCollection" type="id.6">

<entryFlow xmi:id="id.5" to="id.14" from="id.4"/>

<codeElement xmi:id="id.6" xmi:type="code:Signature">

<parameterUnit xmi:id="id.7" name="a">

<codeElement xmi:id="id.8" xmi:type="code:ArrayType">

<itemUnit xmi:id="id.9" type="id.3"/>

</codeElement>

</parameterUnit>

<parameterUnit xmi:id="id.10" name="c" type="id.11">

<codeElement xmi:id="id.11" xmi:type="code:TemplateType"

name="Collection&lt;T1>">

<codeRelation xmi:id="id.12" xmi:type="code:ParameterTo"

to="id.3" from="id.11"/>

<codeRelation xmi:id="id.13" xmi:type="code:InstanceOf"

to="id.75" from="id.11"/>

</codeElement>

</parameterUnit>

</codeElement>

<codeElement xmi:id="id.14" xmi:type="action:ActionElement"

name="a1" kind="Compound">

<codeElement xmi:id="id.15" xmi:type="action:ActionElement"

name="a1.1" kind="Call">

<actionRelation xmi:id="id.16" xmi:type="action:Addresses"

to="id.7" from="id.15"/>

<actionRelation xmi:id="id.17" xmi:type="action:Calls" to="id.81" from="id.15"/>

<actionRelation xmi:id="id.18" xmi:type="action:Flow" to="id.19" from="id.15"/>

</codeElement>

<codeElement xmi:id="id.19" xmi:type="action:ActionElement"

name="a1.2" kind="Call">

<codeElement xmi:id="id.20" xmi:type="code:StorableUnit"

name="t1" type="id.88" kind="register"/>

<actionRelation xmi:id="id.21" xmi:type="action:Addresses"

to="id.40" from="id.19"/>

<actionRelation xmi:id="id.22" xmi:type="action:Calls" to="id.83" from="id.19"/>

<actionRelation xmi:id="id.23" xmi:type="action:Writes" to="id.20" from="id.29"/>

<actionRelation xmi:id="id.24" xmi:type="action:Flow" to="id.25" from="id.19"/>

</codeElement>

<codeElement xmi:id="id.25" xmi:type="action:ActionElement"

name="1.3" kind="Condition">

<actionRelation xmi:id="id.26" xmi:type="action:Reads" to="id.20" from="id.25"/>

<actionRelation xmi:id="id.27" xmi:type="action:TrueFlow"

to="id.29" from="id.25"/>

<actionRelation xmi:id="id.28" xmi:type="action:FalseFlow"

to="id.39" from="id.25"/>

</codeElement>

<codeElement xmi:id="id.29" xmi:type="action:ActionElement"

name="a1.4" kind="Call">

<actionRelation xmi:id="id.30" xmi:type="action:Addresses"

to="id.40" from="id.29"/>

<actionRelation xmi:id="id.31" xmi:type="action:Calls" to="id.82" from="id.29"/>

<actionRelation xmi:id="id.32" xmi:type="action:Writes" to="id.44" from="id.29"/>

<actionRelation xmi:id="id.33" xmi:type="action:Flow" to="id.34" from="id.29"/>

</codeElement>

<codeElement xmi:id="id.34" xmi:type="action:ActionElement"

name="a1.5" kind="Call">

<actionRelation xmi:id="id.35" xmi:type="action:Addresses"

to="id.10" from="id.34"/>

<actionRelation xmi:id="id.36" xmi:type="action:Reads" to="id.44" from="id.34"/>

<actionRelation xmi:id="id.37" xmi:type="action:Calls" to="id.84" from="id.34"/>

<actionRelation xmi:id="id.38" xmi:type="action:Flow" to="id.19" from="id.34"/>

</codeElement>

<codeElement xmi:id="id.39" xmi:type="action:ActionElement" name="1.6" kind="Nop"/>

<codeElement xmi:id="id.40" xmi:type="code:StorableUnit"

name="iter" type="id.41" kind="register">

<codeElement xmi:id="id.41" xmi:type="code:TemplateType" name="Iterator&lt;T1>">

<codeRelation xmi:id="id.42" xmi:type="code:InstanceOf"

to="id.78" from="id.41"/>

<codeRelation xmi:id="id.43" xmi:type="code:ParameterTo"

to="id.3" from="id.41"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.44" xmi:type="code:StorableUnit"

name="o" type="id.3" kind="local"/>

<actionRelation xmi:id="id.45" xmi:type="action:Flow" to="id.15" from="id.14"/>

</codeElement>

</codeElement>

</codeElement>

<codeElement xmi:id="id.46" xmi:type="code:MethodUnit" name="demo" type="id.47">

<codeElement xmi:id="id.47" xmi:type="code:Signature"/>

<codeElement xmi:id="id.48" xmi:type="code:StorableUnit"

name="sa" type="id.49" kind="local">

<codeElement xmi:id="id.49" xmi:type="code:ArrayType" name="ar2">

<itemUnit xmi:id="id.50" type="id.89"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.51" xmi:type="action:ActionElement" name="demo.1" kind="New">

<codeElement xmi:id="id.52" xmi:type="code:Value" name="100" type="id.90"/>

<actionRelation xmi:id="id.53" xmi:type="action:Reads" to="id.52" from="id.51"/>

<actionRelation xmi:id="id.54" xmi:type="action:Creates" to="id.49" from="id.51"/>

<actionRelation xmi:id="id.55" xmi:type="action:Writes" to="id.48" from="id.51"/>

<actionRelation xmi:id="id.56" xmi:type="action:Flow"/>

</codeElement>

<codeElement xmi:id="id.57" xmi:type="code:StorableUnit"

name="cs" type="id.58" kind="local">

<codeElement xmi:id="id.58" xmi:type="code:TemplateType"

name="Collection&lt;String>">

<codeRelation xmi:id="id.59" xmi:type="code:ParameterTo" to="id.89" from="id.58"/>

<codeRelation xmi:id="id.60" xmi:type="code:InstanceOf" to="id.75" from="id.58"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.61" xmi:type="action:ActionElement" name="demo.2" kind="New">

<codeElement xmi:id="id.62" xmi:type="code:TemplateType"

name="ArrayList&lt;String>">

<codeRelation xmi:id="id.63" xmi:type="code:ParameterTo" to="id.89" from="id.62"/>

<codeRelation xmi:id="id.64" xmi:type="code:InstanceOf" to="id.85" from="id.62"/>

</codeElement>

<actionRelation xmi:id="id.65" xmi:type="action:Creates" to="id.62" from="id.51"/>

<actionRelation xmi:id="id.66" xmi:type="action:Writes" to="id.57" from="id.61"/>

<actionRelation xmi:id="id.67" xmi:type="action:Flow"/>

</codeElement>

<codeElement xmi:id="id.68" xmi:type="action:ActionElement" name="demo.3" kind="Call">

<codeRelation xmi:id="id.69" xmi:type="code:InstanceOf" to="id.2" from="id.68"/>

<codeRelation xmi:id="id.70" xmi:type="code:ParameterTo" to="id.89" from="id.68"/>

<actionRelation xmi:id="id.71" xmi:type="action:Reads" to="id.48" from="id.68"/>

<actionRelation xmi:id="id.72" xmi:type="action:Reads" to="id.57" from="id.68"/>

<actionRelation xmi:id="id.73" xmi:type="action:Calls" to="id.4" from="id.68"/>

</codeElement>

</codeElement>

</codeElement>

<codeElement xmi:id="id.74" xmi:type="code:LanguageUnit" name="Common Java datatypes">

<codeElement xmi:id="id.75" xmi:type="code:TemplateUnit" name="Collection&lt;T>">

<codeElement xmi:id="id.76" xmi:type="code:TemplateParameter" name="T"/>

<codeElement xmi:id="id.77" xmi:type="code:ClassUnit" name="Collection"/>

</codeElement>

<codeElement xmi:id="id.78" xmi:type="code:TemplateUnit" name="Iterator&lt;T>">

<codeElement xmi:id="id.79" xmi:type="code:TemplateParameter" name="T"/>

<codeElement xmi:id="id.80" xmi:type="code:ClassUnit" name="Iterator">

<codeElement xmi:id="id.81" xmi:type="code:MethodUnit"

name="iterator" kind="constructor"/>

<codeElement xmi:id="id.82" xmi:type="code:MethodUnit" name="next"/>

<codeElement xmi:id="id.83" xmi:type="code:MethodUnit" name="hasNext"/>

<codeElement xmi:id="id.84" xmi:type="code:MethodUnit" name="add"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.85" xmi:type="code:TemplateUnit" name="ArrayList&lt;T>">

<codeElement xmi:id="id.86" xmi:type="code:TemplateParameter" name="T"/>

<codeElement xmi:id="id.87" xmi:type="code:ClassUnit" name="ArrayList"/>

</codeElement>

<codeElement xmi:id="id.88" xmi:type="code:BooleanType" name="Boolean"/>

<codeElement xmi:id="id.89" xmi:type="code:StringType" name="String"/>

<codeElement xmi:id="id.90" xmi:type="code:IntegerType" name="Integer"/>

</codeElement>

</model>

</kdm:Segment>

InterfaceRelations Class Diagram

The InterfaceRelations class diagram defines KDM relationships that represent the usages of an “declarations” by the corresponding “definition” code elements. The classes and associations of the InterfaceRelations diagram are shown in See – InterfaceRelations Class Diagram..

– InterfaceRelations Class Diagram

Implements Class

The Implements is a meta-model element that represents “implementation” association between a CodeItem (for example, a ClassUnit) and an InterfaceUnit. “Implements” relationship is similar to “Extends”. For example, Java “implements” construct can be represented by KDM “Implements” relationship.

Superclass

AbstractCodeRelationship

Associations

from:CodeItem[1]	The CodeItem which implements a certain InterfaceUnit.
to:CodeItem[1]	The InterfaceUnit which is being implemented by CodeItem.

Constraints

The from- and to- endpoints should be different

Semantics

see next section

ImplementationOf Class

The ImplementationOf is a meta-model element that represents “implementation” association between a CodeItem (for example, a MethodUnit) and a particular “external” entity, for example a MethodUnit owned by an InterfaceUnit. “ImplementationOf” relationship represents associations between a declaration and a definition of a computation object, common to various programming languages. While the “Implements” relationship is between entire containers (the target is an InterfaceUnit), the “ImplementationOf” relationship represents a broader range of situations:

particular MethodUnit of a ClassUnit that “Implements” an InterfaceUnit, is an “ImplementationOf” a particular MethodUnit, owned by that InterfaceUnit
a CallableUnit may be an “ImplementationOf” a CallableUnit with kind external, which represents the declaration (the prototype) of that CallableUnit.
a StorableUnit may be an “ImplementationOf” a StorableUnit with kind external, which represents the external declaration of the StorableUnit, such as, for example, the “extern” construct in the C language.

Superclass

AbstractCodeRelationship

Associations

from:CodeItem[1]	CodeItem which implements a certain “declaration”.
to:CodeItem[1]	“declaration” which is being implemented by the CodeItem.

Constraints

It is obligatory that either the origin of the ImplementationOf relationship is a ControlElement, and the target of the is a ControlElement or the origin is a DataElement and the target is a DataElement.

The kind attribute of the CodeItem at the origin of the ImplementationOf relationship should not be equal to “external”
The kind attribute of the CodeItem at the target of the ImplementationOf relationship should be equal to “external” or “abstract”
The from- and to- endpoints should be different

Semantics

A “declaration” entity may be represented in KDM as a ComputationalObject (ControlElement or DataElement) with kind “external” or “abstract”. Kind “abstract” is used for the members of the InterfaceUnit. In case of a ControlElement, Signature represents the procedure type, but not the declaration entity itself.

If both the definition and the declaration of some computational object “foo” are available:

the definition of “foo” may be the origin of the ImplementationOf relationship to the declaration of “foo”
for a certain action element that uses “foo” the target of the KDM callable or data relations will be the definition of “foo”,
the action element that uses “foo” may be the origin of a “CompliesTo” action relationship (defined at the InterfaceRelations class diagram of the Action package) to the declaration of “foo”.

If only the declaration of some computational object “bar” is available in the given context of capturing knowledge about the existing software system:

for a certain action element that uses “bar” the target of the KDM callable or data relations will be the declaration of “bar”,
the action element that uses “bar” may be the origin of a “CompliesTo” action relationship (defined at the InterfaceRelations class diagram of the Action package) to the declaration of “bar”.

Declaration elements are usually owned by a certain SharedUnit.

In case of complex engineering process which involves multiple shared units, that are included into compilation units in complex ways, existing software system may have multiple declarations for the same computational object, or even different computational objects with same name but different properties, that are used in different contexts. In this situation the above KDM mechanism that involves three relationships (the “real” usage, the “ImplementationOf” and the “CompliesTo” relationships) can be used to detect subtle maintenance issues, for example, when for the same action element the target of the “ImplementationOf” relationship originating from the target of the “real” usage relationship, if different from the target of the “CompliesTo” relationship, originating from the action element itself.

Example (Java):

package flip;

public interface iFlip {

public int flip(int i);

}



package flip;

public class foo implements iFlip {

public foo(){}

public flip(int i) {

return i * -1;

}

}



package flip;

public class FlipClient {

public static void main(String[] args) {

foo f= new foo();

iFlip g=(iFlip) f;

f.flip(100);

}

}

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

<kdm:Segment xmi:version="2.1"

xmlns:xmi="http://www.omg.org/XMI"

xmlns:action="http://kdm.omg.org/action"

xmlns:code="http://kdm.omg.org/code"

xmlns:kdm="http://kdm.omg.org/kdm" name="Interface Example">

<model xmi:id="id.0" xmi:type="code:CodeModel">

<codeElement xmi:id="id.1" xmi:type="code:Package" name="flip">

<codeElement xmi:id="id.2" xmi:type="code:ClassUnit" name="foo">

<codeRelation xmi:id="id.3" xmi:type="code:Implements" to="id.21" from="id.2"/>

<codeElement xmi:id="id.4" xmi:type="code:MethodUnit" name="flip" type="id.23">

<codeRelation xmi:id="id.5" xmi:type="code:ImplementationOf"

to="id.22" from="id.4"/>

<entryFlow xmi:id="id.6" to="id.10" from="id.4"/>

<codeElement xmi:id="id.7" xmi:type="code:Signature" name="flip">

<parameterUnit xmi:id="id.8" name="i" type="id.53"/>

<parameterUnit xmi:id="id.9" type="id.53" kind="return"/>

</codeElement>

<codeElement xmi:id="id.10" xmi:type="action:ActionElement"

name="d1" kind="Multiply">

<codeElement xmi:id="id.11" xmi:type="code:Value" name="-1" type="id.53"/>

<codeElement xmi:id="id.12" xmi:type="code:StorableUnit"

name="t5" type="id.53" kind="register"/>

<actionRelation xmi:id="id.13" xmi:type="action:Reads" to="id.8" from="id.10"/>

<actionRelation xmi:id="id.14" xmi:type="action:Reads" to="id.11" from="id.10"/>

<actionRelation xmi:id="id.15" xmi:type="action:Writes" to="id.12" from="id.10"/>

<actionRelation xmi:id="id.16" xmi:type="action:Flow" to="id.17" from="id.10"/>

</codeElement>

<codeElement xmi:id="id.17" xmi:type="action:ActionElement" name="d2" kind="Return">

<actionRelation xmi:id="id.18" xmi:type="action:Reads" to="id.12" from="id.17"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.19" xmi:type="code:MethodUnit"

name="foo" type="id.20" kind="constructor">

<codeElement xmi:id="id.20" xmi:type="code:Signature" name="foo"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.21" xmi:type="code:InterfaceUnit" name="IFlip">

<codeElement xmi:id="id.22" xmi:type="code:MethodUnit"

name="flip" type="id.23" kind="abstract"/>

<codeElement xmi:id="id.23" xmi:type="code:Signature" name="flip">

<parameterUnit xmi:id="id.24" name="i" type="id.53" pos="1"/>

<parameterUnit xmi:id="id.25" type="id.53" kind="return" pos="0"/>

</codeElement>

</codeElement>

<codeElement xmi:id="id.26" xmi:type="code:ClassUnit" name="Flipclient">

<codeElement xmi:id="id.27" xmi:type="code:MethodUnit" name="main" type="id.29">

<entryFlow xmi:id="id.28" to="id.35" from="id.27"/>

<codeElement xmi:id="id.29" xmi:type="code:Signature" name="main">

<parameterUnit xmi:id="id.30" name="args" type="id.31" pos="1">

<codeElement xmi:id="id.31" xmi:type="code:ArrayType">

<itemUnit xmi:id="id.32" name="args[]" type="id.54"/>

</codeElement>

</parameterUnit>

</codeElement>

<codeElement xmi:id="id.33" xmi:type="code:StorableUnit"

name="f" type="id.2" kind="local"/>

<codeElement xmi:id="id.34" xmi:type="code:StorableUnit"

name="g" type="id.21" kind="local"/>

<codeElement xmi:id="id.35" xmi:type="action:ActionElement" name="a1" kind="New">

<actionRelation xmi:id="id.36" xmi:type="action:Creates" to="id.2" from="id.35"/>

<actionRelation xmi:id="id.37" xmi:type="action:Writes" to="id.33" from="id.35"/>

<actionRelation xmi:id="id.38" xmi:type="action:Flow" to="id.39" from="id.35"/>

</codeElement>

<codeElement xmi:id="id.39" xmi:type="action:ActionElement"

name="a2" kind="MethodCall">

<actionRelation xmi:id="id.40" xmi:type="action:CompliesTo"

to="id.20" from="id.39"/>

<actionRelation xmi:id="id.41" xmi:type="action:Addresses"

to="id.33" from="id.39"/>

<actionRelation xmi:id="id.42" xmi:type="action:Calls" to="id.19" from="id.39"/>

<actionRelation xmi:id="id.43" xmi:type="action:Flow" to="id.44" from="id.39"/>

</codeElement>

<codeElement xmi:id="id.44" xmi:type="action:ActionElement"

name="a3" kind="DynCast">

<actionRelation xmi:id="id.45" xmi:type="action:Reads" to="id.33" from="id.44"/>

<actionRelation xmi:id="id.46" xmi:type="action:UsesType" to="id.21" from="id.44"/>

<actionRelation xmi:id="id.47" xmi:type="action:Writes" to="id.34" from="id.44"/>

<actionRelation xmi:id="id.48" xmi:type="action:Flow" to="id.49" from="id.44"/>

</codeElement>

<codeElement xmi:id="id.49" xmi:type="action:ActionElement"

name="a4" kind="InterfaceCall">

<actionRelation xmi:id="id.50" xmi:type="action:CompliesTo"

to="id.23" from="id.49"/>

<actionRelation xmi:id="id.51" xmi:type="action:Addresses"

to="id.34" from="id.49"/>

<actionRelation xmi:id="id.52" xmi:type="action:Calls" to="id.22" from="id.49"/>

</codeElement>

</codeElement>

</codeElement>

</codeElement>

<codeElement xmi:id="id.53" xmi:type="code:IntegerType" name="int"/>

<codeElement xmi:id="id.54" xmi:type="code:StringType" name="String"/>

</model>

</kdm:Segment>

TypeRelations Class Diagram

The TypeRelations class diagram defines meta-model elements that represent semantic associations between datatypes and data elements. The classes and associations of the TypeRelations diagram are shown in See – TypeRelations Class Diagram..

– TypeRelations Class Diagram

HasType Class

The HasType is a specific meta-model element that represents semantic relation between a data element and the corresponding type element.

Superclass

AbstractCodeRelationship

Associations

from:CodeItem[1]	The source data element.
to:Datatype[1]	The target datatype element.

Constraints

The from- and to- endpoints should be different

Semantics

HasType relationship represents an association between a code item which uses a certain user-defined type, and that datatype. Each data element has a direct association to its datatype. HasType relationship duplicates this information if the datatype is a named user-defined datatype (rather than an anonymous datatype or a primitive datatype) which allows a uniform representation of this information as a KDM relationship. In particular, this relationship can then by used in AggregatedRelationships.

HasValue Class

The HasValue is a specific meta-model element that represents semantic relation between a data element and its initialization data element.

Superclass

AbstractCodeRelationship

Associations

from:CodeItem[1]	The source data element.
to:Datatype[1]	The target datatype element.

Constraints

Semantics

HasValue relationship as an optional way to represent initialization. In micro KDM that it should have explicit initialization actions.

Example (C++):


/*----d.h---*/
class D {
private: int num;
public:
D(int x) { this->num=x; printf("Hello, this is %d\n", x); }
work() { printf("This is %d working\n", this->num);
};
/*---a.cpp---*/
#include "d.h"
int g1=0;
D d1(1);

/*---b.cpp--*/
#include "d.h"
extern D d1;
D d2(2);
main() {
int l2=0;
D * d3=new D(3);
d1.work();
d2.work();
d3->work();
}

<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment xmi:version="2.1"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:action="http://kdm.omg.org/action"
xmlns:code="http://kdm.omg.org/code"
xmlns:kdm="http://kdm.omg.org/kdm" name="ClassD Example">
<model xmi:id="id.0" xmi:type="code:CodeModel">
<codeElement xmi:id="id.1" xmi:type="code:CodeAssembly">
<codeElement xmi:id="id.2" xmi:type="code:CompilationUnit" name="a.cpp">
<codeElement xmi:id="id.3" xmi:type="code:IncludeDirective" name="imp1">
<codeRelation xmi:id="id.4" xmi:type="code:Includes" to="id.22" from="id.3"/>
</codeElement>
<codeElement xmi:id="id.5" xmi:type="code:StorableUnit" name="g1" type="id.105">
<codeRelation xmi:id="id.6" xmi:type="code:HasValue" to="id.20" from="id.5"/>
</codeElement>
<codeElement xmi:id="id.7" xmi:type="code:StorableUnit" name="d1" type="id.23">
<codeRelation xmi:id="id.8" xmi:type="code:HasType" to="id.23" from="id.7"/>
<codeRelation xmi:id="id.9" xmi:type="code:ImplementationOf"
to="id.47" from="id.7"/>
</codeElement>
<codeElement xmi:id="id.10" xmi:type="code:CallableUnit" name="bi1">
<entryFlow xmi:id="id.11" to="id.12" from="id.10"/>
<codeElement xmi:id="id.12" xmi:type="action:ActionElement" name="i1" kind="Assign">
<actionRelation xmi:id="id.13" xmi:type="action:Reads" to="id.20" from="id.12"/>
<actionRelation xmi:id="id.14" xmi:type="action:Writes" to="id.5" from="id.12"/>
<actionRelation xmi:id="id.15" xmi:type="action:Flow" to="id.16" from="id.12"/>
</codeElement>
<codeElement xmi:id="id.16" xmi:type="action:ActionElement" name="i2" kind="Calls">
<actionRelation xmi:id="id.17" xmi:type="action:Reads" to="id.21" from="id.16"/>
<actionRelation xmi:id="id.18" xmi:type="action:Calls" to="id.25" from="id.16"/>
<actionRelation xmi:id="id.19" xmi:type="action:Writes" to="id.7" from="id.16"/>
</codeElement>
<codeElement xmi:id="id.20" xmi:type="code:Value" name="0"/>
<codeElement xmi:id="id.21" xmi:type="code:Value" name="1"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.22" xmi:type="code:SharedUnit" name="d.h">
<codeElement xmi:id="id.23" xmi:type="code:ClassUnit" name="D">
<codeElement xmi:id="id.24" xmi:type="code:MemberUnit"
name="num" type="id.105" export="private"/>
<codeElement xmi:id="id.25" xmi:type="code:MethodUnit" name="D">
<entryFlow xmi:id="id.26" to="id.28" from="id.25"/>
<codeElement xmi:id="id.27" xmi:type="code:Value"
name="&quot;Hello, this is %d\n&quot;" type="id.111"/>
<codeElement xmi:id="id.28" xmi:type="action:ActionElement"
name="a4" kind="Assign">
<actionRelation xmi:id="id.29" xmi:type="action:Reads" to="id.37" from="id.28"/>
<actionRelation xmi:id="id.30" xmi:type="action:Writes" to="id.24" from="id.28"/>
<actionRelation xmi:id="id.31" xmi:type="action:Flow" to="id.32" from="id.28"/>
</codeElement>
<codeElement xmi:id="id.32" xmi:type="action:ActionElement" name="a5" kind="Call">
<actionRelation xmi:id="id.33" xmi:type="action:Reads" to="id.27" from="id.32"/>
<actionRelation xmi:id="id.34" xmi:type="action:Reads" to="id.37" from="id.32"/>
<actionRelation xmi:id="id.35" xmi:type="action:Calls" to="id.106" from="id.32"/>
</codeElement>
<codeElement xmi:id="id.36" xmi:type="code:Signature" name="D">
<parameterUnit xmi:id="id.37" name="x" pos="1"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.38" xmi:type="code:MethodUnit" name="work">
<codeElement xmi:id="id.39" xmi:type="code:Value"
name="&quot;This is %d working\n&quot;"/>
<codeElement xmi:id="id.40" xmi:type="action:ActionElement" name="a6" kind="Call">
<actionRelation xmi:id="id.41" xmi:type="action:Reads" to="id.39" from="id.40"/>
<actionRelation xmi:id="id.42" xmi:type="action:Reads" to="id.24" from="id.40"/>
<actionRelation xmi:id="id.43" xmi:type="action:Calls" to="id.106" from="id.40"/>
</codeElement>
</codeElement>
</codeElement>
</codeElement>
<codeElement xmi:id="id.44" xmi:type="code:CompilationUnit" name="b.cpp">
<codeElement xmi:id="id.45" xmi:type="code:IncludeDirective" name="imp2">
<codeRelation xmi:id="id.46" xmi:type="code:Includes" to="id.22" from="id.45"/>
</codeElement>
<codeElement xmi:id="id.47" xmi:type="code:StorableUnit"
name="extern d1" kind="external"/>
<codeElement xmi:id="id.48" xmi:type="code:CallableUnit" name="main">
<entryFlow xmi:id="id.49" to="id.70" from="id.48"/>
<codeElement xmi:id="id.50" xmi:type="code:StorableUnit" name="l2" type="id.105">
<codeRelation xmi:id="id.51" xmi:type="code:HasValue" to="id.20" from="id.50"/>
</codeElement>
<codeElement xmi:id="id.52" xmi:type="code:StorableUnit" name="d2">
<codeRelation xmi:id="id.53" xmi:type="code:HasType" to="id.23" from="id.52"/>
</codeElement>
<codeElement xmi:id="id.54" xmi:type="code:StorableUnit" name="d3" type="id.55">
<codeElement xmi:id="id.55" xmi:type="code:PointerType">
<itemUnit xmi:id="id.56" type="id.23">
<codeRelation xmi:id="id.57" xmi:type="code:HasType" to="id.23" from="id.56"/>
</itemUnit>
</codeElement>
</codeElement>
<codeElement xmi:id="id.58" xmi:type="action:ActionElement" name="a1" kind="Call">
<actionRelation xmi:id="id.59" xmi:type="action:Calls" to="id.38" from="id.58"/>
<actionRelation xmi:id="id.60" xmi:type="action:Addresses" to="id.7" from="id.58"/>
<actionRelation xmi:id="id.61" xmi:type="action:CompliesTo"
to="id.47" from="id.58"/>
<actionRelation xmi:id="id.62" xmi:type="action:Flow" to="id.63" from="id.58"/>
</codeElement>
<codeElement xmi:id="id.63" xmi:type="action:ActionElement" name="a2" kind="Call">
<actionRelation xmi:id="id.64" xmi:type="action:Calls" to="id.38" from="id.63"/>
<actionRelation xmi:id="id.65" xmi:type="action:Addresses"
to="id.52" from="id.63"/>
<actionRelation xmi:id="id.66" xmi:type="action:Flow" to="id.67" from="id.63"/>
</codeElement>
<codeElement xmi:id="id.67" xmi:type="action:ActionElement" name="a3" kind="Call">
<actionRelation xmi:id="id.68" xmi:type="action:Calls" to="id.38" from="id.67"/>
<actionRelation xmi:id="id.69" xmi:type="action:Addresses"
to="id.56" from="id.67"/>
</codeElement>
<codeElement xmi:id="id.70" xmi:type="action:BlockUnit" name="bi2">
<codeElement xmi:id="id.71" xmi:type="action:ActionElement"
name="i3" kind="Assign">
<actionRelation xmi:id="id.72" xmi:type="action:Reads" to="id.20" from="id.71"/>
<actionRelation xmi:id="id.73" xmi:type="action:Writes" to="id.50" from="id.71"/>
<actionRelation xmi:id="id.74" xmi:type="action:Flow" to="id.79" from="id.71"/>
</codeElement>
<codeElement xmi:id="id.75" xmi:type="action:ActionElement" name="i4" kind="New">
<actionRelation xmi:id="id.76" xmi:type="action:Creates"
to="id.23" from="id.75"/>
<actionRelation xmi:id="id.77" xmi:type="action:Writes" to="id.54" from="id.75"/>
<actionRelation xmi:id="id.78" xmi:type="action:Flow" to="id.79" from="id.75"/>
</codeElement>
<codeElement xmi:id="id.79" xmi:type="action:ActionElement"
name="i5" kind="MethodCall">
<actionRelation xmi:id="id.80" xmi:type="action:Reads" to="id.85" from="id.79"/>
<actionRelation xmi:id="id.81" xmi:type="action:Addresses"
to="id.54" from="id.79"/>
<actionRelation xmi:id="id.82" xmi:type="action:Calls" to="id.25" from="id.79"/>
<actionRelation xmi:id="id.83" xmi:type="action:Writes" to="id.56" from="id.79"/>
<actionRelation xmi:id="id.84" xmi:type="action:Flow" to="id.58" from="id.79"/>
</codeElement>
<codeElement xmi:id="id.85" xmi:type="code:Value" name="3"/>
<actionRelation xmi:id="id.86" xmi:type="action:Flow" to="id.71" from="id.70"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.87" xmi:type="code:CallableUnit" name="bi3">
<entryFlow xmi:id="id.88" to="id.89" from="id.87"/>
<codeElement xmi:id="id.89" xmi:type="action:ActionElement" name="i6" kind="Call">
<actionRelation xmi:id="id.90" xmi:type="action:Reads" to="id.93" from="id.89"/>
<actionRelation xmi:id="id.91" xmi:type="action:Calls" to="id.25" from="id.89"/>
<actionRelation xmi:id="id.92" xmi:type="action:Writes" to="id.52" from="id.89"/>
</codeElement>
<codeElement xmi:id="id.93" xmi:type="code:Value" name="2" type="id.105"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.94" xmi:type="code:CallableUnit" name="bi4" kind="unknown">
<entryFlow xmi:id="id.95" to="id.96" from="id.94"/>
<codeElement xmi:id="id.96" xmi:type="action:ActionElement" name="i7">
<actionRelation xmi:id="id.97" xmi:type="action:Calls" to="id.10" from="id.96"/>
<actionRelation xmi:id="id.98" xmi:type="action:Flow" to="id.99" from="id.96"/>
</codeElement>
<codeElement xmi:id="id.99" xmi:type="action:ActionElement" name="i8">
<actionRelation xmi:id="id.100" xmi:type="action:Calls" to="id.87" from="id.99"/>
<actionRelation xmi:id="id.101" xmi:type="action:Flow" to="id.102" from="id.96"/>
</codeElement>
<codeElement xmi:id="id.102" xmi:type="action:ActionElement" name="i9">
<actionRelation xmi:id="id.103" xmi:type="action:Calls" to="id.48" from="id.102"/>
</codeElement>
</codeElement>
</codeElement>
<codeElement xmi:id="id.104" xmi:type="code:LanguageUnit">
<codeElement xmi:id="id.105" xmi:type="code:IntegerType" name="int"/>
<codeElement xmi:id="id.106" xmi:type="code:CallableUnit" name="printf" type="id.107">
<codeElement xmi:id="id.107" xmi:type="code:Signature" name="printf">
<parameterUnit xmi:id="id.108" type="id.105" kind="return" pos="0"/>
<parameterUnit xmi:id="id.109" name="format" type="id.111" pos="1"/>
<parameterUnit xmi:id="id.110" name="arguments" type="id.112"
kind="variadic" pos="2"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.111" xmi:type="code:StringType" name="char *"/>
<codeElement xmi:id="id.112" xmi:type="code:VoidType"/>
</codeElement>
</model>
</kdm:Segment>

ClassRelations Class Diagram

The ClassRelations class diagram defines meta-model elements that represent semantic associations between datatypes. The classes and associations of the ClassRelations diagram are shown in See – ClassRelations Class Diagram..

– ClassRelations Class Diagram

Extends Class

The Extends is a specific meta-model element that represents semantic relation between two classes, where one class (called a “child” class) extends another class (called its “parent” class) through inheritance, common to object-oriented languages.

Superclass

AbstractCodeRelationship

Associations

from:Datatype[1]	The child Class
to:Datatype[1]	The parent Class

Constraints

The from- and to- endpoints should be different

Semantics

Extends relationship represents the associations between two datatypes in which the first datatype (called the “child” class) “subclasses” the second datatype (called the “parent” class) by inheriting the semantics and owned elements of the parent class.

A typical preprocessor allows the use of an embedded language in the source code written in some primary language. It is different than let’s say an HTML/Javascript program or programs with embedded assembler routines where there is more than one language but those don’t end up forming a modified version in a single language that is what gets compiled and executed (and that could be traced after, etc.). Example of the use of the preprocessor include Cobol copy replacing, Exec CICS, Exec SQL, 4GL user-defined language elements (such as MENTER macro/command in Dataflex).

The Exec SQL in Cobol example might be one of the best and easiest to look at. From a modeling/representation perspective the SQL statement itself is very much what we want to capture along with the various data elements and variable involved and their flow. However, an embedded SQL statement is expanded by the SQL pre-processor which generates some low-level code that will translate into a call to some library. By capturing this as generated code and correctly associating the elements, we can understand the program both from its SQL semantic, as well as from its execution realm. And our relationship between the “SQL language” elements to the “native” code elements that are generated is the glue tying things together. Trying to do the same analysis and operations by simply working with a couple of SourceRef would be very limiting indeed.

Preprocessor directive is a language/dialect on its own and it should be handled and treated as a first class citizen in KDM. However, the preprocessor support is an optional part of the code model, so that and the non-preprocessor-enabled L0 KDM tool can seamlessly ignore the embedded language and work only with the primary language. The implementer will have the choice to either: 1) represent the embedded language in KDM and ignore the primary code that results from expansion of some preprocessor directives (provided this can lead to a meaningful model); 2) ignore the embedded language and represent only the primary language in KDM; 3) represent both the embedded and the generated primary code and relations between the two. In order to achieve this goal, KDM modeling framework provides a strong separation between embedded language representation and primary language representation.

Preprocessor support in KDM allows conveying information that a certain code element appeared as the result of 1) being originally coded in the primary language; b) being included from another file by a preprocessor; c) being generated by a preprocessor as an expansion of an embedded language directive; d) being selected by satisfying appropriate conditions by the preprocessor.

KDM provides the following modeling elements for representing preprocessor directives:

PreprocessorDirective – representation of a generic preprocessor directive and a superclass for several other concrete preprocessor directives.
MacroUnit -representation of macro definitions
MacroDirective – representation of an embedded language construct as distinguishable from the primary language construct. This is also known as a Macro Call.
IncludeDirective – representation of an include directive of a preprocessor.
ConditionalDirective – representation of a pre-processor conditional branch

Preprocessor Class Diagram

The Preprocessor class diagram defines the meta-model elements to represent embedded language constructs and to support common modeling situations resulting from the use of a language preprocessor (for example, preprocessor defined as part of the C language, or the preprocessing capabilities of Cobol).

The class diagram in See – Preprocessor Class Diagram. shows these classes and their associations.

– Preprocessor Class Diagram

PreprocessorDirective Class (generic)

PreprocessorDirective is a generic meta-model element that represents preprocessor directives common to some programming languages (for example, the C language preprocessor capabilities). This class is extended by several concrete meta-model elements that represent several key directive types common to language preprocessors. KDM representations of existing systems are expected to use concrete subclasses of PreprocessorDirective, however this class itself is a concrete meta-model element and can be used as an extended element with an appropriate stereotype to represent other types of preprocessing directives not covered by the standard subclasses. Semantics of preprocessor directives in KDM is described later in this section.

Superclass

AbstractCodeElement

Associations

codeElement:AbstractCodeElement[0..*]

this optional code element represents the content of the preprocessor directive

Constraints:

PreprocessorDirective should have a stereotype

Semantics

From the KDM perspective, each preprocessor directive (an embedded language statement) is a container for code elements (possibly empty). KDM preprocessor support does not define any further special elements for semantic-rich representation of the embedded language directives. This is up to the implementer. The macro declaration is just code written for example in the “Cpreprocessor” language and can be represented using standard KDM constructs, such as CodeElements, Action, Flow etc., if needed or light-weight extension elements, like Stereotypes and ExtendedValues. In many situations, the right implementation choice is to leave the directive as an empty container with a name, and likely, a SourceRef with a code snippet.

It is possible to provide a high-fidelity semantic-rich representation of the preprocessor directives themselves (for example, parameters to MacroUnit, the body of the MacroUnit as CodeElements, conditional compilation expressions as KDM micro actions and flows) however in most situations this is inadequate. Besides, since many preprocessors operate at the level of lexical tokens or below, the representation of the body of the MacroUnit may not be adequate at the level of the CodeModel. In many situations, only the resulting code in the primary language can be interpreted semantically and represented as meaningful KDM CodeElements. Relationship Alternative is a practical approximation of a more precise description of the flow between the alternative branches of the conditional compilation directive. Example to this section only illustrate a simplified approach.

“Generated” code (code in the primary language that results from executing the preprocessor directives) is owned by a BlockUnit. There is a relation GeneratedFrom from the entire BlockUnit to the corresponding pre-processor directive. It is recommended that the generated code has a SourceRef with a snippet, since it is not present in the original source file and can not be referred to using the SourceRegion construct.

“Included” code (code in the primary language that results from executing the pre-processor include directive) is also owned by a BlockUnit. There is a relation GeneratedFrom from the entire BlockUnit to the corresponding pre-processor directive. From the logical perspective, the contents of an included file are owned by a certain SharedUnit. KDM does not restrict implementers whether to clone the included code elements or to reuse them and keep a single copy in the SharedUnit. However, many KDM implementations will usually clone the elements of the SharedUnit.

The implementer of KDM has the following implementation choices:

ignore the embedded language constructs, represent original and generated primary code; the resulting KDM does not contain any pre-processor directives, and relationships expands and alternative; information about the embedded language can not be recovered from the KDM representation;
ignore the generated primary code, provide a high-fidelity representation to the embedded construct; the embedded construct is the origin and the target of KDM relationships; some details of how the embedded construct is expanded into the primary code may not be recovered from the KDM representation (but in general, the embedded construct provides a better representation, since it is the view that developers have)
represent both the embedded constructs and the primary code, provide a high-fidelity representation only to the primary code; there is a BlockUnit that owns the generated code, the generated code is the origin and the target of KDM relationships; there are no KDM relations to and from the embedded construct (other than Expands and Alternative); there is an GeneratedFrom relation from the entire BlockUnit to the corresponding embedded construct;
represent both the embedded constructs and the primary code, provide the high fidelity representation to the embedded construct: there is a BlockUnit that owns the generated code, the embedded construct is the origin and the target of KDM relationships; there are no KDM relationships to and from the BlockUnit representing the generated code (but there may be some local relationships inside the BlockUnit); there is an GeneratedFrom relation from the entire BlockUnit to the corresponding embedded construct;

MacroUnit class

MacroUnit class represents macro definitions common to several programming languages. Although KDM allows semantic-rich contents of MacroUnit (as it is a subclass of a ControlElement), usually it is sufficient to represent a macro definition only as a names KDM element that can be the target of special Expands relations, so that its usage in the primary code as well as in other macro definitions can be tracked. The kind attribute provides some additional semantic information about the macro definition.

Superclass

PreprocessorDirective

Attributes

kind:MacroKind

additional semantic properties of the macro definition

Constraints

Semantics:

MacroUnit represents a preprocessor directive which defines a named rule for generating code, usually in the form of a macrodefinition, possible with the parameters and the body, where the occurrence of the name of the macro with the actual parameters is substituted by the body of the macro definition. KDM does not explicitly represent parameters to the macro directive or the body of the macro definition, since the granularity of these objects is usually related to string manipulation. However, the optional owned code element may be used to represent these.

It is the implementer’s responsibility to select particular strategy to representing macro units.

MacroKind data type (enumeration)

MacroKind enumeration datatype describes several semantic classes of MacroUnits.

Literal Value

regular	macro definition has a body and may have parameters
option	macro definition without a body and parameters, only a name
undefined	this value represents an undefined macro as the target for some relations in the representation of default branches of conditional compilation and variants
external	external compilation option
unknown	unknown class of a macro definition

MacroDirective class

MacroDirective class represents the so-called “macro call”, the occurrence of a macro name (possible with parameters) in the primary code, such that the preprocessor recognizes it and “expands” by substituting the macro directive construct with its “definition”. A block of “generated” code elements which represent the primary code resulting from macro expansion may be associated with the MacroDirective.

Superclass

PreprocessorDirective

Semantics

MacroDirective represents the so-called “macrocall”, or an occurrence of a macro name (possibly with the actual parameters) which is substituted by the body of the macro definition in which the occurrences of the formal parameters are substituted by the corresponding actual parameters. A MacroDirective can own an optional action element as the origin of the action relationships to the actual parameters to the MacroDirective.

IncludeDirective class

IncludeDirective class represents the so-called include directive, common to several programming languages and their preprocessors (for example, the COPY statement in Cobol, the #include directive in the C language). The include directive is usually related to a SharedUnit (for example, a copybook in Cobol, or a header file in C). A block of “included” code elements which are the clones of the elements owned by the SharedUnit may be associated with the include directive. Semantics of the IncludeDirective class is described later in this section in more detail.

Superclass

PreprocessorDirective

Semantics

IncludeDirective represents a preprocessor directive which is related to copying the content of some SharedUnit into a stand-alone CompilationUnit.

Conditional Directive class

ConditionalDirective class represents the so-called “variant” of a software system, resulting from the use of conditional compilation capabilities, common to several programming languages and their preprocessors (for example the #if … #endif and #ifdef … #endif directives of the preprocessor of the C language). ConditionalDirective represents a single “branch” of the conditional compilation construct. A block of “conditional” code elements which represent the elements of this particular variant that were selected for compilation may be associated with the conditional directive. Semantics of the ConditionalDirective class is described later in this section in more detail.

Superclass

PreprocessorDirective

Semantics

Conditional directive identifies a variant of the software system within a software product line which is controlled by the so-called conditional compilation. Conditional directive determines a block of “generated” code, corresponding to the selected variant. The block of “generated” code identifies the corresponding conditional directive.

PreprocessorRelations class diagram

The Preprocessor class diagram defines several concrete relationships types for the KDM support of embedded language constructs and pre-processor directives, common to several programming languages.

The classes and associations of the PreprocessorRelations class diagram are shown at See – PreprocessorRelations Class Diagram..

– PreprocessorRelations Class Diagram

Expands class

Expands class represents the relationship between a MacroUnit to another MacroUnit or from a MacroDirective to a MacroUnit. This relationship results from using the name of the target macro definition in the context of the origin MacroUnit or MacroDirective.

Superclass

AbstractCodeRelationship

Associations

to:MacroUnit[1]	the target MacroUnit
from:PreprocessorDirective[1]	the origin context in which the MacroUnit is used

Semantics:

It is the implementer’s responsibility to identify and represent associations between MacroUnits, as well as a MacroDirective and the corresponding MacroUnit according to the semantics of the preprocessor. See general description of the Preprocessor support for the implementer guidelines.

GeneratedFrom class

GeneratedFrom class represents the relationship between a block of code elements that were not originally produced by the developers, but were produced by the preprocessor as the result of processing a certain preprocessor directive. In particular, according to the level of granularity selected in KDM, aligned with the concrete subclasses of the PreprocessorDirective class, the resulting code may represent one of the following:

“generated” code that corresponds to a certain MacroDirective
“included: code that corresponds to a certain IncludeDirective
“conditional” code that was selected as a particular “variant” of a software product line with conditional compilation

GeneratedFrom relationship originates from the entire BlockUnit that owns the “generated” code and target the corresponding PreprocessorDirective.

Superclass

AbstractCodeRelationship

Associations

to:PreprocessorDirective[1]	a subclass of a PreprocessorDirective class that represent the preprocessor directive that was involved in producing the code
from:AbstractCodeElement[1]	The BlockUnit that owns the “generated” code

Constraints:

The origin of the GeneratedFrom relationship should be an BlockUnit

Semantics:

See the general description of the preprocessor directives for the implementer’s guidelines.

Example (C preprocessor):


#define GT(A,B) ((A) > (B))
#define GMAX(A,B) g=( GT(A,B) ? (A) : (B))
GMAX(p+q, r+s );


<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment xmi:version="2.1"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:action="http://kdm.omg.org/action"
xmlns:code="http://kdm.omg.org/code"
xmlns:kdm="http://kdm.omg.org/kdm" name="Macro Directive Example">
<model xmi:id="id.0" xmi:type="code:CodeModel">
<codeElement xmi:id="id.1" xmi:type="code:CompilationUnit">
<codeElement xmi:id="id.2" xmi:type="code:MacroUnit" name="GMAX">
<source language="Cpreprocessor"
snippet="#define GMAX(A,B) g=( GT(A,B) ? (A) : (B) )"/>
<codeRelation xmi:id="id.3" xmi:type="code:Expands" to="id.4" from="id.2"/>
</codeElement>
<codeElement xmi:id="id.4" xmi:type="code:MacroUnit" name="GT">
<source language="Cpreprocessor" snippet="#define GT(A,B) ((A) > (B))"/>
</codeElement>
<codeElement xmi:id="id.5" xmi:type="action:BlockUnit">
<codeElement xmi:id="id.6" xmi:type="code:StorableUnit" name="p" type="id.49"/>
<codeElement xmi:id="id.7" xmi:type="code:StorableUnit" name="q" type="id.49"/>
<codeElement xmi:id="id.8" xmi:type="code:StorableUnit" name="r" type="id.49"/>
<codeElement xmi:id="id.9" xmi:type="code:StorableUnit" name="s" type="id.49"/>
<codeElement xmi:id="id.10" xmi:type="code:StorableUnit" name="g" type="id.49"/>
<codeElement xmi:id="id.11" xmi:type="code:MacroDirective" name="m1">
<source xmi:id="id.12" language="Cpreprocessor" snippet="GMAX(p+q,r+s);"/>
<codeRelation xmi:id="id.13" xmi:type="code:Expands" to="id.2" from="id.11"/>
</codeElement>
<codeElement xmi:id="id.14" xmi:type="action:BlockUnit" name="bm1">
<codeRelation xmi:id="id.15" xmi:type="code:GeneratedFrom" to="id.11" from="id.14"/>
<codeElement xmi:id="id.16" xmi:type="action:ActionElement">
<source xmi:id="id.17" language="C"
snippet="g=( ((p+q) > (r+s)) ? (p+q) : (r+s) );"/>
<codeElement xmi:id="id.18" xmi:type="action:ActionElement" name="a1" kind="Add">
<actionRelation xmi:id="id.19" xmi:type="action:Reads" to="id.6" from="id.18"/>
<actionRelation xmi:id="id.20" xmi:type="action:Reads" to="id.10" from="id.18"/>
<actionRelation xmi:id="id.21" xmi:type="action:Writes" to="id.47" from="id.18"/>
<actionRelation xmi:id="id.22" xmi:type="action:Flow" to="id.23" from="id.18"/>
</codeElement>
<codeElement xmi:id="id.23" xmi:type="action:ActionElement" name="a2" kind="Add">
<actionRelation xmi:id="id.24" xmi:type="action:Reads" to="id.8" from="id.23"/>
<actionRelation xmi:id="id.25" xmi:type="action:Reads" to="id.9" from="id.23"/>
<actionRelation xmi:id="id.26" xmi:type="action:Writes" to="id.48" from="id.23"/>
<actionRelation xmi:id="id.27" xmi:type="action:Flow" from="id.23"/>
</codeElement>
<codeElement xmi:id="id.28" xmi:type="action:ActionElement"
name="a3" kind="GreaterThan">
<codeElement xmi:id="id.29" xmi:type="code:StorableUnit"
name="c" type="id.50" kind="register"/>
<actionRelation xmi:id="id.30" xmi:type="action:Reads" to="id.47" from="id.28"/>
<actionRelation xmi:id="id.31" xmi:type="action:Reads" to="id.48" from="id.28"/>
<actionRelation xmi:id="id.32" xmi:type="action:Writes" to="id.29" from="id.28"/>
<actionRelation xmi:id="id.33" xmi:type="action:Flow" to="id.34" from="id.28"/>
</codeElement>
<codeElement xmi:id="id.34" xmi:type="action:ActionElement"
name="a3.1" kind="Condition">
<actionRelation xmi:id="id.35" xmi:type="action:Reads"
to="id.29" from="id.34"/>
<actionRelation xmi:id="id.36" xmi:type="action:TrueFlow"
to="id.38" from="id.28"/>
<actionRelation xmi:id="id.37" xmi:type="action:FalseFlow"
to="id.42" from="id.34"/>
</codeElement>
<codeElement xmi:id="id.38" xmi:type="action:ActionElement"
name="a4" kind="Assign">
<actionRelation xmi:id="id.39" xmi:type="action:Reads" to="id.47" from="id.38"/>
<actionRelation xmi:id="id.40" xmi:type="action:Writes" to="id.10" from="id.38"/>
<actionRelation xmi:id="id.41" xmi:type="action:Flow" to="id.46" from="id.38"/>
</codeElement>
<codeElement xmi:id="id.42" xmi:type="action:ActionElement"
name="a5" kind="Assign">
<actionRelation xmi:id="id.43" xmi:type="action:Reads" to="id.48" from="id.42"/>
<actionRelation xmi:id="id.44" xmi:type="action:Writes" to="id.7" from="id.42"/>
<actionRelation xmi:id="id.45" xmi:type="action:Flow" to="id.46" from="id.42"/>
</codeElement>
<codeElement xmi:id="id.46" xmi:type="action:ActionElement" name="a6" kind="Nop"/>
<codeElement xmi:id="id.47" xmi:type="code:StorableUnit"
name="t1" type="id.49" kind="register"/>
<codeElement xmi:id="id.48" xmi:type="code:StorableUnit"
name="t2" type="id.49" kind="register"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.49" xmi:type="code:IntegerType" name="int"/>
<codeElement xmi:id="id.50" xmi:type="code:BooleanType" name="boolean"/>
</codeElement>
</codeElement>
</model>
</kdm:Segment>

Includes class

Includes class represents the relationship from an IncludeDirective to a SharedUnit that represents the code elements being included.

Superclass

AbstractCodeRelationship

Associations

from:AbstractCodeElement[1]	the code elements being included (usually a SharedUnit)
from:PreprocessorDirective[1]	the IncludeDirective class that represents the include directive

Constraints:

The origin of the Includes relationship should be an IncludeDirective

Semantics:

It is the implementer’s responsibility to identify and represent include relationships according to the semantics of the particular preprocessor.

Example (C preprocessor):


/*---a.h---*/
... c1 ...
...c2...
/*---a.c---*/
#include "a.h"
...c1...


<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment xmi:version="2.1"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:action="http://kdm.omg.org/action"
xmlns:code="http://kdm.omg.org/code"
xmlns:kdm="http://kdm.omg.org/kdm" name="Include Directive Example">
<model xmi:id="id.0" xmi:type="code:CodeModel">
<extensionFamily xmi:id="id.1" >
<stereotype xmi:id="id.2" name="sample"/>
</extensionFamily>
<codeElement xmi:id="id.3" xmi:type="code:SharedUnit" name="a.h">
<codeElement xmi:id="id.4" xmi:type="code:CodeElement" stereotype="id.2" name="c1">
<source xmi:id="id.5" language="C"/>
</codeElement>
<codeElement xmi:id="id.6" xmi:type="code:CodeElement" stereotype="id.2" name="c2">
<source xmi:id="id.7" language="C"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.8" xmi:type="code:CompilationUnit" name="a.c">
<codeElement xmi:id="id.9" xmi:type="code:IncludeDirective">
<source language="Cpreprocessor" snippet="#include &quot;a.h&quot;"/>
<codeRelation xmi:id="id.10" xmi:type="code:Includes" to="id.3" from="id.9"/>
</codeElement>
<codeElement xmi:id="id.11" xmi:type="action:BlockUnit" name="b1">
<codeRelation xmi:id="id.12" xmi:type="code:GeneratedFrom" to="id.9" from="id.11"/>
<codeElement xmi:id="id.13" xmi:type="code:CodeElement"
stereotype="id.2" name="c1_clone">
<source xmi:id="id.14" language="C"/>
</codeElement>
<codeElement xmi:id="id.15" xmi:type="code:CodeElement"
stereotype="id.2" name="c2_clone">
<source xmi:id="id.16" language="C"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.17" xmi:type="action:BlockUnit" name="b2">
<codeElement xmi:id="id.18" xmi:type="action:ActionElement" name="a1">
<actionRelation xmi:id="id.19" xmi:type="action:ActionRelationship"
to="id.13" from="id.18"/>
</codeElement>
</codeElement>
</codeElement>
</model>
</kdm:Segment>

VariantTo class

VariantTo class represents the relationship between variants of a software product line with conditional compilation. This relationship connects the ConditionalDirective to each alternative branch of the conditional compilation directive. KDM representation are expected to identify a single “default” variant, to which additional variants are alternatives. There is no VariantTo relationship to the “default” variant, only to the alternative ones. Each variant is expected to contain relationship GeneratedFrom connecting it to the corresponding ConditionalDirective. The “default” variant is expected to have a VariantTo relationship to every alternative branch.

Superclass

AbstractCodeRelationship

Associations

to:PreprocessorDirective[1]	ConditionalDirective class that represent an alternative variant of the conditional
from:PreprocessorDirective[1]	a ConditionalDirective class that represent the default variant of the conditional

Constraints:

The origin of the VariantTo relationship should be an ConditionalDirective

The target of the VariantTo relationship should be an ConditionalDirective

Semantics:

It is the implementer’s responsibility to identify and represent the variants and associations between the “generated” code and the corresponding conditional directive according to the semantics of the preprocessor. See the general description of the preprocessor directive support and the implementer guidelines.

Example (C preprocessor):


#define UNIX 1
#if UNIX | DEBUG
g=1;
#endif

Ifdef UNIX
g=1
#else
g=2
#endif

<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment xmi:version="2.1"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:action="http://kdm.omg.org/action"
xmlns:code="http://kdm.omg.org/code"
xmlns:kdm="http://kdm.omg.org/kdm" name="Variants Example">
<model xmi:id="id.0" xmi:type="code:CodeModel">
<codeElement xmi:id="id.1" xmi:type="code:MacroUnit" name="UNIX">
<source language="Cproprocessor" snippet="#define UNIX 1"/>
</codeElement>
<codeElement xmi:id="id.2" xmi:type="code:MacroUnit" name="DEBUG" kind="external"/>
<codeElement xmi:id="id.3" xmi:type="code:StorableUnit" name="g" type="id.4">
<codeElement xmi:id="id.4" xmi:type="code:IntegerType"/>
</codeElement>
<codeElement xmi:id="id.5" xmi:type="code:ConditionalDirective" name="c1">
<source language="Cpreprocessor" snippet="#if UNIX | DEBUG"/>
<codeRelation xmi:id="id.6" xmi:type="code:Expands" to="id.1" from="id.5"/>
<codeRelation xmi:id="id.7" xmi:type="code:Expands" to="id.2" from="id.5"/>
</codeElement>
<codeElement xmi:id="id.8" xmi:type="action:BlockUnit" name="b1">
<codeRelation xmi:id="id.9" xmi:type="code:GeneratedFrom" to="id.5" from="id.8"/>
<codeElement xmi:id="id.10" xmi:type="action:ActionElement" name="a1" kind="Assign">
<source xmi:id="id.11" language="C" snippet="g=123"/>
<codeElement xmi:id="id.12" xmi:type="code:Value" name="123" type="id.4"/>
<actionRelation xmi:id="id.13" xmi:type="action:Reads" to="id.12" from="id.10"/>
<actionRelation xmi:id="id.14" xmi:type="action:Writes" to="id.3" from="id.10"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.15" xmi:type="code:ConditionalDirective" name="c2">
<source language="Cpreprocessor" snippet="#ifdef UNIX"/>
<codeRelation xmi:id="id.16" xmi:type="code:Expands" to="id.1" from="id.15"/>
<codeRelation xmi:id="id.17" xmi:type="code:VariantTo" to="id.25" from="id.15"/>
</codeElement>
<codeElement xmi:id="id.18" xmi:type="action:BlockUnit" name="b2">
<codeRelation xmi:id="id.19" xmi:type="code:GeneratedFrom" to="id.15" from="id.18"/>
<codeElement xmi:id="id.20" xmi:type="action:ActionElement" name="a2" kind="Assign">
<source xmi:id="id.21" language="C" snippet="g=123"/>
<codeElement xmi:id="id.22" xmi:type="code:Value" name="1" type="id.4"/>
<actionRelation xmi:id="id.23" xmi:type="action:Reads" to="id.22" from="id.20"/>
<actionRelation xmi:id="id.24" xmi:type="action:Writes" to="id.3" from="id.20"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.25" xmi:type="code:ConditionalDirective" name="c3">
<source language="Cpreprocessor" snippet="#else"/>
<codeRelation xmi:id="id.26" xmi:type="code:Expands" to="id.1" from="id.25"/>
</codeElement>
<codeElement xmi:id="id.27" xmi:type="action:BlockUnit" name="b3">
<codeRelation xmi:id="id.28" xmi:type="code:GeneratedFrom" to="id.25" from="id.27"/>
<codeElement xmi:id="id.29" xmi:type="action:ActionElement" name="a3" kind="Assign">
<source xmi:id="id.30" language="C" snippet="g=123"/>
<codeElement xmi:id="id.31" xmi:type="code:Value" name="2" type="id.4"/>
<actionRelation xmi:id="id.32" xmi:type="action:Reads" to="id.31" from="id.29"/>
<actionRelation xmi:id="id.33" xmi:type="action:Writes" to="id.3" from="id.29"/>
</codeElement>
</codeElement>
</model>
</kdm:Segment>

Redefines class

Redefines class represents the relationship between a MacroUnit and another MacroUnit (usually with the same name) where the origin MacroUnit is a redefinition of the MacroUnit that is the target of the relationship. In many preprocessors, the redefinition is achieved simply by providing another macro definition with the same name. KDM Expands relationships are expected to correctly represent the semantics of the given preprocessor, by targeting the MacroUnit which is “current” definition at the given point.

Superclass

AbstractCodeRelationship

Associations

to:MacroUnit[1]	the old MacroUnit
from:PreprocessorDirective[1]	the new MacroUnit

Constraints

The origin of the Redefines relationship should be a MacroUnit

Semantics:

It is the implementer’s responsibility to identify and represent redefinitions of macro units according to the semantics of the particular preprocessor.

Example (C preprocessor):


#define A 1
#define A 2
#undef A
#pragma once

<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment xmi:version="2.1" xmlns:xmi="http://www.omg.org/XMI" xmlns:code="http://kdm.omg.org/code" xmlns:kdm="http://kdm.omg.org/kdm" name="Preprocessor Directives example">
<model xmi:id="id.0" xmi:type="code:CodeModel">
<extensionFamily xmi:id="id.1" >
<stereotype xmi:id="id.2" name="directive">
<tag xmi:id="id.3" tag="directive_type" type="String"/>
</stereotype>
</extensionFamily>
<codeElement xmi:id="id.4" xmi:type="code:MacroUnit" name="A">
<source language="Cpreprocessor" snippet="#define A 1"/>
</codeElement>
<codeElement xmi:id="id.5" xmi:type="code:MacroUnit" name="DEBUG" kind="option">
<source language="Cpreprocessor" snippet="#define DEBUG"/>
</codeElement>
<codeElement xmi:id="id.6" xmi:type="code:MacroUnit" name="A">
<source language="Cpreprocessor" snippet="#define A 2"/>
<codeRelation xmi:id="id.7" xmi:type="code:Redefines" to="id.4" from="id.6"/>
</codeElement>
<codeElement xmi:id="id.8" xmi:type="code:MacroUnit" name="A" kind="undefined">
<source language="Cpreprocessor" snippet="#undef A"/>
<codeRelation xmi:id="id.9" xmi:type="code:Redefines" to="id.6" from="id.8"/>
</codeElement>
<codeElement xmi:id="id.10" xmi:type="code:PreprocessorDirective" stereotype="id.2" name="d1">
<taggedValue xmi:id="id.11" xmi:type="kdm:TaggedValue" tag="id.3" value="pragma once"/>
<source language="Cpreprocessor" snippet="#pragma once"/>
</codeElement>
</model>
</kdm:Segment>

Comments Class Diagram

The Comments class diagram defines meta-model elements that represent comments. Comment is at the bottom of the inheritance hierarchy so that it can occur in all containers without restrictions. The classes and associations of the Comments diagram are shown in See – Comments Class Diagram..

– Comments Class Diagram

CommentUnit Class

The CommentUnit is a meta-model element which represents comments in existing systems (including any special comments). CommentUnit element can be used to introduce comments during transformation of the existing system (including special comments).

Superclass

ModelElement

Attributes

text:String

the representation of the comment

Constraints

Semantics

CommentUnit represents comments in the source code. CommentUnits are associated with a certain code element. It is the implementer’s responsibility to make a adequate decision on how to associate line comments with the surrounding elements in the source code.

AbstractCodeElement Class (additional properties)

Associations

comment:CommentUnit[0..*]

CommentUnits associated with the AbstractCodeElement

Constraints

Semantics

Visibility Class Diagram

The Visibility class diagram defines meta-model elements that represent visibility of code elements in their corresponding containers. The classes and associations that make up the Visibility diagram are shown in See – Visibility Class Diagram..

– Visibility Class Diagram

Namespace Class

The Namespace is a specific meta-model element that represents can be the target of the VisibleIn or Imports visibility relationships.

Superclass

CodeItem

Associations

groupedCode:CodeItem[0..*]

a KDM group of code elements which belong to the namespace. The actual owners of these elements are the corresponding modules, not the namespace, since namespaces can, in general cross cut the module boundaries.

Constraints

Namespace element should not belong to own group

Semantics

A Namespace is a group of code element. A Namespace can be owned by Module element or one of its subclasses. Namespace class represents a unit of visibility (for example, the namespace concept in C++).

An anonymous namespace can represent a group of code element that are the target of an Imports relationship

VisibilityRelations Class Diagram

The VisibilityRelations class diagram defines meta-model elements that represent visibility of code elements in their corresponding containers. The classes and associations of the Visibility diagram are shown in See – Visibility Class Diagram..

– VisibilityRelations Class Diagram

VisibleIn Class

The VisibleIn is a specific meta-model element that represents semantic relation between two code items, where one provides the restricted visibility context for another code item.

Superclass

AbstractCodeRelationship

Associations

from:CodeItem[1]	The CodeItem visibility of which is specified.
to:CodeItem[1]	The CodeItem that provides the visibility context.

Constraints

Semantics

VisibleIn optional relationship represents an association between a code item and one of the containers which corresponds to the visibility scope of the first item. This relationship is optional, since all other KDM relationship are determined by the semantics of the target language, including the visibility rules.

Example:


<?xml version="1.0" encoding="UTF-8"?>
<kdm:Segment xmi:version="2.1"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:action="http://kdm.omg.org/action"
xmlns:code="http://kdm.omg.org/code"
xmlns:kdm="http://kdm.omg.org/kdm" name="Visibility and Comment Example">
<model xmi:id="id.0" xmi:type="code:CodeModel">
<codeElement xmi:id="id.1" xmi:type="code:CodeAssembly">
<codeElement xmi:id="id.2" xmi:type="code:NamespaceUnit"
name="ab" groupedCode="id.4 id.9 id.13"/>
<codeElement xmi:id="id.3" xmi:type="code:CompilationUnit" name="a">
<codeElement xmi:id="id.4" xmi:type="code:CallableUnit"
name="foo" type="id.8" kind="regular">
<comment text="Comment #1 to foo"/>
<comment text="Comment #2 to foo"/>
<codeRelation xmi:id="id.5" xmi:type="code:VisibleIn" to="id.2" from="id.4"/>
<codeElement xmi:id="id.6" xmi:type="action:ActionElement" name="a1">
<comment xmi:id="id.7" text="Comment to action element a1"/>
</codeElement>
<codeElement xmi:id="id.8" xmi:type="code:Signature" name="foo"/>
</codeElement>
<codeElement xmi:id="id.9" xmi:type="code:IntegerType" name="int">
<comment xmi:id="id.10" text="Comment to integer type"/>
<codeRelation xmi:id="id.11" xmi:type="code:VisibleIn" to="id.2"/>
</codeElement>
</codeElement>
<codeElement xmi:id="id.12" xmi:type="code:CompilationUnit" name="b">
<codeElement xmi:id="id.13" xmi:type="code:RecordType" name="bar">
<comment xmi:id="id.14" text="Comment to record type bar"/>
<codeRelation xmi:id="id.15" xmi:type="code:VisibleIn" to="id.2" from="id.13"/>
<itemUnit xmi:id="id.16" name="foobar" type="id.9">
<comment xmi:id="id.17" text="Comment to item unit foobar"/>
<codeRelation xmi:id="id.18" xmi:type="code:VisibleIn" to="id.13" from="id.16"/>
</itemUnit>
</codeElement>
</codeElement>
</codeElement>
</model>
</kdm:Segment>

Imports Class

The Imports meta-model element represents an association between two CodeItems where one CodeItem “imports” definitions from another. The “import” relationship is common to several programming languages (for example, the import statement in Java). In this relationship the origin CodeItem (usually, a CompilationUnit or a subclass of Module) resolves the visibility of certain names that are defined (owned) by the target CodeItem (usually, another CompilationUnit or some other subclass of Module, but possibly a NamespaceUnit from another CodeItem, or even an individual code element). The Imports class simply represents the “import” relationships between CodeItem, for example, for tracking dependencies between packages. KDM representations themselves do not require additional import statements in order to have relationships between CodeItem, or even between different models.

Superclass

AbstractCodeRelationship

Associations

from:CodeItem[1]	a subclass of CodeResource that represent the “consumer” of the imported definitions
to:CodeItem[1]	a subclass of CodeResource that represent the “owner” of the imported definitions

Constraints

The origin of the Imports relationship should be an subclass of Module

Semantics

It is the implementer’s responsibility to identify and represent import directives and their targets according to the semantics of the programming language of the existing software system.

ExtendedCodeElements Class Diagram

The ExtendedCodeElements class diagram defines two “wildcard” generic elements for the code model as determined by the KDM model pattern: a generic code entity and a generic code relationship.

The classes and associations of the ExtendedCodeElements diagram are shown in See – Visibility Class Diagram..

– ExtendedCodeElements Class Diagram

CodeElement Class (generic)

The CodeElement is a generic meta-model element that can be used to define new “virtual” meta-model elements through the KDM light-weight extension mechanism

Superclass

CodeItem

Constraints

CodeElement should have at least one stereotype

Semantics

A code entity with under specified semantics. It is a concrete class that can be used as the base element of a new “virtual” meta-model entity types of the code model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.

CodeRelationship Class (generic)

The CodeRelationship is a generic meta-model element that can be used to define new “virtual” meta-model elements through the KDM light-weight extension mechanism

Superclass

AbstractCodeRelationship

Associations

from:CodeItem[1]	The CodeItem
to:KDMEntity[1]	The KDMEntity

Constraints

CodeRelationship should have at least one stereotype

Semantics

A code relationship with under specified semantics. It is a concrete class that can be used as the base element of a new “virtual” meta-model relationship types of the code model. This is one of the KDM extension points which can integrate additional language-specific, application-specific or implementer-specific pieces of knowledge into the standard KDM representation.