Skip to Main Navigation Skip to Content

Prioritize, Measure and Quantify CyberSecurity Risk

21. Build Package

The Build package represents the artifacts that represent the engineering view of a particular existing system. The Build package also includes the entities to represent the artifacts which are generated by the build process.

Organization of the Build Package

The Build package defines a collection of meta-model elements whose purpose is to represent entities and relationships related to the engineering view of existing software systems.

The Build package consists of the following class diagrams:

  • BuildModel
  • BuildInheritances
  • BuildResources
  • BuildRelations
  • ExtendedBuildRelations

The Build package depends on the following packages:

  • Core
  • kdm
  • Source

BuildModel Class Diagram

The BuildModel class diagram provides basic meta-model constructs to model the engineering view of a particular existing software system within the KDM framework. The class diagram shown in See – BuildModel Class Diagram. captures these classes and their relations.

– BuildModel Class Diagram

BuildModel Class

The BuildModel encapsulates meta-model constructs needed to model the building of a particular software system.

Superclass

KDMModel

Associations

buildElement:AbstractBuildElement[0..*] The set of build elements owned by the model

Constraints

Semantics

AbstractBuildElement Class (abstract)

The AbstractBuildElement is the abstract base class from which all other build model elements are extended.

Superclass

KDMEntity

Associations

buildRelationship:AbstractBuildRelationship[0..*] The set of build relations

Constraints

Semantics

AbstractBuildRelationship Class (abstract)

The AbstractBuildRelationship is the abstract base class

Superclass

KDMRelationship

Constraints

Semantics

Origin Class

The Origin class models producers of the 3rd party software components as they contribute to the build process.

Superclass

AbstractBuildElement

Semantics

Tool Class

The Tool class represents software tools as they are used in the build process.

Superclass

AbstractBuildElement

Semantics

SymbolicLink Class

The SymbolicLink is used to represent symbolic links.

Superclass

AbstractBuildElement

Semantics

BuildInheritances Class Diagram

The BuildInheritances Class Diagram shown in See – BuildInheritances Class Diagram. depicts how various build classes extend other KDM classes. Each of the classes shown is this diagram inherits properties from classes found in the KDM Core package.

– BuildInheritances Class Diagram

BuildResources Class Diagram

The BuildResources class diagram provides basic meta-model constructs to model various common build resource and their relations to the code model. The class diagram shown in See – BuildResources Class Diagram. captures these classes and their relations.

– BuildResources Class Diagram

BuildResource Class

BuildResource class is a generic meta-model element that represents a container for build elements. It provides a common superclass for the build elements that can own other build elements. BuildResource is also a group for other KDM entities. Usually, a Build resource such as a Library, a BuildProduct or a BuildComponent will group together some Inventory elements. Certain BuildResource can also group other build elements.

Superclass

AbstractBuildElement

Associations

buildElement:AbstractBuildElement[0..*] owned build element
groupedBuild:AbstractBuildElement[0..*] grouped build elements (KDM group mechanism)
implementation:KDMEntity[0..*]

Constraints

BuildResource should either own elements or group elements but not both

  1. “implementation” group should not include other Build elements.
  2. Build element should not be included in its own groupedBuild group.

Semantics:

BuildComponent Class

The BuildComponent class represents binary files that correspond to deployable components, for example executable files.

Superclass

BuildResource

Semantics

BuildDescription Class

The BuildDescription class is used to model objects such as make files or ant scripts, which describe the build process itself.

Superclass

BuildResource

Associations

source:SourceRef[0..*] Link to the physical artifact for the build description

Semantics

BuildStep class

BuildStep class is the key meta-model element of the Build model. It represents a unit of transformation performed by the build process, during which certain input resources are processed and certain output resources are produced. BuildStep element is the origin of several build relationships. For example, a Build step “consumes” certain input resources, “produces” certain output resources, “is defined” by a certain build description, and may be “supported” by a certain tool.

Superclass

BuildResource

Semantics

BuildRelations Class Diagram

The BuildRelations class diagram defines the various build related relationships.

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

– BuildRelations Class Diagram

LinksTo Class

The LinksTo class models the relationship between two linked build resources.

Superclass

AbstractBuildRelationship

Associations

from:SymbolicLink[1]
to:AbstractBuildElement[1]

