Core Package

Overview

The Core package provides basic constructs for creating and describing meta-model classes in all specific KDM packages. Classes of the Core package determine the structure of KDM models, define fundamental modeling constraints and determine the reflective API to KDM instances.

Organization of the Core Package

The KDM uses packages to control complexity and bring together logically interrelated classes. The Core package define a set of meta-model elements which have the purpose of defining the fundamental patterns and constraints implemented by all other KDM packages.

The KDM Core packages consists of the following 4 class diagrams:

The Core package depends on no other packages.

CoreEntities Class Diagram

The CoreEntity class diagram defines key abstractions shared by all KDM models.

The classes and associations of the CoreEntities class diagram are shown in See - CoreEntities Class Diagram..

 

 

 

- CoreEntities Class Diagram

Element Class (abstract)

An element is an atomic constituent of a model. In the meta-model, an Element is the top meta-element in the KDM class hierarchy. Element is an abstract meta-model element.

Semantics

Element is the common parent from all meta-model elements of KDM. Most subclasses of Element can own annotations and user-defined attributes through mechanisms defined in the kdm package.

 

ModelElement Class (abstract)

A model element is an element that represents some aspect of the existing system.

In the meta-model, a ModelElement is the base for all meta-elements of KDM. All other meta-elements are either direct or indirect subclasses of ModelElement. ModelElement is an abstract meta-model element.

A ModelElement can be extended through the lightweight extension mechanism.

Superclass

Element

Semantics

The ModelElement is a common class for all meta-model elements that represent some element of the existing software system. The subclasses of Element that are not the subclasses of the ModelElement class are the auxiliary elements of the KDM infrastructure.

Each subclass of the ModelElement meta-model element can be extended through the light-weight extension mechanism defined in the kdm package.

 

KDMEntity Class (abstract)

A KDM entity is a named model element that represents an artifact of existing software system.

In the meta-model, KDMEntity is a subclass of ModelElement. Each KDM package defines specific KDM entities that are direct or indirect subclasses of KDMEntity. A KDMEntity can be either an atomic element, a container for some KDMEntities or a group of some KDMEntities.

Superclass

ModelElement

Attributes

 

name: String

An identifier for the KDM entity.
Associations

 

owner:KDMContainer[0..1]

KDM container which owns the current element. This property determines a meta-level interface to KDM entities. This property is a derived union. Every specific KDM container defines a concrete set of owned elements that are subtypes of KDMEntity. In KDM this is represented by the CMOF "derived union" mechanism. Concrete properties subset the "union" properties of the parent classes, defined in the Core package. The owner of a KDM entity is defined as the container for which the given entity is an owned entity.
group:KDMGroup[0..*]

Set of KDM groups with which the current element is associated. This property determines a meta-level interface to KDM entities. This property is a derived union. Every specific KDM group defines a concrete set of grouped elements that are the subtypes of KDMEntity. In KDM this is represented by the CMOF "derived union" mechanism. Concrete properties subset the "union" properties of the parent classes, defined in the Core package. The group of a KDM entity is defined as the group for which the given entity is a grouped entity. Each KDM entity can be associated with multiple groups.
Constraints
  1. KDMEntity can have either the ownedElement or groupedElement, but not both.
  2. KDMEntity should not reference self as groupedElement
Operations

 

getOwner(): KDMEntity[0..1]

This operation returns the KDM entity which is the owner of the current KDM Entity. The owner entity is a KDM container. There can be at most one owner for each given entity

getOwnerElement():KDMEntity[0..*]

This operation returns the set of KDM entities which are owned by the current KDM Entity. Only KDM containers can own other entities.

getGroup():KDMEntity[0..*]

This operation returns the set of KDM Entities which have a group association to the current KDM Entity. The group entity is a KDM group. Unlike KDM containers, there may be many groups that have an association to a given entity.

getGroupedElement():KDMEntity[0..*]

This operation returns the set of KDM entities which are "grouped" by the current KDM entity. Only KDM groups can have group associations to other entities.
Semantics

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.

CoreRelations Class Diagram

The Core class diagram defines key meta-model associations of KDM models.

The classes and associations of the CoreRelations class diagram are shown in See - CoreRelations Class Diagram..

 

- CoreRelations Class Diagram

