Part 1. KDM Infrastructure Layer
KDM is a large specification, since it provides n intermediate representation for several facets of knowledge about existing enterprise software system. In order to manage the complexity of KDM, a small set of concepts was selected and systematically used throughout the entire specification. These concepts are defined in the so-called KDM Infrastructure Layer. It consists of the following 3 packages:
The Core package defines the fundamental meta-model element types and the corresponding constraints. Core package provides a set of types which determine each individual KDM meta-model element through subclassing. Each KDM meta-model element is a subclass of one of the core classes. From the meta-model perspective KDM is an entity-relationship representation. So, the two fundamental classes of the Core package are KDMEntity and KDMRelationship. An entity is a thing of significance, about which information needs to be known or held. A KDM entity is an abstraction of some element of an existing software system, that has a distinct, separate existence, a self-contained piece of data that can be referenced as a unit. Each KDM package defines several entity types representing specific abstractions related to a certain viewpoint on existing software systems.
A relationship is represents an association, linkage, or connection between entities which describes their interaction, the dependence of one upon the other, or their mutual interdependence. A KDM relationship represents some semantic association between elements of an existing software system. Each KDM package defines several relationship types representing specific abstractions related to a certain viewpoint on existing software systems. All KDM relationships are binary.
KDM defines two special relationships:
Some KDM entities are containers for other entities. There is a special container ownership (containment) relationship between a container and the entities that are directly owned by this container. Some KDM entities are groups of other KDM entities. There is a special group association (grouping) relationship between the group and the entities that are directly “grouped into” this group.
Core package define an analysis mechanism, the so-called Aggregated Relations mechanism that brings together special relationships of containment and grouping and regular relationships of the entity-relationship model.
Core package defines a reflective API to KDM representation. Other KDM packages extend this API by specific operations, corresponding to specific facets of knowledge about existing software systems.
Small KDM Core is aligned with OMG SBVR specification, as it provides an abstraction of existing software system in the form of terms (various KDM entities) and facts (various attributes of KDM entities, and relationships between KDM entities). Indeed, most of the KDM specification is a definition of a language- and platform-independent ontology of existing software systems. This alignment is important since KDM can be viewed as a standard vocabulary related to descriptions of existing software systems. SBVR rules can be written using this vocabulary to formally describe further properties of existing software systems.
The kdm package defines several elements that together constitute the framework of each KDM representation. The framework determines the physical structure of a KDM representation. The elements of the framework are present in every instance of KDM that represents a particular existing software system. From the framework perspective, each KDM representation consists of one or more Segments, where each Segment owns several KDM models. Each KDM package defines some specific type of KDM model, which addresses a certain specific facet of knowledge about existing software systems. Individual KDM implementations may support one or more selected KDM models, as defined in the KDM compliance section. KDM tools may use multiple KDM implementation to represent different facets of knowledge about the existing software system and integrate them into a single coherent representation. Further, KDM design facilitate incremental implementations, where certain pieces of knowledge about the existing software is collected by analyzing more lower level KDM representations. According to this approach certain KDM tools may perform a “KDM enrichment” process, a “KDM to KDM transformation”, where a tool analyzes the input KDM model and produces one or more additional Segments and Models, explicitly representing certain derived pieces of knowledge about the system.
The Source package defines the so called Inventory model, which represents the physical artifacts of an existing system as KDM entities as well as the mechanism of traceability links which provide associations between KDM elements and their “original” language-dependent representation in the source code of the existing software system, for which the KDM representation is created. This is an important part of the KDM Infrastructure, because other KDM packages use this mechanism to refer to the source code and the physical artifacts of the existing software system.