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:
The Build package depends on the following packages:
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.
| buildElement:AbstractBuildElement[0..*] | The set of build elements owned by the model |
AbstractBuildElement Class (abstract)
The AbstractBuildElement is the abstract base class from which all other build model elements are extended.
| buildRelationship:AbstractBuildRelationship[0..*] | The set of build relations |
AbstractBuildRelationship Class (abstract)
The AbstractBuildRelationship is the abstract base class
Origin Class
The Origin class models producers of the 3rd party software components as they contribute to the build process.
Tool Class
The Tool class represents software tools as they are used in the build process.
SymbolicLink Class
The SymbolicLink is used to represent symbolic links.
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.
| buildElement:AbstractBuildElement[0..*] | owned build element |
| groupedBuild:AbstractBuildElement[0..*] | grouped build elements (KDM group mechanism) |
| implementation:KDMEntity[0..*] |
BuildResource should either own elements or group elements but not both
- “implementation” group should not include other Build elements.
- Build element should not be included in its own groupedBuild group.
BuildComponent Class
The BuildComponent class represents binary files that correspond to deployable components, for example executable files.
BuildDescription Class
The BuildDescription class is used to model objects such as make files or ant scripts, which describe the build process itself.
| source:SourceRef[0..*] | Link to the physical artifact for the build description |
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.
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.
| from:SymbolicLink[1] | |
| to:AbstractBuildElement[1] |
| from:AbstractBuildElement[1] | |
| to:AbstractBuildElement[1] |
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.
| from:BuildStep[1] | the build step |
| to:AbstractBuildElement[1] | the input build elements for the given step |
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.
| from:BuildStep[1] | the build step |
| to:AbstractBuildElement[1] | the output build elements for the given step |
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.
| from:BuildStep[1] | the build step |
| to:Tool[1] | the Tool element that represents the tool performing the transformations represented by the given step |
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.
| from:AbstractBuildElement[1] | the build element |
| to:Supplier[1] | the Supplier element that represents the origin of the build element |
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.
| from:BuildStep[1] | the build step |
| to:BuildDescription[1] | The BuildDescription element that describes the transformation represented by the build step |
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.
<?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 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 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 xmi:id=”id.9″ xmi:type=”source:SourceFile” name=”makefile”/>
<inventoryElement xmi:id=”id.10″ xmi:type=”source:ExecutableFile” name=”ab.exe”/>
<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 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 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 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 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 xmi:id=”id.32″ xmi:type=”build:Supplier” name=”Tools’R’Us corp”/>
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
BuildElement should have at least one stereotype
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
| from:AbstractBuildElement[1] | The build element origin of the relationship |
| to:KDMEntity[1] | The KDMEntity target of the relationship |
BuildRelationship should have at least one stereotype
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.