KDMRelationship Class (abstract)

A KDM relationship is a model element that represents semantic association between two entities.

In the meta-model, KDMRelationship is a subclass of ModelElement. Each KDM package defines some specific KDM relations that are either direct or indirect subclasses of KDMRelationship. Specific subclasses of KDMRelationship are typed associations between some specific subclasses of KDMEntity.

Superclass

ModelElement

Associations

 

to: KDMEntity[1]

The target entity (also referred to as the to-endpoint of the relationship). This property determines a meta-level interface to KDM relationships. This property is a derived union. Every specific KDM relationship redefines the to-endpoint to a particular subtype of KDMEntity. In KDM this is represented by the CMOF "redefines" mechanism. Concrete properties redefine the "union" properties of the parent classes, defined in the Core package.

from:KDMEntity[1]

The origin entity (also referred to as the from-endpoint of the relationship). This property determines a meta-level interface to KDM relationships. This property is a derived union. Every specific KDM relationship redefines the from-endpoint to a particular subtype of KDMEntity. In KDM this is represented by the CMOF "redefines" mechanism. Concrete properties redefine the "union" properties of the parent classes, defined in the Core package.
Constraints
Operations

 

getTo(): KDMEntity[1]

This operation returns the KDM entity which is the to-endpoint (the target) of the current relationship

getFrom():KDMEntity[1]

This operation returns the KDM entity which is the from-endpoint (the origin) of the current relationship.
Semantics

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.

KDMEntity (additional properties)

Associations

 

ownedRelation: KDMRelationship[0..*]

Primitive KDM relationships that originate from the current entity
Operations

 

getInbound(): KDMRelationship[0..*]

This operation returns the set of relationships such that the current KDMEntity is the to-endpoint of these relations

getOutbound():KDMRelationship[0..*]

This operation returns the set of relationships such that the current KDMEntity is the from-endpoint of the these relationships

getOwnedRelation():KDMRelationship[0..*]

This operation returns the set of relationships such that the current KDMEntity owns these relationships
Constraints

The set of ownedRelations for a given KDMEntity should be the same as the set of KDMRelations for which the from property is the given KDMEntity.

Semantics

This property defines the so called "encapsulated relationship" pattern. From the infrastructure perspective, the ownedRelation association is required to manage relationship elements. KDM relationships are owned by the entity which is the origin of the relationship. From the meta-model perspective, each relationship is a self-contained association class with to- and from- properties.

AggregatedRelations Class Diagram

The AggregatedRelations class diagram defines the key analysis mechanism of KDM. AggregatedRelationship are part of the "meta-level" interface to KDM models, along with interface defined by KDMEntity, and KDMRelationship.

Overall management and lifecycle of the Aggregated Relationships is determined by the operations of the KDMEntity class.

The classes and associations of the AggregatedRelations class diagram are shown in See - AggregatedRelations Class Diagram..

 

- AggregatedRelations Class Diagram

AggregatedRelationship Class

The set of aggregated relationships for a given entity represents all primitive relationships between the entities that are transitively owned by the given entity as well as the entity itself. This is a concrete class, because an AggregatedRelationship can be instantiated, and exchanged. AggregatedRelations are meant to be built on demand (and exchanged too, if necessary). The lifecycle of the Aggregated Relationships can be explicitly managed by the operations of the KDMEntity class.

Superclass

ModelElement

Attributes

 

density:Integer

The number of primitive relationships in the aggregated set.

 

Associations

 

relation:KDMRelationship[0..*]

The set of primitive KDM relationships represented by the aggregated relationship.
to: KDMEntity[1]

The target container of the relationships in the aggregated set. All relations in the aggregated set should terminate at the target container or at some entity that is contained directly or indirectly in the target container.
from:KDMEntity[1]

The source container of the relationships in the aggregated set. All relationships in the aggregated set should originate from the source container or from some entity that is contained directly or indirectly in the source container.

 

Constraints
  1. To- and from-endpoints should be distinct.
  2. The density should be greater than or equal to 1.
  3. The density should be the same as the number of primitive relations represented by the given aggregated relationship.
  4. The to- and from- endpoints of each relation should be the same as in the aggregated relationship.
Semantics

