KDM12 — ISO standard documents are described with "shall", "should" and "may" (JP-8)

Suggested resolution: Define this standard with "shall", "should" and "may".

Modify table 2.1 Compliance statement by adding phrase “Compliant tool shall: in each cell and
adding bullets to each requirement.
Make the following editorial changes:
L0 Import-Analysis:
Change:
support specified mapping between KDM and existing model in the tool;
into
implement mapping between KDM and existing internal representation of the tool;
Add word “support”:
extend operations of existing tool to support traceability to the physical artifacts of the application
from Source package.
Add word “demonstrate” in front to “L0 compliance”
In semantic sections – change “it is implementer’s responsibility” to “the implementer shall”
(below we only show the new version of the sentence with the changed phrase underlined):
Source package:
Page 45
The implementer shall arrange inventory elements into one or more inventory models. KDM import tools
shall not make any assumptions about the organization of inventory items into inventory models.
Page 47:
The implementer shall provide a mapping from concrete types of the physical artifacts involved in the
engineering of the existing software system into concrete subclasses of the InventoryItem. The
implementer shall map each artifact of the existing software system to some instance of KDM
InventoryItem.
Page 51:
The implementer shall capture certain aspects knowledge of the engineering process in the form of
“DependsOn” relations between inventory items.
Page 53:
The implementer shall provide adequate traceability links.
Code package The implementer shall arrange code elements into one or more code models.
Page 65
The implementer shall select an appropriate subclass of the Module element.
Page 66
The implementer shall add such files to the InventoryModel.
Page 110
Change “The implementer will have the choice to either”
into
The implementer shall either:
Page 112
Change “This is up to the implementer” into
The implementer may provide additional information using stereotypes.
Page 113
Change “KDM does not restrict implementers whether to clone the included code
elements or to reuse them and keep a single copy in the SharedUnit. However, many
KDM implementations will usually clone the elements of the SharedUnit. “ into
The implementer may either clone the included code elements or to reuse them and keep a single copy in
the SharedUnit. The recommended approach is to clone the elements of the SharedUnit.
Page 114
The implementer shall select a particular strategy to represent macro units
Page 116
The implementer shall identify and represent associations between MacroUnits, as well as a
MacroDirective and the corresponding MacroUnit according to the semantics of the preprocessor.
Page 119
The implementer shall identify and represent include relationships according to the semantics of the
particular preprocessor.
Page 120
The implementer shall identify and represent the variants and associations between the “generated” code
and the corresponding conditional directive according to the semantics of the preprocessor.
Page 121
The implementer shall identify and represent redefinitions of macro units according to the semantics of the
particular preprocessor.
Page 123
The implementer shall make an adequate decision on how to associate line comments with the surrounding
elements in the source code.
Page 127 The implementer shall identify and represent import directives and their targets according to the semantics
of the programming language of the existing software system.
Action package
Page 131
The implementer shall select the granularity of the action elements.
Page 131
The implementer shall map programming language statements and other descriptions of behavior into
KDM ActionElements.
Page 134
The implementer shall map control flow mechanisms of the given programming language into ControlFlow
meta-elements. The implementer shall adequately represent the control flows of the existing system by a set
of action elements and ControlFlow relationships between them.
Page 150
The implementer shall identify and represent these associations according to the semantics of the
programming language of the existing software system.
Micro actions
Page 154; constraint 1 “should” change into “shall”
Platform package
Page 165
The implementer shall arrange platform elements into one or more platform models.
Page 168
The implementer shall identify runtime resources used by the existing software system according to the
semantics of the platform used by the existing system, resource configuration files, and other appropriate
sources of information.
Page 175
The implementer shall correctly associate the platform resource with the corresponding logical definition of
this resource (usually a Signature, an Interface, or a Package).
UI package
Page 184
The implementer shall arrange user-interface elements into one or more UIModel containers.
Page 185
The implementer shall map specific user interface element types determined by the particular user-interface
system of the existing software system, into concrete subclasses of the AbstractUIElement. The
implementer shall map each user interface element into some instance of the AbstractUIElement.
Implementation elements are one or more ComputationalObjects or ActionElements from some
CodeModel that are represented by the current UI element. “Abstraction” actions may be used to represent
precise semantics of the UI Element. Page 185
The implementer shall map specific user interface association types determined by the particular userinterface
system of the existing software system, into concrete subclasses of the AbstractUIRelationship.
The implementer shall map each user interface association into some instance of the
AbstactUIRelationship.
Event package
Page 196
The implementer shall arrange event elements into one or more event models.
Data package
Page 208
The implementer shall arrange the instances of the data elements into one or more DataModels.
Build package
Page 285
The implementer shall capture the input build elements for a certain build step in the form of “Consumes”
relation.
Page 286
The implementer shall capture the output build elements for a certain build step in the form of “Produces”
relation.
Page 286
The implementer shall capture the required Tool elements for a certain build step in the form of
“SupportedBy” relation.
Page 287
The implementer shall capture the origin of build elements in the form of “SuppliedBy” relation.
Page 287
The implementer shall capture the description of a certain build step in the form of “DescribedBy” relation
to some BuildDescription element.