Constraints

Semantics

Associations

from:AbstractBuildElement[1]
to:AbstractBuildElement[1]

Constraints

Semantics

Consumes class

Consumes class defines association between a certain BuildStep element and certain build elements, called the input build elements. These elements provide the input to the transformation, performed by the build step. For example, the set of source files is an input to the compilation step.

Superclass

AbstractBuildRelationship

Associations:

from:BuildStep[1] the build step
to:AbstractBuildElement[1] the input build elements for the given step

Semantics:

It is the implementer’s responsibility to capture the input build elements for a certain build step in the form of “Consumes” relation.

When the target of the “Consumes” relationship owns other build elements, this means that the build step (the origin of the relationship) depends on all elements owned by the container (directly or indirectly).

When the origin of the “Consumes” relationship is a container that owns one or more build steps (directly or indirectly), this means that all build steps consume the elements designated as the target of the “Consumes” relationship.

Produces class

Produces class defines association between a certain BuildStep element and certain build elements, called the output build elements. These elements are produced as the result of the transformation, performed by the build step. For example, the set of object files can be produced as the result of the compilation step.

Superclass

AbstractBuildRelationship

Associations:

from:BuildStep[1] the build step
to:AbstractBuildElement[1] the output build elements for the given step

Semantics:

It is the implementer’s responsibility to capture the output build elements for a certain build step in the form of “Produces” relation.

When the target of the “Produces” relationship owns other build elements, this means that the build step (the origin of the relationship) produces all elements owned by the container (directly or indirectly).

When the origin of the “Produces” relationship is a container that owns one or more build steps (directly or indirectly), this means that the elements designated as the target of the “Produces” relationship are produced in collaboration of all build steps, and no particular build step is the sole producer.

SupportedBy class

SupportedBy class defines association between a certain BuildStep element and certain Tool element. The Tool element is required to perform the build step. For example, a particular version of a complier is required to perform the compilation step.

Superclass

AbstractBuildRelationship

Associations:

from:BuildStep[1] the build step
to:Tool[1] the Tool element that represents the tool performing the transformations represented by the given step

Semantics:

It is the implementer’s responsibility to capture the required Tool elements for a certain build step in the form of “SupportedBy” relation.

SuppliedBy class

SuppliedBy class defines association between certain build elements and their points of origin, represented by Supplier element. For example, certain parts of the runtime platform can originate from a software vendor, some libraries can originate from open source.

Superclass

AbstractBuildRelationship

Associations:

from:AbstractBuildElement[1] the build element
to:Supplier[1] the Supplier element that represents the origin of the build element

Semantics:

It is the implementer’s responsibility to capture the origin of build elements fin the form of “SuppliedBy” relation.

When the origin of the “SuppliedBy” relationship is a container that owns one or more build elements (directly or indirectly), this means that all elements designated as the source of the “SuppliedBy” relationship are supplied by a particular Supplier element.

DescribedBy class

DescribedBy class defines association between certain build step and a certain BuildDescription element. These elements are produced as the result of the transformation, performed by the build step. For example, the set of object files can be produced as the result of the compilation step.

Superclass

AbstractBuildRelationship

Associations:

from:BuildStep[1] the build step
to:BuildDescription[1] The BuildDescription element that describes the transformation represented by the build step

Semantics:

It is the implementer’s responsibility to capture the description of a certain build step in the form of “DescribedBy” relation to some BuildDescription element.

Example:

<?xml version=”1.0″ encoding=”UTF-8″?>

 

<kdm:Segment xmi:version=”2.1″

 

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

 

xmlns:build=”http://kdm.omg.org/build”

 

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

 

xmlns:source=”http://kdm.omg.org/source” name=”Build Example”>

 

<model xmi:id=”id.0″ xmi:type=”source:InventoryModel”>

 

<inventoryElement xmi:id=”id.1″ xmi:type=”source:SourceFile” name=”a.c”>

 

<inventoryRelation xmi:id=”id.2″ xmi:type=”source:DependsOn” to=”id.5″ from=”id.1″/>

 

</inventoryElement>

 

<inventoryElement xmi:id=”id.3″ xmi:type=”source:SourceFile” name=”b.c”>

 