AggregatedRelations are determined by how atomic elements are owned by containers (or referenced by groups) in the following way:

  1. AggregatedRelationship between two entities (no owned elements) represents the set of regular KDM relationships between these two entities (such that the first entity is the from-endpoint of the relationship, and the second entity is the to-endpoint of the relationship).
  2. AggregatedRelationship between an entity and a container (or group) represents the set of all regular KDM relationships such that the given entity is the from-endpoint and the to-endpoint is any entity that is owned by the given container (directly or indirectly).
  3. AggregatedRelationship between a container (or group) and an entity represents the set of all regular relationships such that the to-endpoint is the given entity and the from-endpoint is any entity that is owned by the given container (directly or indirectly).
  4. AggregatedRelation between two containers represents the set of all regular KDM relations such that the from-endpoint is an entity owned by the first container and the to-endpoint is an entity owned by the other container.

A regular KDM relationship is represented by a subtype of KDMRelationship class. It has a concrete type, and an implied density of 1. An AggregatedRelationship represents a set of regular KDM relationships. It has density of greater or equal than 1 and no concrete type (as it may represent regular KDM relationships of different types). An AggregatedRelationship cannot be constructed between two entities if there are no regular KDM relationships between them (according to the definition above).

The relation "x in* C" means that x is in container C or in some sub-container of C, transitively.

For relation R, let R' be the corresponding aggregated relation.

Given containers C1 and C2 and the relation R, let

P = {(x,y) : x in* C1 and y in* C2 and x R y}

That is, P is the set of pairs such that x is in* C1 and y is in* C2 and x R y.

Then

C1 R' C2 iff |P| > 0

C1 and C2 are related by the aggregated relation R' if and only if there is at least one pair in the set P.

The density of C1 R' C2 is then simply |P|, the size of the set P.

 

- AggregatedRelations illustrated

See - AggregatedRelations illustrated. Illustrates Containers and aggregated relations. It uses the following notation. UML package symbols represent KDM Containers, UML associations represent KDMRelations. An arrow at the end of an association indicates, the direction of the relation (there should be at least one arrow; arrows at both ends indicate two relations, one in each direction).Numbers at the ends of associations represent the density of the corresponding KDM relationship. The KDM density has a different interpretation that UML multiplicity: since KDM represents an existing application, the exact relations and their number is what the model captures. KDM model is not a model that represents constraints, like the ones used during the design phase, rather, this is a model that captures precise knowledge about the application. So, the KDM densities are exact.

Aggregated relations are collections of more primitive relations, which at the end are some basic code fact, for example "procedure x calls procedure y". Such basic fact has density 1. The primitive code relation represents some basic fact about the existing application. Now, when there are two or more such facts, for example "procedure x in module A calls procedure y in module B" and "procedure z in module A calls procedure y in module B", there is an aggregated relation between modules A and B with density 2 (2=1+1). In this case, the aggregated relation represents the collection of the two primitive relations between modules A and B.

KDMEntity (additional properties)

Operations

 

createAggregation(otherEntity:KDMEntity)

This operation creates an aggregated relationship such that the current entity is the from-endpoint of the aggregated relation and the "otherEntity" is the to-endpoint. The new aggregated relationship is owned by the model to which owns the current entity (either directly or indirectly through container ownership).
deleteAggregation
(aggregatedRelation:AggregatedRelationship)

This operation deletes the given aggregated relationship.
getInAggregated():AggregatedRelationship[0..*]

This operation returns the set of AggregatedRelationship for which the target is the current KDM Entity
getOutAggregated():AggregatedRelationship[0..*]

This operation returns the set of AggregatedRelationship for which the origin is the current KDM Entity

 

Datatypes Class Diagram

The Datatypes class diagram collects together utility data types for the Core package. Each class at the Datatypes class diagram is a subclass of MOF DataType class. The classes of the Datatypes class diagram are shown in See - Datatypes Class Diagram..

 

- Datatypes Class Diagram

Boolean Type (datatype)

The meta-model uses the Boolean type to represent some KDM attributes, KDM operations, and their parameters.

String Type (datatype)

The meta-model uses the String type to represent some KDM attributes, KDM operations, and their parameters.

Integer Type (datatype)

The meta-model uses the Integer type to represent some KDM attributes, KDM operations, and their parameters.