Plug-Fest Scope in Relation to the Technologies
This page discusses the scope of the Plug-Fest with consideration of the
technologies that the various standards use to support (formally describe and enforce)
conformance to normative requirements of the specification.
Each of the relevant technologies (UML, STEP, CADM) provides its own notion of
what could be called 'the well-formedness of units of information exchanged.'
In this terminology, we might say that a specification describes required conditions
on that form, and that each of UML, STEP and CADM provide support, in the form of
an architecture, for its notion of well-formedness. Implementors of each technology
ensure that their tools respect the requirements of that architecture, without which
their implementation cannot be said to be conforming.
Our interest is primarily in improving SE tool interoperability (within a technology,
and across technologies). Some aspects of each architecture relate strongly to this goal.
Other aspects are less directly relevant. For example, an aspect may concern the exchange of files
without regard to the content (the content might not even concern systems engineering).
In principle, the structure of files exchanged is outside the scope of the Plug-Fest.
But in practice it may be an essential pre-conditions to running the Plug-Fest.
The following is an attempt to outline
a perspective on the relationship of the architectures of the technologies to the scope
and goals of the Plug-Fest.
The purpose of this discussion is to help participants frame the scope of the Plug-Fest.
SysML
There are four 'kinds of rules' relevant to this UML technology:
- Rules that govern the structure of metamodels (instances of MOF)
- The MOF spec defines these.
- An example of a rule of this type is the stipulation that a the multiplicity of
Association::memberEnd is limited to 2. (Section 14.3 of the MOF Spec).
- Rules that define the 'UML+SysML metamodel' as an information model with SE domain content
- The purpose of this metamodel is to allow the
expression of SysML's view of the part of the SE domain SysML concerns. The rules govern the
representation of objects and relationships in the SE domain.
- An example of a rule of this type is the stipulation that a connector shall be owned by the most immediate
block that owns both ends. (Section 8.3.1.3 of the SysML Spec).
- Note: Of course, strictly speaking, a 'UML+SysML metamodel' does not exist;
SysML is a profile defined on UML. Nonetheless, for the sake of this discussion, we can view this
composition of the UML metamodel + SysML profile as such.
- The SysML spec and the files UML4SysML.cmof and SysMLProfile.xml define these.
- Rules that govern how objects and relationships in the domain
are to be encoded in an instance of a metamodel, for exchange
- 'a metamodel' here is that defined by (2), for SysML.
- The XMI Specification, Section 6, "XML Document Production," provides many example of
this type of rule.
- Rules that govern how an instance is to be presented as a diagram
- The SysML spec defines these.
About these four kinds of rules, we can say the following:
(1) is out of scope of the Plug-Fest. The UML metamodel and SysML profile presumably
conform to these rules. If they don't, building tools (including validation tools)
would be difficult.
(2) is entirely within the scope of the Plug-Fest. These rules concern the
expression of SE content in SysML.
(3) is what the XMI Certification Program is doing. Conformance to XMI is a pre-condition
to successful interoperation. In as far as non-conformance to XMI is an impediment to
testing in areas (2) and (4), we may need to get involved.
(4) is something that we might do in the Plug-Fest as a way to ensure that
the content of exchanges is comprehended. That is, some tools can display
the information graphically. If so, we can check that what is presented is
consistent with what we intended to be conveyed in the exchange.
AP233
AP233 is built on STEP technology. STEP modularization, the EXPRESS
information modeling language, and the Part 28 encoding of content
are the key aspects of the architecture.
There are three 'kinds of rules' relevant to this STEP technology:
- Rules that govern the composition of modules into an information model
- These are the rules of STEP Modularization
- Rules that govern the structural form of entities, the domain of values
that their properies may take, and the presence of particular entities in the unit of exchange
- These are rules embodied in the EXPRESS schema of AP233.
- Rules that govern the encoding of the unit of exchange in XML
- These are the rules of ISO 10303-28
About these three kinds of rules, we can say the following:
(1) is out of scope of the Plug-Fest. The AP233 schema and other STEP
schema that might be of interest (e.g. PLCS) are presumably conformant
to the rules of STEP modularization.
(2) is entirely within the scope of the Plug-Fest.
These rules concern the expression of SE content in AP233.
(3) is largely out of scope of the Plug-Fest.
Conformance to Part 28 is a pre-condition to successful interoperation.
In as far as non-conformance is an impediment to testing in area (2),
we may need to get involved.CADM
CADM defines relational and XML schema for query, exchange, and the definition
of repositories. The information content of CADM follows the DoDAF.
Further discussion of CADM will be provided soon.