KDM12 — Align KDM Package with ISO Architecture Views (rh-10)

Related to 8.2, Part I

"Each KDM package defines several entity types representing specific abstractions related to a certain viewpoint on existing software systems."

The architectural viewpoints being employed should be made explicit, and defined as per ISO 42010

Add definitions of architecture viewpoints for each package that defines an architectural viewpoint:
Section 11.1 Page 43 Inventory architecture viewpoint
Concerns:
• What are the artifacts (software items) of the system?
• What is the general role of each artifact (for example, is it a source file, a binary file, an
executable or a configuration description)?
• What is the organization of the aritifacts (into directories and projects)?
• What are the dependencies between the artifacts?
Viewpoint language:
Inventory views conform to KDM XMI schema. The viewpoint language for the Inventory
architectural viewpoint is defined by the Source package. It includes an abstract entity
AbstractInventoryElement, several generic entities, such as InventoryItem and InventoryContainer, as well
as several concrete entities, such as SourceFile, BinaryFile, Image, Directory, etc. The viewpoint language
for the Inventory architectural viewpoint also includes DependsOn relationship, which are subclasses of
AbstractInventoryRelationship.
Analytic methods:
The Inventory architectural viewpoint supports the following main kinds of checking:
• What artifacts depend on the given artifact?
The Inventory viewpoint also supports check in combinations with other KDM architectural
viewpoint to determine the original artifacts that correspond to a given KDM element.
Construction methods:
• Inventory views that correspond to the KDM Inventory architectural viewpoint are
usually constructed by directory scanning tools, which identify files and their types.
• Construction of an Inventory view is determined by the particular development and
deployment environments of the existing software system
• Construction of an Inventory view is determined by the semantics of the environment as
well as the semantics of the corresponding artifacts, and it based on the mapping from the
given environment to KDM The mapping from a particular environment to KDM may produce additional information
(system-specific, or environment-specific, or extractor tool-specific). This information
can be attached to KDM elements using stereotypes, attributes or annotations
Change sentence: It represents the convergence between the KDM intermediate representation and the
application source it represents.
Into
It represents the association between the KDM model and the artifacts it represents.
Part II Program Elements Page 57 Code architecture viewpoint
Concerns:
• What are the computational elements of the system?
• What are the modules of the system?
• What is the low-level organization of the computational elements?
• What are the datatypes used by the computational elements?
• What are the units of behaviour of the system?
• What are the low-level relationships between the code elements, in particular what are the
control-flow and data-flow relationships ?
• What are the important non-computational elements?
• How computational elements and modules are related to the physical artifacts of the
system?
Viewpoint language:
Code views conform to KDM XMI schema The viewpoint language for the Code architectural
viewpoint is defined by the Code and Action packages. It includes several abstract entities, such as
AbstractCodeElement and CodeItem, several generic entities, such as Datatype, ComputationalObject and
Module, as well as several concrete entities, such as StorableUnit, CallableUnit, CompilationUnit and
ActionElement. The viewpoint language for the Code architectural viewpoint also includes several
relationships, which are subclasses of AbstractCodeRelationship and AbstractActionRelationship.
Analytic methods:
The Code architectural viewpoint supports the following main kinds of checking:
• Composition (for example, what code elements are owned by a CompilationUnit,
SharedUnit or a CodeAssembly; what action elements are owned by a CallableUnit)
• Data flow (for example, what action elements read from a given StorableUnit; what
action elements write to a given StorableUnit; what action elements create dynamic
instances of a given Datatype; what action elements address a particular StorableUnit;
what data element are being read as actual parameters in a call)
• Control flow (for example, what CallableUnit is used in a call; what action element is
executed after the given action element; what action elements are executed before the
given action element; what data element is used to dispatch control flow from a given
action element; what action element is executed after the given element under what
conditions; what is the exceptional flow of control; what action elements are executed as
entry points to a given module or a CallableUnit)
• Datatypes (for example, what is the datatype of the given storable unit; what is the base
datatype of the given pointer type; what is the base datatype of the given element of the
record type; what is the signature of the given CallableUnit)
Other kind of checking are related to the interfaces, templates and pre-processor. All
relationships defined in the Code model are non-transitive. Additional computations are
required to derive, for example, all action elements that can be executed after the given action
element, or all CallableUnits that a given action element can dispatch control to. The KDM mechanism of aggregated relationship is used to derive relationships between
KDM elements that own or reference various Code elements (usually, Module and
CodeAssembly) based on the low-level relationship between individual Code elements
Construction methods:
• Code views that correspond to the KDM Code architectural viewpoint are usually
constructed by parser-like tools which take artifacts of the system as the input and
produce one or mode Code views as output
• Construction of the Code view is determined by the syntax and semantics of the
programming language of the corresponding artifact, and it based on the mapping from
the given programming language to KDM; such mapping is specific only to the
programming language and not to a specific software system
• The mapping from a particular programming language to KDM may produce additional
information (system-specific, or programming language-specific, or extractor toolspecific).
This information can be attached to KDM elements using stereotypes, attributes
or annotations
Section 15.1, page 163 KDM Platform architecture viewpoint
Concerns:
• What are the resources used by the software system?
• What elements of the run-time platform are used by the software system?
• What behaviour is associated with the resources of the run-time platform?
• What control flows are initiated by the events in the resources?
• What control flows are initiated by the run-time environment?
• What are the bindings to the run-time environment?
• What are the deployment configurations of the software system?
• What are the dynamic/concurrent threads of activity within the software system?
Viewpoint language:
Platform views conform to KDM XMI schema The viewpoint language for the Platform
architectural viewpoint is defined by the Platform package. It includes an abstract entity
AbstractPlatformElement, several generic entities, such as ResourceType, RuntimeResource, as well as
several concrete entities, such as PlatformAction, PlatformEvent, ExternalActor, MarshalledResource,
NamingResource, etc. The viewpoint language for the Platform architectural viewpoint also includes
several relationships, which are subclasses of AbstractPlatformRelationship.
Analytic methods:
The Platform architectural viewpoint supports the following main kinds of checking:
• Data flow (for example, what action elements read from a given resource; what action
elements write to a given resource; what action elements manage a given resource;
including indirect data flow using a MarshalledResource or a MessagingResource where
a particular resource is used to perform a data flow between the “send” action element
and the “receive” action element)
• Control flow (for example, what action elements are triggered by events in a given
resource; what action elements operate on a given resource)
• Identify of resource instances based on resource handles in various modules
Platform Views are used in combination with Code views and Inventory views.
Construction methods:
• Platform views that correspond to the KDM Platform architectural viewpoint are usually
constructed by analyzing Code views for the given system as well as the platformspecific
configuration artifacts. The platform extractor tool uses the knowledge of the
API and semantics for the given run-time platform to produce one or mode Platform
views as output As an alternative, for some languages like Cobol, in which the elements of the run-time
platform are explicitly defined by the language, the platform views are produced by the
parser-like tools which take artifacts of the system as the input and produce one or mode
Platform views as output (together with the corresponding Code views)
• Construction of the Platform view is determined by the semantics of the run-time
platform, and it based on the mapping from the given run-time platform to KDM; such
mapping is specific only to the run-time platform and not to a specific software system
• The mapping from a particular run-time platform to KDM may produce additional
information (system-specific, or platform-specific, or extractor tool-specific). This
information can be attached to KDM elements using stereotypes, attributes or annotations
Section 16.1, page 183 UI architecture viewpoint
Concerns:
• What are the distinct elements of the user interface of the systems?
• What is the organization of the user interface?
• How user interface uses artifacts of the system (for example, images) ?
• What data flows originate from the user interface ?
• What data flows output to the user interface?
• What control flows are initiated by the user interface?
Viewpoint language:
UI views conform to KDM XMI schema The viewpoint language for the UI architectural
viewpoint is defined by the UI package. It includes an abstract entity AbstractUIElement, several generic
entities, such as UIResource, UIDisplay, as well as several concrete entities, such as Screen, Report,
UIField, UIAction, UIEvent, etc. The viewpoint language for the UI architectural viewpoint also includes
several relationships, which are subclasses of AbstractUIRelationship.
Analytic methods:
The UI architectural viewpoint supports the following main kinds of checking:
• Data flow (for example, what action elements read from a given UI element; what action
elements write to a given UI element; what action elements manage a given UI element)
• Control flow (for example, what action elements are triggered by events in a given UI
element; what action elements operate on a given UI element)
• Workflow (what UI elements will be displayed after the given one; what UI elements are
displayed before the given one)
UI Views are used in combination with Code views and Inventory views.
Construction methods:
• UI views that correspond to the KDM UI architectural viewpoint are usually constructed
by analyzing Code views for the given system as well as the UI-specific configuration
artifacts. The UI extractor tool uses the knowledge of the API and semantics for the given
run-time platform to produce one or mode UI views as output
• As an alternative, for some languages like Cobol, in which the elements of the UI are
explicitly defined by the language, the UI views are produced by the parser-like tools
which take artifacts of the system as the input and produce one or mode UI views as
output (together with the corresponding Code views)
• Construction of the UI view is determined by the semantics of the UI platform, and it
based on the mapping from the given UI platform to KDM; such mapping is specific only
to the UI platform and not to a specific software system
• The mapping from a particular UI platform to KDM may produce additional information
(system-specific, or platform-specific, or extractor tool-specific). This information can be
attached to KDM elements using stereotypes, attributes or annotations Section 17.1, page 195 Event architecture viewpoint
Concerns
• What are the distinct states involved in the behaviour of the software system?
• What are the events that cause transitions between states?
• What action elements are executed in a given state?
Viewpoint language:
Event views conform to KDM XMI schema The viewpoint language for the Event architectural
viewpoint is defined by the Event package. It includes an abstract entity AbstractEventElement, generic
entity EventResource, UIDisplay, as well as several concrete entities, such as State, Transition, Event,
EventAction, etc. The viewpoint language for the UI architectural viewpoint also includes several
relationships, which are subclasses of AbstractEventRelationship.
Analytic methods:
The Event architectural viewpoint supports the following main kinds of checking:
• Reachability (for example, what states are reachable from the given state)
• Control flow (for example, what action elements are triggered by a given state transition;
what action elements will be executed for a given traversal of the state transition graph)
• Data flow (what data sequences correspond to a given traversal of the state transition
graph)
Event Views are used in combination with Code views, Data views, Platform views and
Inventory views.
Construction methods:
• Event views that correspond to the KDM Event architectural viewpoint are usually
constructed by analyzing Code views for the given system as well as the configuration
artefacts specific to the event-driven framework. The Event extractor tool uses the
knowledge of the API and semantics of the event-driven framework to produce one or
mode Event views as output
• Construction of the Event view is determined by the semantics of the event-driven
framework, and it based on the mapping from the given event-driven framework to
KDM; such mapping is specific only to the event-driven framework and not to a specific
software system
• The mapping from a particular event-driven framework to KDM may produce additional
information (system-specific, or platform-specific, or extractor tool-specific). This
information can be attached to KDM elements using stereotypes, attributes or annotations
Section 18.1, page 207 Data architecture viewpoint
Concerns
• What is the organization of persistent data in the software systems?
• What are the information model supported by the software system?
• What action elements read persistent data?
• What action elements write persistent data?
• What control flows are determined by the events corresponding to persistent data?
Viewpoint language
Data views conform to KDM XMI schema The viewpoint language for the Data architectural
viewpoint is defined by the Data package. It includes abstract entities AbstractDataElement,
AbstractContentElement, generic entities DataResource, DataContainer, ContentItem, as well as several
concrete entities, such as Catalog, RelationalSchema, DataEvent, DataAction, ColumnSet,
RecordFile,XMLSchema, etc. The viewpoint language for the Data architectural viewpoint also includes
several relationships, which are subclasses of AbstractDataRelationship. Analytic methods:
The Data architectural viewpoint supports the following main kinds of checking:
• Data aggregation (the set of data items accessible from the given ColumnSet by adding
data items through foreign key relationships to other tables)
Data Views are used in combination with Code views and Inventory views.
Construction methods:
• Data views that correspond to the KDM Data architectural viewpoint are usually
constructed by analyzing Data Definition Language artifacts for the given data
management platform. The Data extractor tool uses the knowledge of the data
management platform to produce one or mode Data views as output
• As an alternative, for some languages like Cobol, in which some elements of the Data are
explicitly defined by the language, the Data views are produced by the parser-like tools
which take artifacts of the system as the input and produce one or mode Data views as
output (together with the corresponding Code views)
• Construction of the Data view is determined by the semantics of the data management
platform, and it based on the mapping from the given data management platform to
KDM; such mapping is specific only to the data management platform and not to a
specific software system
• The mapping from a particular data management platform to KDM may produce
additional information (system-specific, or platform-specific, or extractor tool-specific).
This information can be attached to KDM elements using stereotypes, attributes or
annotations
Section 19.1, page 255 Structure architecture viewpoint
Concerns:
• What are the structural elements of the system, and what is the organization of these
elements?
• What software elements compose the system?
• How the structural elements of the system are related to the computational elements?
• What are the connections of these elements based on the relationships between the
corresponding computational elements?
• What are the interfaces of the structural elements of the system?
Viewpoint language:
Structure views conform to KDM XMI schema The viewpoint language for the Structure
architectural viewpoint is defined by the Structure package. It includes abstract entitity
AbstractStructureElement, and several concrete entities, such as Subsystem, Layer, Component,
SoftwareSystem, ArchitectureView. The viewpoint language for the Structure architectural viewpoint also
includes an abstract relationship AbstractStructureRelationship.
Analytic methods:
The Structure architectural viewpoint supports the following main kinds of checking:
• Attachment (are components properly connected?)
• Coupling and cohesion (the number of internal relationship within a component
compared to the number of relationships to other components)
• Efferent and afferent relationship (uses of a component by other components and usages
of other component by the given component)
• Interfaces (what is the required and provided interface of the given component)
Structure Views are used in combination with Code views, Data views, Platform views, UI
views and Inventory views.
Construction methods: Structure views that correspond to the KDM Structure architectural viewpoint are usually
constructed by analyzing architecture models of the given system. The Structure extractor
tool uses the knowledge of the architecture models to produce one or mode Structure
views as output
• As an alternative, structure views can be produced manually using the input from the
architect of the system and architecture documentation
• Construction of the Structure view is determined by the architectural description of the
system
• Construction of the Structure views corresponding to a particular architectural description
may involve additional information (system-specific or architecture-specific). This
information can be attached to KDM elements using stereotypes, attributes or annotations
Section 20.1, page 261 Conceptual architecture viewpoint
Concerns:
• What are the domain terms implemented by the system?
• What are the behaviour elements of the system?
• What are the business rules implemented by the system?
• What are the scenarios supported by the system?
Viewpoint language:
Conceptual views conform to KDM XMI schema The viewpoint language for the Conceptual
architectural viewpoint is defined by the Conceptual package. It includes abstract entitity
AbstractConceptualElement, and several concrete entities, such as TermUnit, FactUnit, RuleUnit, Scenario,
BehaviorUnit. The viewpoint language for the Conceptual architectural viewpoint also includes
ConceptualFlow relationship, which is a subclass of an abstract relationship
AbstractConceptualRelationship.
Analytic methods
The Conceptual architectural viewpoint supports the following main kinds of checking:
• Conceptual relationships (what are the relationships between conceptual entities, based
on their implementation by the Code and Data entities?)
• Scenario flow (what are the control flow relationship between the two scenarios based on
the flow between action elements referenced by each scenario)
• BehaviorUnit coupling (what are the control flow and data flow relationships between
two behaviour units based on the action elements referenced by each behaviour unit)
• Business Rule analysis (what is the logic of the business rule based on the action
elements referenced by the business rule)
Conceptual Views are used in combination with Code views, Data views, Platform views, UI
views and Inventory views.
Construction methods:
• Conceptual views can be produced manually using the input from the information
analysis and the architect of the system and architecture documentation
• Construction of the Conceptual view is determined by the domain model and the
architectural description of the system
• Construction of the Conceptual views corresponding to a particular architectural
description may involve additional information (system-specific or architecturespecific).
This information can be attached to KDM elements using stereotypes, attributes
or annotations
Section 21.1, page 279 Build architecture viewpoint
Concerns:
• What are the inputs to the build process? What artifacts are generated during the build process?
• What tools are used to perform build steps?
• What is the workflow of the build process?
• Who are the suppliers of the source artifacts?
Viewpoint language
Build views conform to KDM XMI schema The viewpoint language for the Build architectural
viewpoint is defined by the Build package. It includes abstract entity AbstractBuildElement, a generic
entity BuildResource as well as several concrete entities, such as BuildComponent, BuildStep,
BuildProduct, BuildDescription, Library. The viewpoint language for the Build architectural viewpoint also
includes several build relationships, which is a subclass of an abstract relationship
AbstractBuildRelationship.
Analytic methods
• Supply chain analysis (what are the artifacts that depend on a given supplier)
Build Views are used in combination with Inventory views.
Construction methods:
• Build views that correspond to the KDM Build architectural viewpoint are usually
constructed by analyzing build scripts and build configuration files for the given system.
This inputs are specific to the build automation framework. The Build extractor tool uses
the knowledge of the semantics of the build automation framework to produce one or
mode Build views as output
• Construction of the Build view is determined by the semantics of the build automation
framework, and it based on the mapping from the given build automation framework to
KDM; such mapping is specific only to the build automation framework and not to a
specific software system
• The mapping from a particular build automation framework to KDM may produce
additional information (system-specific, or platform-specific, or extractor tool-specific).
This information can be attached to KDM elements using stereotypes, attributes or
annotations