<inventoryRelation xmi:id=”id.4″ xmi:type=”source:DependsOn” to=”id.5″ from=”id.3″/>

 

</inventoryElement>

 

<inventoryElement xmi:id=”id.5″ xmi:type=”source:SourceFile” name=”ab.h”/>

 

<inventoryElement xmi:id=”id.6″ xmi:type=”source:Directory”>

 

<inventoryElement xmi:id=”id.7″ xmi:type=”source:Image”/>

 

<inventoryElement xmi:id=”id.8″ xmi:type=”source:Image”/>

 

</inventoryElement>

 

<inventoryElement xmi:id=”id.9″ xmi:type=”source:SourceFile” name=”makefile”/>

 

<inventoryElement xmi:id=”id.10″ xmi:type=”source:ExecutableFile” name=”ab.exe”/>

 

</model>

 

<model xmi:id=”id.11″ xmi:type=”build:BuildModel”>

 

<buildElement xmi:id=”id.12″ xmi:type=”build:BuildComponent”

 

name=”sources” implementation=”id.1 id.5 id.3″/>

 

<buildElement xmi:id=”id.13″ xmi:type=”build:BuildProduct”

 

name=”ab product” implementation=”id.10″/>

 

<buildElement xmi:id=”id.14″ xmi:type=”build:BuildStep”>

 

<buildRelation xmi:id=”id.15″ xmi:type=”build:DescribedBy” to=”id.28″ from=”id.14″/>

 

<buildRelation xmi:id=”id.16″ xmi:type=”build:SupportedBy” to=”id.30″ from=”id.14″/>

 

<buildElement xmi:id=”id.17″ xmi:type=”build:BuildStep” name=”compile”>

 

<buildRelation xmi:id=”id.18″ xmi:type=”build:Consumes” to=”id.12″ from=”id.17″/>

 

<buildRelation xmi:id=”id.19″ xmi:type=”build:Produces” to=”id.25″ from=”id.17″/>

 

<buildRelation xmi:id=”id.20″ xmi:type=”build:SupportedBy” to=”id.26″ from=”id.17″/>

 

</buildElement>

 

<buildElement xmi:id=”id.21″ xmi:type=”build:BuildStep” name=”link”>

 

<buildRelation xmi:id=”id.22″ xmi:type=”build:Consumes” to=”id.25″ from=”id.21″/>

 

<buildRelation xmi:id=”id.23″ xmi:type=”build:Produces” to=”id.13″ from=”id.21″/>

 

<buildRelation xmi:id=”id.24″ xmi:type=”build:SupportedBy” to=”id.26″ from=”id.21″/>

 

</buildElement>

 

<buildElement xmi:id=”id.25″ xmi:type=”build:BuildComponent” name=”object files”/>

 

<buildElement xmi:id=”id.26″ xmi:type=”build:Tool” name=”C compiler”>

 

<buildRelation xmi:id=”id.27″ xmi:type=”build:SuppliedBy” to=”id.32″ from=”id.26″/>

 

</buildElement>

 

</buildElement>

 

<buildElement xmi:id=”id.28″ xmi:type=”build:BuildDescription” implementation=”id.9″>

 

<source xmi:id=”id.29″ language=”shell” snippet=”cc $(SOURCE) -o ab.exe”/>

 

</buildElement>

 

<buildElement xmi:id=”id.30″ xmi:type=”build:Tool” name=”make”>

 

<buildRelation xmi:id=”id.31″ xmi:type=”build:SuppliedBy” to=”id.32″ from=”id.30″/>

 

</buildElement>

 

<buildElement xmi:id=”id.32″ xmi:type=”build:Supplier” name=”Tools’R’Us corp”/>

 

</model>

 

</kdm:Segment>

ExtendedBuildElements Class Diagram

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

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

– ExtendedBuildElements Class Diagram

BuildElement Class (generic)

The BuildElement 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

AbstractBuildElement

Constraints

BuildElement should have at least one stereotype

Semantics

A build 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 build 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.

BuildRelationship Class (generic)

The BuildRelationship 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

AbstractBuildRelationship

Associations

from:AbstractBuildElement[1] The build element origin of the relationship
to:KDMEntity[1] The KDMEntity target of the relationship

Constraints

BuildRelationship should have at least one stereotype

Semantics

A build 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 build 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.