KDM12 — Missing definitions of terms (rh-3)

Related to section 4

It is hard to believe that there are "no special terms or definitions in this specification", since usage of a number of terms in this DIS seem to have no relationship to other, more common usages of those same terms.

Define the terms that have specialzed meanings or usage in this DIS. ISO/IEC 42010:2007 provides a well established ontology for describing architectures of various types, presumably including "Architecture Driven Modernization" senses of "Architecture". For the architecture-related terms, architecture, architecture description, architecture view, architecture viewpoint and architecture model, adopt the defintions from ISO/IEC 42010:2007

Section 4, Page 6 “Terms and Definitions”
Replace sentence “There are no special terms or definitions in this specification.”
with the following text:
This subclause contains only those terms which are used in a specialised way throughout the
KDM specification. The majority of terms in KDM are used either according to their
accepted dictionary definitions or according to commonly accepted definitions that may be
found in ISO glossaries or other well-known collections of software engineering terms. Some
combinations of common terms used in KDM, while not meriting glossary definition, are
explained for clarity in the context where they are used.
Abstraction: A view of an object that focuses on the information relevant to a particular
purpose and ignores the remainder of the information.
Aggregation: a derived relationship between two elements that are groups of other
elements that represents all individual relationships between the grouped elements of the
two groups.
Architecture-Driven Modernization (ADM): ADM is the process of understanding and
evolving existing software assets of a system of interest. ADM focuses at collecting,
sharing, utilizing, transforming, presenting, maintaining and storing models of the
architectural aspects of existing systems. ADM does not preclude source-to-source
migrations (where appropriate), but encourages user organizations to consider
modernization from an analysis and design perspective. In doing so, project teams ensure
that obsolete concepts or designs are not propagated into modern languages and
platforms. Build: An operational version of a system or component that incorporates a specified
subset of the capabilities that the final product provides.
Build process: a process of transforming of project code base into usable applications.
The end result of a software build is a collection of files that consitute a product in a
distributable package. In this case, package can mean a standalone application, Web
service, compact disc, hotfix, or bug fix. Each step of a build process is a transformation
performed by software running on a general purpose computer. A simple software build
may involve compiling a single source code file into an executable code. A complex
software build may involve orchestrating hundreds of versions of thousands of files with
millions of lines of source code such that a correct executable code results from the
compilation. The implementation of a system also involves deploying the build onto the
system nodes, and applying appropriate configuration settings.
Component: a functionally or logically distinct part of a system. A component may be
hardware or software and may be subdivided into other components. Often a component
is a physical, replaceable part of a system that packages implementation and provides the
realization of a set of interfaces. Such component represents a physical piece of
implementation of a system, including software code (source, binary or executable) or
equivalents such as scripts or command files.
Container: a model element that owns one or more distinct elements through the special
“owns” (“contains”) relationships between the container element and owned elements.
“Containment” relationships form a special group of the corresponding owned elements.
No element has more than one container.
Domain : An area of knowledge or activity characterized by a set of concepts and
terminology understood by practitioners in that area.
Element: one of the parts of a compound or complex whole. For example, a model
element, a meta-model element.
Group: a number of model elements regarded as a unit formed by traceability
relationships to a single distinct element. An element may be part of multiple groups,
including a single group formed by the “containment” relationships between a container
and its owned elements. An element is said to group together one or more elements, if
these elements have traceability relationships to the element.
Hierarchy: an arrangement of model elements according to traceability relationships,
where an element that “owns” or “group” other elements is considered at a higher level
than the owned (grouped) elements.
Interface: (1) a shared boundary or connection between two dissimilar objects, devices or
systems through which information is passed. The connection can be either physical or
logical. (2) a named set of operations that characterize the behavior of an entity
Item: that which can be individually described or considered. See also Component,
Element, Unit, Module. KDM Entity: a meta-model element (as well as the corresponding model elements) that
represents a thing of significance of the system of interest, about which information needs
to be known or held. A KDM entity is an abstraction of some element of the system of
interest that has a distinct, separate existence objective or conceptual reality, a selfcontained
piece of data that can be referenced as a unit. As a model element each KDM
entity is an instance of some specific meta-model element and it usually the endpoint of
distinct KDM relationships.
KDM instance: a collection of KDM model elements that represent one or more views of
the system of interest.
KDM model: a meta-model element (as well as the corresponding model elements) that is
a container for a KDM view
KDM Relationship: a meta-model element (as well as the corresponding model elements)
that represents some semantic association between elements of the system of interest. All
KDM relationships are binary. As a model element each KDM relationship is an instance
of some specific meta-model element.
Meta-model: A special kind of model that specifies the abstract syntax of a modeling
language. The typical role of a metamodel is to define the semantics for how model
elements in a model get instantiated. A model typically contains model elements. These
are created by instantiating model elements from a metamodel, i.e., metamodel elements.
Meta-model element: an element of a meta-model from which model elements are
instantiated.
Model: A model represents a system of interest, from the perspective of a related set of
concerns. The model is related to the system by an explicit or implicit isomorphism.
Models are instances of MOF meta-models and therefore consist of model elements and
links between them.
Model element: instance of a meta-model element
Module. (1) A program unit that is discrete and identifiable with respect to compiling,
combining with other units, and loading; for example, the input to, or output from, an
assembler, compiler, linkage editor, or executive routine. (2) A logically separable part of
a program.
Resource: any physical or virtual component of limited availability within a computer
system available for a given purpose and managed by the runtime platform.
Runtime platform: the set of hardware and software components that implement the
services utilized by the application software. A runtime system generally controls how
several tasks are scheduled to run, and manages resources. Its provisions for the
programmer typically form an Application Programming Interface— a set the welldocumented
ways of using the system.
Segment: A collection of data that corresponds to one or more coherent views of a
system of interest that is stored or transferred as a unit. Software artifact: A software artifact is a tangible machine-readable document created
during software development. Examples are requirement specification documents, design
documents, source code and executables.
Software asset: A software asset is a description of a partial solution (such as a
component or design document) or knowledge (such as requirements database or test
procedures) that engineers use to build or modify software products. A software asset is a
set of one or more related artifacts that have been created or harvested for the purpose of
applying that asset repeatedly in subsequent contexts. The asset consumer is an architect
or a designer of any type of IT or business process solutions from solution business
modeling, analysis (assets used are models) and design to application development
(assets used are pieces of code).
Traceability: The degree to which a relationship can be established between two or more
products of the development process, especially products having a predecessor-successor
or master-subordinate relationship to one another; for example, the degree to which the
requirements and design of a given software component match.
Unit : (1) a piece or complex of apparatus serving to perform one particular function (2) A
software element that is not subdivided into other elements.
User interface: An interface that enables information to be passed between a human user
and hardware or software components of a computer system.
View: A representation of a whole system from the perspective of a related set of
concerns.
Viewpoint: A specification of the conventions for constructing and using a view. A
pattern or template from which to develop individual views by establishing the purposes
and audience for a view and the techniques for its creation and analysis.