pages are blank
in section 6 and elsewhere I think 'Class Library' (which does not exist as a UML concept) should be 'Model Library' (which does).
Section 6 lists the XMI files 'for the compliance levels' which include those for the 'formal metamodel'. However the formal metamodel is currently in a non-normative Annex. Personally I would like to make the metamodel a proper compliance point.
CapabilityRequirementCapability is duplicated by stereotyped association and relation via subject/usecase metaproperties (as implied by OCL constraints)
CapabilityOperationalCapability is duplicated by stereotyped association and relation via subject/usecase metaproperties (as implied by OCL constraints)
Connection between OperationalActivity and SystemFunction is not clearly traceable. This has effect on SV-5 generation.
Stereotyped associations do not speicfy their end types. Stereotypes that are related to other stereotypes through stereotyepd relationships are specified in their diagrams with association to the other stereotypes and redundantly in their Associations section. Apply the agreed upon diagram notation using steretyped dependencies - non normatinve notation used i the profile specificaton and remove all redundant associations.
Attribute for compatibility with MODAF. Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of
Missing stereotype for compatibility with MODAF. Resolution:Add stereotype extending Association to model composition of Capabilities both ends constrained to be Capability
Missing instance stereotype for compatibility with MODAF. Summary:We need a correspoinding instance stereotype,
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of Competence
Missing instance stereotype for compatibility with MODAF. Summary:OrganizationType closely corresponds to OrganizationalResource in UPDM, but we need an instance stereotype corresponding to OrganizationalResource
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of OrganizationalResource
Missing instance stereotype for compatibility with MODAF. Summary:PostType is very similar to OperationalCapabilityRole in UPDM, but we don't have a corresponding instance stereotype.
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of OperationalCapabilityRole
Service Specification can be either an interface or a class. It only extends interface. Resolution:Add Class extension
Revised Text:
8.6.20.1 Extension
o Interface (from UML2)
· Class (from UML2)
These Elements should also specialize ConformingElement
Summary:Goal - p
· Competence-p,s
· Capability-p,s
· OerationalNode-p,s
· Service-p,s
· OperationalNodePort-p,s
· SystemPort-p,s
· CapabilityConfiguration-p,s
· Effect-p
· OperationalActivity-p
· CommunicationPort-p,s
· SystemTask-p
· OperationalTask-p
· SystemsNode-p
· CapabilityRequirement-p
· CommunicationsPath-p
· CommunicationsLink-p,s
· DataElement-p
· DataExchange-p
· Information Element-p
· InformationExchange-p
· System-p,s
· SystemFunction-p,s
· SystemInterface-p,s
· Technical Standards Profile
Resolution:Add check for zero
8.4.29.3 Description - Missing association to Rule - fix diagram. :8.4.29.3 Associations
<<add>>
adheresToRules : Rule [*] Rules to which this OperationalTask adheres
Resolution:Add check for zero
Revised Text: adheresToRules : Rule [*] Rules to which this OperationalTask adheres
Typo input pin and output pin. Resolution:Fix text
Revised Text: [1] Asserts that if the source of the object flow is an outputpin, OutputPin then if the owner of the output pin is a CallBehaviorAction then its behavior is an OperationalActivity, or a CallOperationAction then its operation is an OperationalTask.
[2] Asserts that if the target of the object flow is an Input Pin, InputPin then the owner of the Input pin must be an OperationalAction - a CallBehaviorAction whose behavior is an OperationalActivity, or a CallOperationAction whose operation is an OperationalTask.
[3] The type of the input or output pin InputPin or OutputPin must be an InformationElement.
Constraints [1],[2],[3],[4],[5] OCL doesn't check for zero or more. Resolution:Add check for zero
Revised Text: [1] Asserts that this OperationalTask adheres to zero or more Rules
self.adheresToRules ->notEmpty() implies
self.adheresToRules > forAll(getAppliedStereotype('UPDM::Rule')>notEmpty())
[2] Asserts that this OperationalTask adheres to zero or more Policies
self.adheresToPolicy->notEmpty() implies
self.adheresToPolicy-> forAll(getAppliedStereotype('UPDM::Policy')->notEmpty())
3] Asserts that there are zero or more Doctrines that govern this OperationalTask self.governedByDoctrine->notEmpty() implies
self.governedByDoctrine->forAll(getAppliedStereotype('UPDM::Doctrine')- >notEmpty())
[4] Asserts that Materiel is utilized by this OperationalTask
self.utilizesMateriel->notEmpty() implies
self.utilizesMateriel-> forAll(getAppliedStereotype('UPDM::Materiel')->notEmpty())
[5] Asserts that the Triggers of this OperationalTask can be stereotyped Trigger, a callEventAction
self.triggeredByEvents->notEmpty() implies
self.triggeredByEvents->forAll(getAppliedStereotype('UPDM::Trigger') -> notEmpty())
Typo -of should be or. Fix text
Revised Text: 8.4.19.3 Description A flow of control of or energy from one activity node to another.
Multiplicity and description for goals and StrategicMission are wrong. Summary:o goals : Goal [*] The Goals that are to be realized by the Strategic Mission and this capability
o strategicMission : StrategicMission [*] The Strategic Missions supported by this OperationalCapability o
Resolution:Add check for zero
Revised Text: o goals : Goal [1..*] The Goals that are to be realized by the Strategic Mission and this OperationalCapability
strategicMission : StrategicMission [1..*] The Strategic Missions supported by this OperationalCapability
remove Materiel,CapabilityRequirement and Capability
Missing stereotype for ArchitectureSummary. Summary:The classifier for ArchitectureDescription::architectureSummary is constrained to be ArchitectureSummary which means we have to have an instance of the Class ArchitectureSummary, but there is no stereotype for that.
Resolution: There should be a stereotype "ArchitectureSummary" that specializes InstanceSpecification.
typos in association names. Resolution:fix text
Revised Text: activity : OperationalActivity [*] This policy governs these Activities o
operationaltask operationalTask: OperationalTask [*] OperationalTasks governed by this Policy o
SystemFunction systemFunction: SystemFunction [*] SystemFunctions governed by this Policy o
systemtasksystemTask : SystemTask [*] SystemTasks governed by this Policy
OCL doesn't check for zero or more. Resolution:Add check for zero
Revised Text: [3] Asserts that the entries in policy are typed Policy
self.policy->notEmpty() implies
self.policy->forAll(getAppliedStereotype('UPDM::Policy')->notEmpty())
:materiel is listed as an association, but doesn't show up on the diagram. Resolution:It is actually a MaterielNode association, and should be removed.
Missing stereotype for compatibility with MODAF. Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of Location
isFielded is unnecessary, since "FieldedCapability" is defined as an instance of CapabilityConfigureatoin from MODAF
The package structure does not lend itself to reuse. Resolution:Add the following packages and move appropriate stereotypes to these packages
· Standards
· Viewpoint
· Requirement
· BMM
· Services
· Communications
· Parametrics
· ResourceCompetence
Existing Packages remain
· Acquisition
· Strategic
· Operational
· System
· TechnicalStandards
Figure is obsolete
OCL doesn't check for zero or more. Constraint[5] is unnecessary. [1] Asserts that zero or more effects affect this resource.
self.effect-> forAll(getAppliedStereotype('UPDM::Effect')->notEmpty())
Resolution:Add check for zero, delete [5]
Revised Text:
[1] Asserts that zero or more effects affect this resource.
self.effect->notEmpty() implies
self.effect-> forAll(getAppliedStereotype('UPDM::Effect')->notEmpty())
[5] Asserts that there is an association between a Competence and the OperationalCapabilityRole that requires it.
self.getAllAttributes()>asOrderedSet()>select(association->notEmpty() ).association->any (getAppliedStereotype('UPDM::OperationalCapabilityRoleResource')> notEmpty())>notEmpty()
Summary:
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of
this concept does not exist in MODAF
This stereotype is useless - delete. Delete Asset and AssetMapping stereotypes
Multiplicity wrong for goals - should be [1..*] fix diagram to show 1..* Goals required by vision and 1..* visions by goal. In 8.3.24.5 fix multiplicity and add a descriptionj for goals
Revised Text: o goals : Goal [1..*] The Goals that contribute to realizing the Vision
OCL doesn't check for zero or more. [1] Asserts that zero or more OperationalCapabilities have been designated as instrumental in achieving the StrategicMission.
self.operationalCapabilities-> forAll(getAppliedStereotype ('UPDM::OperationalCapability')->notEmpty())
Resolution:Add check for zero
Revised Text: self.operationalCapabilities->notEmpty() implies
self.operationalCapabilities-> forAll(getAppliedStereotype ('UPDM::OperationalCapability')->notEmpty())
constraint [5] OCL doesn't check for zero or more. Resolution:Add check for zero
Revised Text: [5] Asserts that the elements in the operationalInformationFlow are stereotyped OperationalInformationFlow
self.operationalInformationFlow->notEmpty() implies
self.operationalInformationFlow-> forAll(getAppliedStereotype('UPDM::OperationalInformationFlow')->notEmpty())
Constraints [1], [2] OCL doesn’t check for zero or more. Resolution:Add check for zero
Revised Text: [1] Asserts that this InformationElement is associated with an OperationalActivityFlow. self.operationalCapabilities->notEmpty() implies
self.operationalInformationFlow.getAppliedStereotype ('UPDM::OperationalInformationFlow')->notEmpty()
[2] Asserts that there are zero or more InformationExchanges that utilize this InformationElement self.operationalCapabilities->notEmpty() implies
self.informationExchange-> forAll(getAppliedStereotype ('UPDM::InformationExchange')->notEmpty())
the relationship to OperationalNode appears to indicate that the op nodes
are part of the SystemsNode. This is inappropriate, as in both DoDAF and MODAF
operational nodes are logical entities that perform operational activities. They may be
realised as SystemsNodes, but to show structure in this way is a misunderstanding of the
intent behind MODAF and DoDAF. This is a common misunderstanding amongst DoDAF
users which has been cleared up in the MODAF 1.1 documentation
as these are classes, it is unclear
how they are to be used. Do they represent generic actors in a service orchestration ?
There are no major issues with the TV area of UPDM. The definition of Standard would have to be
broadened for MODAF use. Also, it is not clear how TechnicalStandardsProfile could be used in
MODAF.
Standard in MODAF, this includes non-technical standards whereas the UPDM definition
seems to restrict it to systems standards
as in the operational views, these are UML operations linking Systems to
their behaviour. This is not done in MODAF M3, though it is a perfectly reasonable
approach.
the definition talks about SystemInterfaces. However, SystemInterface is
more of an abstract concept. Surely it is CommunicationLink that should connect
SystemPorts ?
now represented as resource interactions in MODAF v1.1
note that in MODAF 1.1, there are simply functions which are
performed by functional resources (systems, human roles, or capability configurations).
unclear whether this is a class of system or an individual system
it is not clear whether this is a group of individual systems (i.e. serial
numbered) or a grouping by type. Without this distinction, there may be semantic
interoperability issues between different tools and different architectures
this seems to indicate that an OperationalActivity can be
realised by an event trace or state model, which does not appear to make sense. Is it useful
to specify anything other than an op activity to system function mapping ? Also, this again
seems to relate to materiel, which further obscures the semantics of Materiel (if that is
possible).
it is often important to distinguish between an actual location, and a type of
location (e.g. “in theatre”, “behind enemy lines”, “maritime littoral”, etc.)
MODAF no longer uses this it simply has resource interactions that
carry data elements.
this seems to indicate an implementation of a service by a system. In the NATO
SOA views, the Service stereotype indicates a type of service which may be implemented by
many different means (the UPDM equivalent would seem to be ServiceSpecification)
this would appear to use an
interface to define a type of system and classes to deploy those systems. This seems rather
an unusual and complex approach given that UML now has composite structure models for
this purpose.
The SV area of UPDM covers MODAF and DoDAF reasonably well. The concern mentioned before
about lack of a clear logical-physical split from OV-SV is again apparent in the SV section though.
SystemsNodes can “house” Operational Nodes in UPDM, which is against the original intent of
DoDAF, and clearly against the rules in MODAF. The remaining concerns about the SV area are
mostly due to the change in MODAF 1.1 that extends SV-1,SV-4, etc. to cover human factors
see previous comment (issue 12075)
the UPDM model has CapabilityConfiguration in it, yet it relates
capabilities to resources which deliver them why then have CapabilityConfiguration ?
again, this would seem to be a misunderstanding of the
MODAF approach. OperationalCapability seems to link Capabilities to
CapabilityRequirements, but a capability manager would want to be able to specify capability
requirements in a broad sense without recourse to operational models.
this is not explicitly defined in MODAF there was much
resistance from the MODAF TWG to introducing special types of systems (the argument
was “where do you stop ?”). Instead, the MODAF Ontology is used to add semantics to the
basic M3 elements. This also applies to hardware, networks, software, etc.
this concept does not exist in MODAF
in MODAF, this is covered in SV-2 as a system port connection and
requires that ports be defined this is not required in UPDM
this Boolean attribute is meant to describe the fielded status of a
capability. However, the reality is far more complex the capability may be implemented
(and therefore fielded) in many possible ways. In addition, there are levels of fielding (IOC,
FOC). This problem may be related to the UPDM misunderstanding of the concept of
Capability.
the UPDM spec states “The Capability is expressed in terms of the Resources
required to implement the Capability”, which is in clear contradiction to the way capability is
used in the MOD and the MODAF Stratgic Views. The whole idea of the capability concept is
for architects to specify their requirements INDEPENDENTLY of how it is to be
implemented (i.e. the resources to be used are deliberately not stated).
the relationship to Milestone does not appear to follow the
current MODAF approach. In MODAF 1.0, CapabilityRequirement was a specialisation of
Capability that had performance metrics. In MODAF 1.1, CapabilityRequirement has been
removed altogether (Capability itself is sufficient).
this concept does not exist in MODAF (see comment on
OperationalCapability).
There are a number of concerns about this package in the UPDM specification. There does not
seem to be a clear understanding of what a capability is and how it relates to other parts of the
architecture; the logical (OV) and physical (SV). Capabilities in UPDM have a strong equipment and
systems focus. In MODAF and M3, capability an ability to do something, which may or may not be
achieved by procuring / using equipment e.g. it may be possible to provide a capability increment
simply by re-training soldiers
again, this may indicate a misunderstanding of the
capability approach in UK and US defence acquisition. The statement “Defines the
association between a CapabilityConfiguration and the Capabilities that are configured by it”
implies the capability is defined by the resources that realise it. This is not the case (see the
comment on Capability).
despite the word “capability” being in the name, a capability
configuration is firmly in the solution space, and therefore does not belong in the StV
package of the UPDM profile (this also applies to the related stereotypes).
the description suggests that an operational node “realises” capability,
which tends to give a rather physical slant to nodes. In MODAF (and DoDAF) operational
nodes are logical representations of the usage (or requirement for) capability in an
architecture. The realising systems are shown in the SVs (in MODAF, people and
organizations may also be part of the realisation). The physical aspect of UPDM’s
OperationalNode is reinforced by the enumeration NodeType, which allows an
OperationalNode to be an organization or type of organization. This is strictly against the
rules in MODAF, and probably against the original intent of DoDAF (though CADM does
allow it, and it is commonly found in DoDAF architectures).
this represents the flow of information, materiel, or energy
between activity nodes (typically, these are Actions). MODAF and DoDAF only cover the flow
of information between activities. If this is an attempt to replicate the MODAF node
connector concept, it is a misinterpretation node connectors are only intended to be
information flows on OV-2 diagrams they have no behavioural semantics.
it seems inappropriate to
model service consumption in this way. It does not allow the architect to show that a
particular node is both a consumer and a provider of different services. This approach
forces the architect to produce two nodes one for production and one for consumption
even when it is clearly the same node producing and consuming. The work done in
developing SOA views by UK and Sweden would seem to indicate that OV-2 is not
appropriate in a true SOA approach most SOA orchestration approaches map the
services to the activities that use them rather than to nodes. The nodes that produce and
consume services can then be derived by examining the activities they perform
event trace models apply to Materiel which is itself not clearly
defined, hence it is not clear what the event trace model would represent. In most MODAF
or DoDAF architectures, an OV-6c shows sequences of messages between operational
nodes here it would seem to allow other representations
this is defined as the “control of flow of energy from one activity
node to another”. Further clarification of semantics is required
this approach used UML Operations to link nodes to activities (though
the materiel object also seems to serve this purpose ?) and is not used in MODAF, where
instead a dependency is used to link nodes to operational activities
the definition describes it as the “state machine for OV-5”, yet
state models belong in OV-6b and typically describe the state transitions of operational
nodes (OV-2).
this is not explicitly defined as an element in MODAF. Instead, MODAF architects
use operational activities, and standards to define policy. It may be worth considering the
addition of this in a future MODAF release e.g. as a subtype of standard
refers to roles being played by OperationalNodes, which breaks the
MODAF rule about nodes being logical
it is not clear if this is an actual resource (e.g. Ian Bailey) or a
type of resource (e.g. EW Officer).
an enumeration “LineKind” is used to describe dotted, solid,
etc. lines. This kind of graphical specification seems inappropriate in a meta-model
(especially as this only seems to be specified for OrganizationalRelationship).
this would appear to duplicate the functionality of
the OperationalCapabilityRealization
as this is a solution specification, it would belong in the SVs in
MODAF.
this concept does not exist in MODAF. In addition, it subclasses into
OperationalServiceConsumer and OperationalServiceProvider which would appear to
prevent a node from being both a consumer and a provider of different services (this is very
common in SOA models).
see issue with OperationalCapabilityRealization (issue 12048)
MODAF does not use UML::Port for nodes
the semantics of this relationship are not explained. The same relationship
is used to relate Materiel to Operational Nodes, Systems, etc. without explaining the
semantics for each case.
this association links Material to UML behavioural elements. It seems
to allow Materiel to be linked to either operational behaviour elements or system behaviour
elements, which does not make sense. Without a clear definition for Materiel, it is not clear
whether the system behaviour or operational behaviour is correct. It is usual in DoDAF that
an operational node conducts operational activities, and a system conducts system
functions. Quite what UPDM’s Materiel is or does is something of a mystery.
the definition in UPDM does not appear to make sense (possibly as the result of
cut-and-paste problems ?). Later references to Materiel would seem to suggest that is the
supertype of all UPDM elements that can have behaviour. This is not apparent from its
name or from its definition, so cannot be confirmed
it is difficult to interpret the purpose of this from the definition (which
is somewhat Byzantine), but this seems in essence to be a relationship between an Op
Activity and a System Function to show that the System Function realises the Op Activity. If
this is the case, it seems strange that UPDM has not used the usual UML approach of a
dependency. Alternatively, it could be argued that as these are classes (i.e. types of activity),
then the system function is a special way of conducting an operational activity, so a
Generalisation relationship might be acceptable. The use of an Association seems very
unusual.
The Operational Views form the linchpin of a MODAF architecture they either serve to abstract
an as-is architecture into a logical structure, or present a logical requirement for a to-be
architecture. It is not at all clear that UPDM handles this. Of particular concern is the use of the
Materiel stereotype (see details below) which is not well defined and seems to connect logical and
physical elements with no clear semantics. The need for Material is also questionable it seems an
unnecessary element to create in order to associate other elements
this is a simple way to reference external information. To
accommodate the MODAF Ontology and IDEAS, a more sophisticated mechanism of
external specialisation, instantiation and equivalence will be required. This could be achieved
with some additions to the ExternalReferenceType enumeration, however
this has two attributes that are probably not specified clearly enough to be
useful. It has a “value”, which is a string representing its “value to the enterprise”. There is
no way a simple string like this could be used for any kind of analysis or decision support in a
repository. In addition, Resource extends class, implying it is a type of resource, yet it has an
attribute “type”.
in UPDM, this is a Stereotype of Class, whereas M3 uses
InformationItem.
this seems to be based on a poor understanding of DoDAF and MODAF.
Operational Nodes are logical “actors” whose functionality may be realised (by systems in
DoDAF, and by resources in MODAF). To have yet another level of abstraction (if that is
what this is meant to be) seems to just add confusion. In addition, OV-1 tends to be the last
view produced in an architecture, so it is unlikely that it will specify anything that is “later
realised”.
this is a UML Use Case that specifies the requirements for a
capability. There is no equivalent of this in MODAF or M3, but it does appear to be useful. A
future MODAF release should consider something similar for the StVs.
in UPDM, a needline is specified as a requirement to exchange information. In
an as-is architecture, it would not be a requirement, but a logical representation of an
existing information exchange. It should be noted that the UPDM definition is probably in line
with DoDAF in this respect, but not with MODAF
This would appear to be the definition for
OperationalCapability rather than OperationalCapabilityRealization. In addition, it states that
the OperationalCapability is equivalent to an EnduringTask in MODAF, which is not correct
it is not clear why this relates an OperationalCapability
to the realizing systems, instead of just relating the Capability itself to the capability
configurations or systems see also RealizedOperationalCapability
MODAF now defines the temporal and physical structure of the
enterprise i.e. an enterprise can be decomposed into its parts and into its temporal
phases. UPDM applies the temporal information to the Vision (and also to other elements),
which does not allow for quite such a flexible way to “slice and dice” the architecture
no equivalent in MODAF for this concept (note this is a very particular use of the
word “Asset” for OV-1 purposes in UPDM)
A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
· MODAF/ NAF places all of its solution based entities within the system view something that is not the case for UPDM which presents a much more convoluted picture. This is seen as a major advantage for MODAF/ NAF in comparison.
· MODAF/ NAF enables discussions about bandwidth and spectrum utilisation, something that is not a part of UPDM. UPDM differentiates between different types of communication systems and networks however but here the distinction between different entities is far less clear. NAF makes use of Network as an add-on to MODAF but this has primarily been included as a means of stating something in the architecture relating to spectrum and bandwidth.
· Both in the operational views as well as system views there are a couple of entities that deal with services in UPDM. This handling is seen as very inadequate. MODAF/ NAF contain a lot more in this area than UPDM and this is considered a major issue. In UPDM it also seems unclear whether a service description/ specification is being considered or if an implementation of a service is being described.
· The extremely large use of extensions of associations that are used by UPDM seems unnecessary and is seen as a problem.
A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
· MODAF/ NAF attempts to ensure that the modelling taking place as part of the operational views is logical and it uses the concept of ProblemDomain to distinguish between entities that are inside or outside of the trade space of the architecture. This is seen as a great advantage. UPDM has no equivalent concepts and the inclusion of the Materiel entity within the Operational view diminishes the logical handling within the operational views.
· MODAF/ NAF contains a lot more stereotypes devoted to activity handling within the model than UPDM and while certain simplifications may be possible in this area, the area is still felt to be better covered in MODAF/ NAF than in UPDM
· UPDM does contain port handling within the operational views, something that can be used to ensure a proper semantic bridging between different levels of abstraction and this is seen as a UPDM advantage. There seems to be some need to complement this model also in UPDM however.
· The extremely large use of extensions of associations that are used by UPDM seems unnecessary and is seen as a problem.
A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
· MODAF/ NAF ensure the ability to indicate capabilities composed of other capabilities. Whether this ability exists in UPDM is much less clear. In the same fashion MODAF/ NAF supports inheritance hierarchies between capabilities. This does not seem to be discussed within UPDM making it difficult to establish proper capability categorisation. The use of a type: String[1] within UPDM: Capability is not considered to be a valid substitute.
· As stated previously, the inclusion of Effect based entities within UPDM seems pre-mature and the fact that this has been avoided within MODAF/ NAF is perceived as strength.
· The field-trials and modelling that has been carried out based on MODAF/ NAF indicates that the MODAF/ NAF treatment of capability is valid.
· The MODAF/ NAF entity dealing named StandardOperationalActivity has proven to be very useful during modelling. No equivalent entity exists as part of UPDM.
this view is now called “Acquisition
Clusters” in MODAF
The UPDM specification for the AcVs would appear to be incomplete. It specifies the key
stereotypes (Project, Milestone, etc.), but not the logic needed to put all these together into a
sensible programme management view (AcV-2).
A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
· There is a very great deal of difference between the MODAF/ NAF Acquisition view entities and the UPDM Acquisition view entities. It is not considered possible to deliver the types of views that MODAF/ NAF requires based on the entities that UPDM contains and this is seen as a major disadvantage.
A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
· There is a major difference between MODAF/ NAF and UPDM as regards the handling of InformationElement and DataElement. In MODAF/ NAF these are atomic and tied in the data model to a standard where an entity within the standard can go into detail as regards their internal contents. UPDM does not seem to have a data model entity at all making it difficult to assess what should actually be shown as an OV-7 or SV-11 view should this view be desirable. The lack in this area is seen as a UPDM disadvantage.
· MODAF/ NAF contain various specialisations of standard the support the handling of bandwidth and spectrum handling and this is considered an advantage for MODAF/ NAF in comparison with UPDM.
the semantics of this relationship are unclear. In addition, there are four
relationships using this name in the Milestone section, which is very confusing
capability increment is represented by a string in UPDM. The M3 equivalent
links to the capability that is met so that there is contiguity through the architecture. Only by
doing this can StV-3 and SV-8 be derived from the project milestones (essential for
architectural coherence and contiguity across views).
as with the DLOD Elements, UPDM hard-wires the possible status
indicators. MODAF does not specify this, and neither does the M3
the MODAF Meta-Model specifically does not mention the Defence Lines
of Development (which are a UK only concept) so as to allow a more generic mechanism for
dealing with other project thread approaches e.g. the US DoD DOTMLPF approach.
Furthermore, each line of development is specified in the UPDM profile. MOD has recently
changed the number of lines of development, and there is no reason to assume this will not
happen again.
A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
· MODAF/ NAF contain environmental entities that can be used to qualify different parts of a MODAF/ NAF model. This has been found to be a necessity during the modelling field trials that have been performed in Sweden. UPDM has no such entities.
· The handling of the Enterprise entities in MODAF/ NAF gives a much clearer picture of the temporal aspects and can be used to subdivide the enterprise into constituent parts that can be handled separately. No such handling is contained within UPDM.
· MeasurableProperty handling as well as ontology references in MODAF/ NAF ensure that hard-coded enumerations and classes are not required. Hard-coded enumerations and classes are made use of within UPDM.
· The handling within MODAF/ NAF of external references and Ontology is also much clearer that external reference handling within UPDM.
MODAF/ NAF are felt to be a more connected model than UPDM where no attempt is made to show all entities as a connected meta-model for different purposes. This makes UPDM much harder to assess.
MODAF/ NAF have a much clearer model of temporal components making it a lot easier to discuss how different parts of the model applies at different points in time.
The MODAF/ NAF use of UML: property ensures that several types of connections that UPDM defines based on associations are unnecessary in MODAF/ NAF.
The AV in UPDM is derived from IEEE1471 (the same goes for MODAF). The interpretation used in
UPDM is different to that used in M3. The biggest cause for concern is the Resource stereotype. It
is not clearly defined and attributed. It is not clear whether a resource is an individual resource or a
type of resource (a key distinction in Enterprise Architecture).
this is possibly a misunderstanding of the two
MODAF concepts a type of project cannot be a special case of a project
the UPDM description of Project confines it to the procurement of systems. The
MODAF approach says nothing about the type of project. This has been deliberately done in
MODAF to allow for capability increment projects that achieve the increments through
other means than equipment e.g. revised doctrine, re-configuration of battlegroups, etc.
· The attributes contained here seem fairly simplistic and it seems doubtful whether they will be enough to manage the information required. By contrast, the meta-model for MODAF/ NAF gives a great deal more.
· This element may well be too specific and subject to change.
By the same argument as that indicated in issue 12010 this association is not seen as required.
this is the equivalent of ArchitecturalProduct in M3. However, M3
takes a different approach; instead of hard-wiring the views into the profile, it allows the
profile itself to specify the views and the framework used (allowing for NAF, DoDAF, etc. to
be covered by M3). M3 also specifies the type of product in terms of its nature i.e.
structural, behavioural, matrix, etc. UPDM does not.
a class library approach is used in UPDM, but not in MODAF
· As stated previously, the inclusion of hard-coded enumerations is not considered as a good approach.
· The fact that a project type should be viewed as a specialisation of project seems very strange. The reverse would be more understandable.
· It is difficult to see the difference between a service as it is being implemented as well as a service as it is being described. Using an extension of Port also seems strange if is to be possible to actually describe a service functionality in an implementation independent manner. The proposed MODAF/ accepted NAF views for services make distinguishes between the description of a service and how it could be implemented. The description of a service is however much more than a single port. The exposed service port containing the service interface is important. A service taxonomy as well as classification is equally important. Composition as well as description of the service achievement is equally important. It is therefore felt that the parts dealing with services in UPDM might well await further definition of a meta-model for services once this is adopted by OMG.
· The description given for this entity would seem to make it difficult to distinguish this and a CapabilityConfiguration (at least from a MODAF/ NAF perspective). Is there a need for this given the existence of the CapabilityConfiguration entity?
· The only difference that can be seen between CommunicationSystem and Network would seem to be dealing with geographical extension. Is there really a need to maintain two different entities to cover this area?
t is noted that OperationalActivity handling does not seem to consider the entities that are considered as required when creating activity diagrams such as swimlanes, callbehavioraction, pins etc. Such entities exist in MOFAF/ NAF.
· Materiel is a very broadly defined entity that seems to relate to almost everything. At first glance the MODAF/ NAF equivalent would seem to be PhysicalAsset but given the concept of MaterielBehaviour this does not seem to be the case. First of all Materiel does not seem to need to be related to anything inside the OperationalViews and provided it is to be retained it should be confined to the SystemViews. The reason for this is twofold:
o The operational views deal with logical operations not with solutions and by introducing materiel solutions are being discussed something that should be done in the system views.
o In cases where entities in the operational views need to be made physical, something that happens when they do not belong to the trade-space as such, there is no need to go to a level of detail that needs materiel. MODAF/ NAF deals with a distinction between the two types of entities by stating by the use of a problem domain entity, a very useful concept.
The association entities therefore also seem questionable.
· In spite of the fact that no such entity exists in MODAF and NAF, its inclusion is considered a good idea as a means of bridging the gaps between different levels of abstraction in an operational node model.
· As stated before, MODAF/ NAF considers nodes as logical entities that could almost be viewed as instances of a capability. The connection to resources are therefore less than clear and as stated previously associations to effect are not considered appropriate at this point.
· The fact that the first entity is supposed to be a specialisation of operational node is strange. It would also seem to belong squarely within the System View entities. Since the relationship is already there based on MODAF/ NAF entities it is considered questionable whether this is actually required.
· The association extension seems questionable at least from a MODAF/ NAF perspective.
· The use of service related concepts here would seem to require a complete service handling throughout and this does not seem to be the case in UPDM, possibly due to the fact that OMG is considering other profiles for services. Based on this it would seem better to await developments here.
· The number of roles used here seems to restate much the same thing in different contexts. MODAF/NAF makes use of a single Role concept and that would seem to be enough.
· This is also considered a good idea, however, in order to be complete there would seem to be a need to tie required and provided interfaces to a port as well as InformationElements by means of the interfaces to make the handling complete.
· The attributes here would seem to be reconsidered. It may well be appropriate to avoid these altogether since the few entries contained seem unable to capture all aspects of organisational relationships. A brief check within CADM for instance reveals a great deal of different relationships and it would therefore seem better to let the architecture model itself deal with this either internally or through external references.
· This could be used to tie rather nicely into the handling of interfaces and ports in which case an operation could be a part of an interface associated with a realized interface that forms a part of a port. In all fairness however, if operations are made use of it is felt that signals should also be allowed, especially since a good way of visualising operations would be to allow InformationElements to be conveyed by signals (they could of course also be dealt with as part of the attributes associated with a given operation).
· As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.
· It seems slightly difficult to distinguish between these two entities and the questions should be asked whether they are both really needed.
· While it is important to be able to show these entities in the form of an organisation chart it needs to be noted that MODAF/ NAF distinguishes between actual organisational resources or types of resources, something that may well be required depending on the scope of the model.
· This association also seems questionable since the relationship will anyway be present as a result of the definition of the system function itself.
CommPathFromTo/ CommunicationLink/ CommunicationPath/ CommunicationSystem/ CommunicationPathRealization
· The main items here would seem to be connectors between systems and their aggregation into paths that could also include intervening communications systems. This makes sense, however the CommPathFromTo association seems fairly superfluous. The same can be stated for CommunicationPathRealization.
· The fact that this is a specialisation of OperationalNode is considered strange as is the relationship it establishes. The crucial relationship would seem to be between capability and CapabilityConfiguration, this is the one that has to be maintained.
· This seems to define an entity in the form of UseCase "above" ordinary capabilities. It is however felt that the name leaves something to be desired (suggestion: CapabilityUseCase) and that it should be part of the StrategicViews rather than the OperationalViews.
· Since the connections between OperationalNode, OperationalNodePort and OperationalNodeSpecification is already established it seems unclear why this relationship would need to be established explicitly.
· As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.
the purpose of this (and its related stereotypes) is not entirely
clear. It is defined as being applied to any ConformingElement, but the “semantics” section
talks about system performance
· MODAF/ NAF does not contain a system node concept and the question is whether a more applicable concept here would not be CapabilityConfiguration. The statement that a system node would be equivalent to PhysicalAsset in MODAF is not correct. If however there is a hidden assumption that a systems node has to be in a single location, then Capability configuration is broader since this would not be a requirement.
· It is considered questionable whether the association extension is really required. A CapabilityConfiguration (to use a MODAF/ NAF term) would be visualised as a composite class diagram and the entities would thus turn up as connected to the surrounding entity without the need of a specific association.
· It is considered questionable whether the above entities are really of interest. A service is realized by a CapabilityConfiguration in MODAF/ NAF not just a system and anything other than web services will require more than this to indicate usage as well as provision of services. Being a consumer or provider will depend very highly on the point of view taken.
· It is noted that in both of these, the text states that they are specialisations from System but the diagram shows them as extensions of class.
· See previous comment. In addition to this the attribute serviceDescription seems to be a link to a formal service description or a description of the service itself. Linking to an external specification is not considered enough for an architecture model intended to describe SOA, neither is a single text description.
· This entity also requires further considerations. It seems better placed as either part of the StrategicViews or the OperationalViews. Given the attributes contained it would seem to be very focused on actual operations something that does not actually fit with its name. The fact that the parameters are only strings furthermore makes one question whether it can actually be used to describe something of architectural value.
· The relationship between these entities seems far from clear. A concern is an extension of UseCase and is associated with a Stakeholder as well as an ArchitectureView. A stakeholder is also associated with an architecture view and the relationship between Stakeholder and concern is stereotypes as StakeholderConcern. It would therefore seem that connections to ArchitectureView exist both through the concern and from the stakeholder directly. Is this really required?
· Resource, given the explanation given also seems far better placed elsewhere than as part of AllViews. Given the extension used (Class) it is obviously a Type, but there seems to be some further classification going on since a resourceType parameter in the form of a string has been included. A ResourceType entity seems of interest. The value parameter also seems strange and the use to which this can actually be put seems questionable.
· This entity would seem to be better positioned within the SystemView elements.
· Capability is shown as directly tied to resources, something that from a MODAF/ NAF perspective would be OK provided the entity was a CapabilityConfiguration. A Capability is an abstract high-level view of that which an enterprise wants to be able to accomplish during a specific time frame. Some of the attributes shown here are also strange such as type and isFielded which would seem to merit entities all by themselves in order to be usable.
· Why do the ExternalReferenceType literals in the table repeat themselves as table entries?
· While InformationAssurance and Security are of concern to an architect, it is considered highly doubtful whether the parameters shown here will cover the issue. Since these are examples of issues that require management across an entire enterprise it may be more profitable to look into aspect-oriented modelling concepts as a means of covering such issues.
· This seems to be a way of creating entities solely for the use within OV-1. The mapping entity then establishes a relationship between the asset and entities elsewhere. MODAF/ NAF manages this by viewing all the above as ConceptItems and therefore no additional entry is required. However since OV-1 users tend to want to draw lines between entities MODAF/ NAF has added an arbitrary connection element that can be used to indicate this. This has no semantic meaning however other than as an illustration. It is noted that no such feature seems to exist in UPDM.
· This extension of association is used to tie an OperationalActivity (an operational view element) to an OperationalActivityRealization (a system view element) or a SystemFunction (a system view element) to an OperationalCapabilityRealization (an operational view element). Based on the semantics description this seems to be intended to create one-to-many mappings between OperationalActivity (s) and SystemFunction(s) in both directions. The above seems a very cumbersome approach and is handled in a far simpler but equally functional way in MODAF/ NAF.
Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapabilityEffect
· Previous versions of MODAF/ NAF contained an effect entity. This has now been removed since it is felt that effect based operations handling require additional consideration before an attempt is made to include it within the architecture framework. The inclusion of effect and associated entities within UPDM seems premature.
· This entity has been removed in MODAF/ NAF as unnecessary. The relationships shown also seem strange. As commented upon later the crucial entity is Capability, and the fact that there is no relationship here between capability and a requirement for it therefore seems strange. Essentially all relationships shown for this entity are considered as highly questionable.
· The need for CapabilityRequirementCapability as an extension of Association is also considered questionable.
OperationalNodeCapabilityRequirement/ OrganisationalResourceCapabilityConfiguration/ ResourceCapability/ ResourceCapabilityConfiguration
· The description of OperationalNodeCapabilityRequirement discusses the need for a relationship between capability and operational node whereas the constraints as well as the name talks about a relationship between a CapabilityRequirement and an OperationalNode. The text should, if it is actually to remain be amended.
· All of the above extensions of association are considered questionable as to need. Using MODAF/ NAF the fact that capability configurations are built by resources are apparent in the model and no additional associations are required.
· As commented upon both previously and later, the need for this association seems questionable.
· PerformanceMeasureSet also turns up as PerformanceMeasurementSet in a number of places and the correct term therefore needs to be established.
· The attributes make use of the entity PerformanceMeasurementPeriod which does not appear anywhere else in the document.
· The descriptions of all of these seem somewhat circular and could do with some modification: PerformanceMeasureSet ="This stereotype (PerformanceMeasureSet) is applied to instances of classes stereotyped PerformanceParameterSet". PerformanceParameterSet = "This stereotype is applied to PerformanceMeasurementSet in the UPDM class library".
· This is shown as part of AllViews but would seem much better placed as part of the StrategicViews.
· This entity seems highly questionable and is commented on later as part of comments concerning OperationalCapability.
· This entity would work better as an extension of Dependency rather than association. It furthermore needs to be noted that capability configurations are defined by the capability they implement not the other way around. This implies that the supplier of the relationship is the capability and that the client is the CapabilityConfiguration of which there may be more than one since different combinations of resources could be used to supply a capability.
· By considering Enterprise as an extension of Package, the ability to use this effectively in a model seems to be severely limited. MODAF/ NAF.
· MODAF/ NAF provides the ability to consider the enterprise as a set of temporal parts as well as whole-parts, something that will yield an ability to be much more specific as regards the enterprise.
· This entity seems better placed as part of the Strategic or the Operational views. It is furthermore shown as having an association with a SystemTask. This, while potentially the reason for placing in this view group, seems somewhat superfluous.
· The attribute instances of architecture summary indicate [1] and the constraints talk about zero or more.
· The constraints seem to indicate a relationship between the architecture enterprise and an Enterprise which is not shown.
· An architecture summary is shown as a specific class rather than a stereotype. The necessity of this can be questioned.
· UPDM uses extensions of associations to a very large degree, in most cases first showing entities as having named associations to other entities and then defining stereotypes for these associations. It is the view of the author that this should have been dealt with by making use of the association extensions within the meta-model itself rather than having them as separate entities. The latter is the approach adopted by MODAF.
· A set of different entities have been hard-coded into UPDM in the form of classes as well as enumeration entities. This is considered fairly dangerous since this can very well change over time making UPDM difficult to maintain. Its use could also well pose national problems since the values may not be applicable everywhere. MODAF/ NAF have avoided the use of any such entities and left them to be part of the model or referred to as externally defined entities, something that seems to be a better approach.
· It is difficult to understand why the different views should be stereotyped at all. The whole point of a modern architecture framework would seem to be to get away from strict adherence to a set of views. The main utility is the meta-model itself and how different entities tie together. How a user elects to visualise this is much less important. The addition of the Custom view is not felt to adequately deal with this.
· It is noted that as UPDM contains different compliance levels, exchanges between tools operating at different UPDM compliance levels will require recognition of these differences as well as translations if the exchange is to be successful.
From 8.6.12
"8.6.12.3 Description
A Forecast describes the actual or predicted status of a System at a Project Milestone - i.e., a point in the lifecycle of the
system. It can be a statement about the future state of one or more types of System or TechnicalStandardsForecast.
The Forecast is effective for a given timePeriod."
SystemGroup is also related to the Milestone (from 8.6.38).
There should be a constraint ensuring that there is at least one Milestone related to the SystemGroup directly and to the Forecast that is related to this SystemGroup. It would not make any sense to have a Forecast at the specific Milestone when a SystemGroup does not even exist.
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “forecasts”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative and too long
Solution #1
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “groups” or “owns”
Solution #2
Remove ForecastStandardsProfile
Change metaclass for TechnicalStandardsProfile to Package
Use ElementImport or Ownership to link Forecast and TechnicalStandardsProfile
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative and too long
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “affects”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative and too long
Node cannot cause Effect, it should be Node’s behavior that does it. This relation is somewhat duplicated by
OperationalCapabilityEffect.
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “causes”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “governs”
Problem
Semantics is not clear. Is it Capabilities provided by Resource or Resources needed by Capability.
Direction is not clear
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “requiredBy” or “providedBy (depending on sematics)
OrganizationalResourceCapabilityConfiguration metaclass should be Usage or Dependency.
Problem
Direction is not clear
Name is not informative and too long
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “configuredBy”
Problem
Direction is not clear. Very important in this case.
Name is too long
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Multiple stereotypes could be introduced “direct”, “indirect”, “back-up”, etc.
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative and too long
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “requiredBy”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative and too long
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “playsRole” or “plays”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative and too long
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “requiredCompetency” or “requires”
Problem
Direction is not clear
Name is not informative
There might be a read-only library of Competencies, so modification is not wanted.
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “providedBy”
Problem
Direction is not clear
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “includedIn”
Problem
Description could be more informative.
Name is not too long.
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “hosts”
Problem
Direction is not clear.
Name is not too long.
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “groups”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative and too long
Different semantics in case of different ends.
Solution
Create one relationship for realization and one for delivery.
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
SystemFunctionSpecifications are abstract Systems modeled as Interfaces. They are not limited to internal system
functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions
that consume or produce DataElements from/to SystemFunctionSpecifications that belong to external systems. The
external system data sources and/or sinks can be used to represent the humans that interact with the system or external
systems. The SystemInformationFlows between the external system data source/sink (representing the human or system)
and the HCI, GUI, or SystemFunctionSpecification can be used to represent human-system interactions, or system-system
interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified in this product
through the ConformingElement relationship.
The relationship between OperationalActivities and SystemFunctions can also be expected to be many-to- many."
UML terms are used. Description should be more about semantics, etc.
Defines the behavior of a System or OperationalActivityRealization as an activity in terms of invocations of
SystemFunctions connected by SystemControlFlows and the flow of objects through the System with
SystemInformationFlows."
Description should be more informative and clear.
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “supportedBy”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “configuredBy”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “delivers”
Problem
Direction is not clear
Unnecessary properties (association ends) are created.
Name is not informative
Solution
Change metaclass to Usage or Dependency.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.
Change name to “relatedTo”
Specifies the behavior of a System or OperationalActivityRealization as an Interaction - by depicting the sequence of
events between Systems and the invocation (TaskInvocation) of SystemTasks. The behavior of an interaction is depicted
in a sequence diagram that shows the ordered exchange of information between Systems through the activation of their
SystemTasks that participate in the interaction."
UML terms are used.
A flow of control, energy from one activity node to another."
Description should be more informative - why and where this element should be used.
A Network is a collection of one or more CommunicationPaths. It may contain multiple CommunicationPaths between
the same pair of Systems. This is typically realized by the Network owning a set of CommunicationPaths.
Description is wrong.
A Location is anywhere that can be specified. The means of describing the location is a string (locationDescription). The
information contained in that string is governed by the locationType."
Description should be more informative - why and where this element should be used.
Problem
Unnecessary properties (association ends) are created.
Direction is not clear
Solution
Change metaclass to Realization.
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability (if needed).
Asserts that there is an association between a Forecast and a TechnicalStandardsProfile."
Description should be more informative. What "association" means in this context?
Specifies that a System or one of its sub stereotypes realizes an interface stereotyped SystemFunctionSpecification or one
of its sub stereotypes."
UML terms are used. Description should be more about semantics, etc.
OperationalActivityRealization is a collaboration among Systems or SystemFunctionSpecifications that realize an
OperationalCapabilityRealization or other System capability."
Description should be more informative - why and where this element should be used.
Specifies these are the elements associated with a SystemsNode."
Description should be more informative. What "associated" means in this context?
Specifies the System elements configured with a System."
It should be "Specifies the System elements configured with a SystemGroup". However I'm not sure if such description is enough.
The SystemGroup is a collection that includes instances of System, SystemHardware and SystemSoftware that forms a
unit for tracking and assessment purposes."
Description is wrong.
Specifies that an OperationalCapabilityRealization delivers the Effect, or that an OperationalActivityRealization realizes
an Effect."
The description is not sufficient
An Effect is an action that brings about a change in the state of something. The event that initiates the action is a Trigger.
The action is the result of an OperationalTask. An Effect is caused by collaborating OperationalNodes that bring about the
Effect as a result of their OperationalTasks. The collaboration, an OperationalCapabilityRealization, can be described in
terms of the Effect that it has. This Effect can be observed in an EventTrace from the perspective of the sequence of OperationalTasks. It can be seen in a StateTrace as a transition that CausesEffect showing the Trigger, the Effect, and the
desired ResultOfEffect, the end state. The OperationalActivity can show the Events that are Triggered and the receiving
Action that includes the OperationalTask in callOperationActions.
An Effect is the central player in all of these scenarios unifying the OperationalCapabilityRealization with the Effect,
viewed from the perspective of the collaborating OperationalNodes, the Triggers, States, and Activities."
UML terms are used. Meaning and usage of this element should be described.
A transition from one state to another Causes an Effect. The Effect is the call event that invokes an OperationalActivity
on the receiving OperationalNode. The affected OperationalNode is the receiver of the InformationExchange while the
causing OperationalNode is the originator of the InformationExchange. The change in state is the Effect of the
InformationExchange. (See Effect)."
UML terms are used. Meaning and usage of this element should be described.
Asserts that a CapabilityRequirement is related to an OperationalCapability."
The description is not clear. It is hard to understand what this relationship means.
Asserts that the CommunicationPath is realized by a CommunicationsSystem described in terms of
CommunicationsSystems and Systems connected by CommunicationLinks."
Description is wrong
A communications link is a single physical connection from one system (or node) to another. A communications path is a
(connected) sequence of communications systems and communications links originating from one system (or node) and
terminating at another systems (or node)."
The OCL does not allow SystemsNodes to be linked, but description says so.
A Forecast describes the actual or predicted status of a System at a Project Milestone - i.e., a point in the lifecycle of the
system. It can be a statement about the future state of one or more types of System or TechnicalStandardsForecast.
The Forecast is effective for a given timePeriod."
Forecast is linked to a SystemsGroup, not a System,
A data element exchanged in between systems."
The description should be more informative.
A CommunicationPort occurs at the end of CommunicationLinks when it is necessary to provide details on the actual
connection. CommunicationPort may implement a PortType, though there is no requirement to be typed."
It is not clear what details spec is talking about. The description should be more informative.
Asserts that a CommunicationPath realizes a SystemInterface."
A description should be more informative.
In effects based planning, the focus is on the outcome of an Effect. This is that end state, the ResultsOfEffect."
The description is not clear.
Specifies that a OperationalNode or one of its sub stereotypes realizes an interface stereotyed
OperationalNodeSpecification or one of its sub stereotypes."
UML terms are used. Meaning and usage of this element should be described
Defines the association between a CapabilityConfiguration and the all of Resources that are included in it."
The description could provide more information.
Specifies an association exists between a Resource and the Capabilities that it provides, that is, the Resources required for
a Capability."
There is a big difference between Resource providing Capability and Capability requiring Resources. Which one is it?
OrganizationalRelationship describes the relationship between two OrganizationalResources."
The description should be more informative"
This is the state machine for OV-5."
Wrong and not informative
The event that invokes either an OperationalTask or a SystemTask in the EventTrace.
The ends of the connector associated with the message are the source and target of the information flow and the argument
is the information element. If there is no argument, then the invocation, itself, is the information element - i.e., a
command."
UML terms are used. Meaning and usage of this element should be described.
Specification is the ancestor of all the stereotypes that extend Instance Specification. It implements the common attribute,
description.
In general, any of the classes supplied in the class library as the type for instance specifications can be extended to
include additional attributes to be used in custom instance specifications.
Instances are created from classes that are defined in the UPDM ModelLibrary. The values of the attributes of the parent
class are set in the slots of the instance. Associations among instances of classes that reside in the Model Library are
specified by creating a link that is an instance of an association that is defined on the classes in the Model Library. In
addition, the stereotyped instance may have stereotype properties that define relationships to other stereotyped classes."
There is no description attribute.
It is not clear why this stereotype exists and how it should be used.
PerformanceParameterType provides details for the type of attribute for PerformanceParameterSet."
The description is not sufficient. It should explain what is the meaning of this element and how it is used.
Description is not sufficient.
8.7.2.3 Description
Asserts that there is an association between a Forecast and a TechnicalStandardsProfile.
"8.4.32.7 Semantics
Use the DeployedToSystemsNode association to indicate deployment of
OrganizationalResource to a SystemsNode.
Use the OperationalCapabilityRoleResource association to indicate an
OrganizationalRole played by the OrganizationalResource.
Use the OrganizationalResourceCapabilityConfiguration association to indicate
inclusion in a CapabilityConfiguration
Use the DeployedToSystemsNode association to indicate deployment of
OrganizationalResource to a SystemsNode.
Use the DeployedToSystemsNode association to indicate deployment of
OrganizationalResource to a SystemsNode."
This Stereotype is applied to the PerformanceMeasurementSet in the UPDM ClassLibrary."
Does not make any sense
A PerformanceMeasurementrSet includes a set of PerformanceMeasures for each PerformanceMeasurePeriod. The set is
applied to ConformingElements. (See UPDM Class Library). This stereotype is applied to instances of classes stereotyped
PerformanceParameterSet."
Typo "PerformanceMeasurementrSet"
PerformanceMeasurementSet does not include any PerformanceMeasures, since there is not such element. It includes actual values for each PerformanceParameterType that are owned by linked PerformanceParameterSet.
An OperationalNodePort is used to model details of Node connections when a Needline is modeled as a connector."
If this element is needed only to facilitate UML usage, it is not needed as separate stereotype. If there is some other meaning, it should be defined in the description.
A flow of control of energy from one activity node to another."
It is not clear why this elements is needed and how it is used
Specifies that an OperationalCapabilityRole requires zero or more Competencies and a Competence is required by zero or
more OperationalCapabilityRole and that these are the elements associated with this association."
If a OperationalCapabilityRole required Competency, it does not mean that Competency requires OperationalCapabilityRole, but the description says so.
An OperationalCapability is a Use Case that specifies the requirements for a Capability."
UML terms should not be used in descriptions.
A Resource or OrganizationalRole can have a set of related Competencies that are required or provided to meet their
declared responsibilities and perform their OperationalTasks."
It is not clear clear if it is required or provided competency.
A general stereotype that can be applied to any element in a model that applies the profile."
The description is not sufficient
Stereotype for realization CommunicationsPathRealizesSystemInterface is too long
Stereotype for realization RealizedOperationalCapability is too long
Stereotype for interface realization RealizedSystemSpecification is too long
Stereotype for interface realization RealizedOperationalSpecification is too long
ConformingElement provides a link from profile elements to specific standards in the context of a forecast."
Conforming element has no connection with Forecast.
Sterotype for Association name ResourceCapability is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name ResourceCompetence is not intuitive. It is not clear if it is provided Competence or required
Sterotype for Association name ResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name SystemsNodeElements is plural and not intuitive. Should be something like "hostedOn"
Sterotype for Association name SystemGroupMember is not intuitive. Should be something like "groupedBy"
Stereotype for dependency AssetMapping is not intuitive. Semantic meaning of the relation should be implied
Stereotype for dependency CompetenceRelationship is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name OrganizationalResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name OperationalNodeCapabilityRequirement is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name OperationalCapabilityRoleResource is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name ForecastStandardsProfile is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name EffectAffectsNode is not nice. Should be simplified to "affects"
Sterotype for Association name NodeCausesEffect is not nice. Should be simplified to "affects
Sterotype for Association name MilestonePoint is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name OperationalCapabilityRoleCompetence is not intuitive. Semantic meaning of the relation should be implied.
Sterotype for Association name OperationalCapabilityEffect is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name MaterielBehavior is not intuitive. Semantic meaning of the relation should be implied
Sterotype for Association name MaterielNode is not intuitive. Semantic meaning of the relation should be implied
Diagram should show an association to Operation instead of OpertionalTask and SystemTask. It should be named "tasks". The association has to be unidirectional with a multiplicity of zero or more.
8.3.11.6 Constraints
[1] Asserts that there are SystemTasks or OperationalTasks governed by this Doctrine self.tasks-> forAll(getAppliedStereotype('UPDM::OperationalTask')>notEmpty() or getAppliedStereotype('UPDM::SystemTask')>notEmpty())
[1] Asserts that there are zero or more SystemTasks or OperationalTasks governed by this Doctrine
self.tasks->notEmpty() implies
self.tasks-> forAll(getAppliedStereotype('UPDM::OperationalTask')
->notEmpty() or
getAppliedStereotype('UPDM::SystemTask')->notEmpty())
[3] Asserts that this Doctrine governs zero or more CapabilityConfigurations self.capabilityConfigurations-> forAll(getAppliedStereotype ('UPDM::CapabilityConfiguration')->notEmpty())
[3] Asserts that this Doctrine governs zero or more CapabilityConfigurations
self.capabilityConfigurations->notEmpty() implies
self.capabilityConfigurations-> forAll(getAppliedStereotype ('UPDM::CapabilityConfiguration')->notEmpty())
8.4.32.6 OrganizationalResource Constraints
Project has zero or more - not 1 or more.
[1] Asserts that there is at least one Project owned by this OrganizationalResource. self.projects.getAppliedStereotype('UPDM::Project')->notEmpty()
[1] Asserts that there is zero or more Projects owned by this OrganizationalResource.
Self.projects -> notEmpty() implies
self.projects.getAppliedStereotype('UPDM::Project')->notEmpty()
[3] Asserts that there is an association between the OperationalNode and a SystemsNode that houses the OperationalNodes. self.getAllAttributes()>asOrderedSet()>select(association- >notEmpty()).association->any (getAppliedStereotype('UPDM::SystemsNodeElements')> notEmpty())>notEmpty()
[3] Asserts that there is an association between the OrganizationalResource and a SystemsNode that requires this resource.
self.getAllAttributes()>asOrderedSet()>select(association- >notEmpty()).association->any (getAppliedStereotype('UPDM::SystemsNodeElements')> notEmpty())>notEmpty()
[3] should be deleted, this association is not a required resource.
8.4.32.7 OrganizationalResource Semantics
Use the DeployedToSystemsNode SystemsNodeElements association to indicate deployment of OrganizationalResource to a SystemsNode.
Use the OperationalCapabilityRoleResource association to indicate an OrganizationalRole played by the OrganizationalResource.
Use the OrganizationalResourceCapabilityConfiguration association to indicate inclusion in a CapabilityConfiguration
Use the DeployedToSystemsNode association to indicate deployment of OrganizationalResource to a SystemsNode.
Use the DeployedToSystemsNode association to indicate deployment of OrganizationalResource to a SystemsNode.
[1] Asserts that this Concern links an ArchitecureView to a set of Stakeholders self.architectureView.getAppliedSubstereotypes(self.getApplicableStereotypes()- >any(qualifiedName='UPDM::ArchitectureView'))->notEmpty()
[1] Asserts that this Concern links an ArchitecureView or one of its specializations to a set of Stakeholders self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
or self.architectureView->forAll(getAppliedStereotypes()> collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )
[2] Asserts that there are zero or more Stakeholders who have this Concern
self.stakeholders-> forAll(getAppliedStereotype('UPDM::Stakeholder')->notEmpty())
[2] Asserts that there are zero or more Stakeholders who have this Concern
self.subject->
8.3.19.3 Stakeholder Description
Fix diagram - remove association between concern and Stakeholder. This is handled by the subject/usecase association.
Change StakeholderConcern to dependency notation
8.3.19.3 Stakeholder Associations
delete concern[]
8.3.19.6 Stakeholder Constraints
[1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
[1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
or self.architectureView->forAll(getAppliedStereotypes()> collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )
materiel is listed as an Association, but the diagram does not indicate the association.
There isn't an association between OperationalActivity and Materiel, but there is a stereotypedAssociation, MaterielBehavior that is bidirectional, so there should be a dependency in the diagram as proposed for the solution for showing stereotyped associations
:[2] Asserts that for every callOperationAction in an OperationalActivity that refers to an Operation that is stereotyped OperationalTask, then:
if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNode or a Property that is typed by an OperationalNode or one of its specializations, then o
the OperationalTask must be owned by that OperationalNode and the OperationalTask must have at least one method that specifies a corresponding OperationalActivity owned by the OperationalNode, (an OperationalTask could also specify Interactions or StateTraces)
OR o
if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNodeSpecification or a Property that is typed by an OperationalNodeSpecification, then o
the OperationalNodeSpecification must own the OperationalTask.
This constraint forces the called operation to be owned by the OperationalActivity that represents the partition in which the callOperationResides and that is not generally the case.
Resolution:Fix the OCL.
This stereotype doesn't have much use as is. Either delete it, or make it more meaningful
[1] Asserts that there is one OrganizationalResource required for this Project
[1] Asserts that there is one or more OrganizationalResources that own this Project
Fix diagram to show 1 or more
[2] Asserts that zero or more Milestones govern this Project through an DOLDElement self.getAllAttributes()>asOrderedSet()> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')> notEmpty())>notEmpty()
[2] Asserts that one or more Milestones govern this Project
self.getAllAttributes()>asOrderedSet()> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')> notEmpty())>notEmpty()
Technology does not exist in UPDM, so reusable libraries cannot be created on order to model a SV-9.
DoDAF spec says that a TimedTechnologyForecast should be linked to exact system and exact standard. Current profile allows linking a Forecast to a SystemGroup and TechnicalStandardsProfile only. A Forecast could be a relationship, linking Systems (or other entities) with Technologies and Standards
This is the agreement we reached with MOD to converge UPDM and MODAF.
MOD will migrate M3 to a formal Mx (name TBD) data model. This is part of MODâs intent eventually to migrate to IDEAS
MOD will define a standard XML format for exchanging data conforming to the Mx data model.
MOD and UPDM will define a bi-directional algorithmic mapping between UPDM and Mx data model
An additional UPDM compliance point will be defined by a toolâs ability to export and import data that is compliant to the standard Mx data model according to 3, 4 & 5.
UPDM will add an optional, normative section that specifies 6.
A UPDM tool that implements 7 enables a vendor to claim the ability to produce MODAF architectures
Sterotype for Association name CapabilityConfigurationCapabilities is not intuitive. Semantic meaning of the relation should be implied
Navigability for association between PerformanceMeasurementSet and ConformingElement.
Current navigability is wrong, same PerformanceMeasurementSet can be applied for only one ConformingElement. It should be 1..*.
ProjectType has a generalization link to Project. This does not make any sense.
:8.3.13.3 Goal Description
Fix diagram to show 1 or more OperationalCapabilities and 1 or more Visions associated with the Goal.
8.3.13.3 Goal Associations
fix multiplicity in both associatione to be [1..*]
Change Milestone and Capability associations to the stereotyped dependency notation
8.2.8.3 Description
Change MilestonePoint to <<StereotypedAssociation>> notation in the diagram
8.2.8.5
Remove all associations
CapabilityRequirement_rule
The constraint documentation is:
[4] Asserts that this Node is required for delivery of an Operational Capability.
The OCL for the constraint is:
self.getAllAttributes()>asOrderedSet()>select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::OperationalNodeCapability')> notEmpty())>notEmpty()
There is no stereotype in UPDM called OperationalNodeCapability. I think it should be OperationalNodeCapabilityRequirement.
And if so, does the textual description make sense?
Resolution:
Revised Text:[4] Asserts that this Node is required for delivery of a CapabilityRequirement.
self.getAllAttributes()>asOrderedSet()>select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::OperationalNodeCapabilityRequirement)> notEmpty())>notEmpty()
In the description of an Operational Activity, the subsection called ProxyActivity is confusing. Proposed wording:
Resolution:Proposed wording- A context-free OperationalActivity is defined with no specific context. The OperationalNode that wants to perform that context-free activity defines its own OperationalActivity that will act as a proxy for the context-free one. This proxy OperationalActivity (ProxyActivity) contains at least a callBehaviorAction referring to the context-free OperationalActivity. Optionally, an OperationalTask can be defined on the OperationlNode and the Specification attribute of that ProxyActivity can be set to that OperationalTask. Typically, the OperationalNode that defined the proxy has another OperationalActivity which uses the context-free OperationalActivity by specifying that the ProxyActivity is performed at that OperationalNode. The proxy is referenced using either a callBehaviorAction or a callOperationAction if the OperationalTask was defined for the proxy.
Using this proxy pattern, multiple Operational Nodes can effectively perform the same context-free OperationalActivity. Instead of defining an OperationalTask on every OperationalNode that defines a proxy for the context-free OperationalActivity, create an OperationalNodeSpecification with an OperationalTask that corresponds to the context-free OperationalActivity. When an OperationalNode defines a ProxyActivity, it sets the Specification attribute on the proxy to the OperationalTask owned by the OperationalNodeSpecification and then the OperationalNode implements (realizes) the OperationalNodeSpecification. Using this pattern, it is easy to determine every OperationalNode that performs that context-free (common) OperationalActivity simply by examining the Method attribute of the corresponding OperationalTask, defined on the OperationalNodeSpecification, which will be a collection of the ProxyActivities.
We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes.
SystemTask-Method_rule
This constraint is supposed to ensure that if the "method" attribute of a System Task (operation) is defined, it must be either a SystemFunction, SystemStateTrace or SystemEventTrace. Two problems: (1) the stereotype references correspond to the operational equivalents and (2) the OCL that should check for an SystemEventTrace casts the behavior to a "uml::StateMachine" but it should be a "uml::Interaction".
OperationalTask::Method_rule
This constraint ensures that if the "method" attribute of an Operational Task (operation) is defined, it must be either an OperationalActivity, OperationalStateTrace or OperationalEventTrace. The OCL that checks for an OperationalEventTrace casts the behavior to a "uml::StateMachine" but it should be a "uml::Interaction".
ConformingElement is used for applying standards or performing measurements. TechnicalStandardsProfile should be just grouping Standards, so it does not need to extend ConformingElement
System stereotype is lost if the instance of System class is created
getAppliedStereotype OCL construct does not exist
An ArchitectureView may not conform to a Standard e.g. if the purpose of
the ArchitectureDescription is to elaborate a new standard (e.g.
concepts of operation). 'Conform' may need expanding and Constraint [6]
may be too strict?
Reword (part of the description for a Viewpoint appears under the
description of the association for a Stakeholder).
If a Concern is modelled as a stereotyped dependency (client being
Stakeholder and supplier being ArchitectureView) then the notion of
Stakeholders having concerns which are addressed by the ArchitectureView
has been resolved.
PerformanceMeasurePeriod or PerformanceMeasurementPeriod. Both are used. Name PerformanceMeasurementPeriod should be used. 8.4.51
TechnicalStandardsProfile should extend a Package, so UML ownership could be reused for grouping Standards
Rule is in the OperationalView package. Since there is no specific Rule for SystemView, Rule should be moved to AllViews. 8.4.46
PerformanceMeasurePeriod is in OperationalView package. It should be moved to AllViews. 8.4.51
SystemsNodeElements should include SystemGroup so that we can include whole configurations.
SystemsNodeElements should use Resource instead of OrganizationalResource. SO that SystemsNodes can be nested.
View/Viewpoint should be imported from SysML, not redefined
Diagram contains element that are not in the model - PerformanceMeasure and PerformanceMeasurementSet,
Goal, Policy, Standard and Doctrine should be connected to elements using a stereotyped dependency. This gains SysML compliance, makes integration with Requirements tools easier. It would create atleast one new steretyped dependency similar to <<Satisfy>>.,
SV-9 talks about forecasted technologies, their impact to the systems, forecast covering services and service areas. In order to facilitate reusability Technologies should be first class objects.
Description for ResourceCompetence does not explain the difference from CompetenceRelationship. It should be reworked
Association between Standard and ConformingElement should be navigable in one direction only. Standard should not be changed if Elements is applied to it., 8.7.3
Standard is too restrictive about linked element. Any element should be able to satisfy Standard, 8.7.3
NetworkPaths, SystemSystemSoftware, SystemNodeElements should be removed and UML composite structure should be reused
Effect could be a regular Activity instead of OpaqueBehavior, which is "A behavior with implementation-specific semantics.",
This description needs to be brought in-line with the description in
section 4.3.4.3
DLODIssues Type should be an enumerated list of 'issues' (as opposed to
colours) and should list 'None Outstanding', 'Manageable', 'Critical',
'Unknown' and 'Not Required'.
This is not an example of an AcV-2 View See www.modaf.com for an
example
The reference to CADMID should be removed as this contradicts the
statement of process neutrality in the Rationale (section 1.7.1)
Qualified name in the OCL constraints should be full, not just "UPDM::StereotypeName"
Why do you need CapabilityDependency. Regular Dependency could be used
OrganizationalRole has bad chapter number, 8.4.32.9
Why OperationalNodePort is needed?, 8.4.23
CapabilityConfigurationCapabilities is plural, while other stereotyped associations are not
Doctrine is too restrictive about linked element. Any element should be able to satisfy Doctrine, 8.3.11
Policy is too restrictive about linked element. Any element should be able to satisfy Policy, 8.4.41
CapabilityOperationalCapability could be replaced by UML metaproperty useCase., 8.5.6
CommunicationsLink/Path/System vs CommunicationLink/Path/System. What is the correct name?,
SystemFunction, SystemInterface, CommunicationLink, DataExchange cannot be measured as stated in DoDAF spec:
"SV-7 builds on SV-1, SV-2, SV-4, and SV-6 by
specifying performance parameters for systems and system hardware/software items and their
interfaces (defined in SV-1), communications details (defined in SV-2), their functions (defined
in SV-4), and their system data exchanges (defined in SV-6).", 8.3.10
DoDAF spec specifies these Rule types: "One of: Structural Assertion, Action Assertion, Derivation". It is lost in the UPDM., 8.4.46
MaterielBehavior is not needed. OwnedBehavior property for BehavioredClassifier could be reused for linking Materiel and behaviors., 8.4.10
There should be a constraint defining that a Classifier for a PerformanceMeasurementSet should be PerformanceParameterSet, 8.3.14.6
TaskInvocation is listed in OperationalView packages, however belongs to both Operational and Systems Views., 8.4.47
Possible conflict between Viewpoint/Stakeholder/Concern in UPDM and SysML. Stakeholder and Concern are String types properties in SysML and they are first class constructs in UPDM
Name conflict with SysML::Viewpoint,
ActivityRealization is Association, while CommunicationPathRealization is a Realization. Seems to be inconsistent., 8.4.2.
Some "realizations" are relationships - ActivityRealization, some - objects - OperationalActivityRealization. Seems to be inconsistent and misleading.,
OCL constraint is missing for the DataExchange, constraining that realization should be "Needline" (Association), 8.6.11.6
OCL constraint is missing for the InformationExchange, constraining that realization should be "Needline" (Association), 8.4.8.6
Diagram for PerformanceParameterSet does not show the association to the ConformingElement.,
There should be a constraint defining that an Owner of PerformanceParameterType should be stereotyped PerformanceParameterSet, 8.3.16.6
Conforming element description: "ConformingElement provides a link from profile elements to specific standards in the context of a forecast." It is not just forecast, but performance measurement as well, 8.3.10.3
According to DoDAF specification, a Network is "A collection of communications links (and systems nodes and
systems where applicable)". Current implementation imply that Systems and SystemsNodes are not a part of Network, 8.6.15
"A Network is a collection of one or more CommunicationPaths. It may contain multiple CommunicationPaths between
the same pair of Systems. This is typically realized by the Network owning a set of CommunicationPaths." This is not completely true. A network is a System, so it can be composed from other Systems, 8.6.15.3
DataElementSystemFunction is not needed, since you can tie SystemFunction and DataElements via activity (SystemFunction) parameters, 8.6.10
According to DoDAF spec, CommunicationLink is "A communications link connects systems nodes or systems
(including communications systems)". A CommunicationsPath is "A series of communications links that support an interface (from
SV-1)". That means that Systems and SystemsNodes may be included in CommunicationsPath. Right now, only CommunicationsSystems are allowed., 8.6.4
Description for RealizedSystemSpecification states: "Specifies that a System or one of its sub stereotypes realizes an interface stereotyped SystemFunctionSpecification or one
of its sub stereotypes." However, there are no sub stereotypes, 8.6.18.3
According to DoDAF spec CommunicationLink is "A communications link connects systems nodes or systems
(including communications systems)". Now only Systems are allowed., 8.6.3
CommunicationPath must have a Network assigned. There might be no Networks, 8.6.4.5
"CommunicationPath is realized by a CommunicationsSystem". In order to get a sequence of Systems that compose a CommunicationPath we need to use supplierDependency collection. But it is not navigable and not ordered., 8.6.5
Why do you need a SystemPort if it does not add any new information, 8.6.44
It is not described how DataExchange is related to SystemInterface and DataElement, 8.6.11
ActivityRealization should be moved to AllViews package from OperationalView, since it talks about both SystemFunctions and OperationalActivities,
OperationalActivityRealization, SystemServiceConsumer, SystemServiceProvider should be displayed as System sub stereotype.,
How can you show the CommunicationPathRealizesSystemInterface?,
There is no way to provide type (tcp/ip, wireless, etc) for CommunicationLink, 8.6.3
Network is a collection of Systems and CommunicationLinks, why explicitly define the collection of CommunicationPaths, 8.6.4
SystemNodeElements is duplicated by regular UML composite structures, 8.6.48
Is it OK to have "Relationship" in the stereotype name? This is not common UML practice. Chapter 8.4.6
Some time/date related attributes are Strings, some TimeInterval. It could be unified
Decomposition level for OperationalNode should be a derived property
"A System can be expressed in UML using a variety of
constructs, for example, a component or a class.". Stereotype <<System>> can be assigned only to the Class., 8.6.33.3
System description should talk about linking to the SystemFunctions - via System Tasks, 8.6.33
SystemTask should have SystemFunction as method property? Not clear from a description, 8.6.52
SystemActivityFunction is used in examples., p. 398
InterfaceRealization should be the metaclass for RealizedSystemSpecification., 8.6.18
Is it OK to have "Relationship" in the stereotype name? This is not common UML practice. Chapter 8.4.31
Why SystemTask - Trigger association is navigable to one way only, and OperationalTask - trigger is navigable both ways?
DLOD elements appears as stereotype and as Class in the Class Library
Table of enumeration literals contains duplicates
There can be a confusion between ExternalReferences and ExternalReference
OperationalStateTrace description - "This is the state machine for OV-5."
It will be hard to visualize SystemInterfaceImplementsNeedline because it is a dependency between relationships
Having service and serviceArea as String properties for Standard prohibits of usage DISR ar model library
SystemView or Systems View
Doctrine-SystemTask association contains different multiplicities on different diagrams
Why DataExchange cannot access DataElements in carries?
What is the preffered way for visualizing some of the stereotyped associations, for example, DataElementSystemFunction, where connected elements are from different products
SV10 talks about 3 variations (a, b, and c) in the description, but this is information does not appear in the model
Relation between OperationalActivityRealization and System should be generalization, not extension
System cannot be decomposed from other systems
SystemGroupMember is duplicated by association between stereotypes
Trigger stereotype conflicts with UML metaclass
SystemNodeElements is duplicated by association between stereotypes
Realization between stereotypes has no semantic meaning
CommPathFromTo is duplicated by association between stereotypes
SystemSystemSoftware is duplicated by association between stereotypes
Realization between stereotypes has no semantic meaning
NetworkPaths is duplicated by association between stereotypes
GroupForecast is duplicated by association between stereotypes
Dependency between stereotypes has no semantic meaning
Why it is NetworkPaths, not NetworkPath
DeliveredCapability is duplicated by association between stereotypes
DoDAF spec says about command, control, coordination, etc organizational relationships. UPDM says about solid and dotted. It is incorrent to have graphical difference as data type.
OV6 talks about 3 variations (a, b, and c) in the description, but this is information does not appear in the model
OperationalCapabilityEffect is duplicated by association between stereotypes
EffectAffectsNode is duplicated by association between stereotypes
OperationalNodeCapabilityRequirement is duplicated by association between stereotypes
Associations between InformationExchange and Needline/SystemInterface are navigable to one direction only, so you cannot "reach" SystemInterface/Needline from InformationExchange. Is this done deliberately?
OperationalCapabilityRoleCompetence is duplicated by association between stereotypes
CommPathFromTo stereotype for association will look weird on the diagram
Extremely long stereotype names for associations will distort diagrams. For example OperationalNodeCapabilityRequirement
CapabilityRequirementCapability is duplicated by association between stereotypes
CapabilityOperationalCapability is duplicated by association between stereotypes
Two "effect" association end for OperationalNode
Needline is duplicated by association between stereotypes
"NodeCasuseEffect.
Typo"
Realization between stereotypes has no semantic meaning
MaterielBehavior is duplicated by association between stereotypes
Lot of "MaterieBehavior". Typo
ActivityRealization is duplicated by association between stereotypes
"A PerformanceMeasurementrSet includes a set of PerformanceMeasures for each PerformanceMeasurePeriod. The set is applied to ConformingElements. (See UPDM Class Library). This stereotype is applied to instances of classes stereotyped PerformanceParameterSet.
ConformingElements are not part of UPDM Class Library anymore"
Possible conflict between Conform stereotype in SysML and UPDM
"Specification is the ancestor of all the stereotypes that extend Instance Specification. It implements the common attribute, description.
Attribute is missing"
ResourceCapabilityConfiguration is duplicated by association between stereotypes
Wrong chapter number for requirements
Possible conflict between Requirement stereotype in SysML and UPDM
ActivityRelazation could be potentially implemented as ownedBehavior
Association between Vision and Enterprise is duplicated by UML ownership
Dependency "Conform" has no sematic meaning between stereotype and confuses reader.
Diagram is too small
ResourceCompetence is duplicated by association between stereotypes
ResourceCapability is duplicated by association between stereotypes
StakeholderConcern is duplicated by association between steretype
There are 2 associations between Concern and stakeholder
"This Stereotype is applied to the PerformanceMeasurementSet in the UPDM ClassLibrary.
PerformanceMeasurementSet is not part of UPDM Class Library"
OperationalCapabilityRoleResource is duplicated by association between stereotypes
Capability and StrategicMission should have an association between them (BMM, where Capability is mapped to Strategy of BMM)
[1] Asserts that the SystemsNodes are required to be deployed to zero or more Locations, have OrganizationalResources, HardwareItems, SoftwareItems, Networks, SystemGroup,or Systems deployed on them, and house OperationalNodes; and that these are the elements associated with this SystemsNode.
let e1:uml::Class = self.oclAsType(uml::Association).endType-> at(1).oclAsType(uml::Class) in let e2:uml::Class = self.oclAsType(uml::Association).endType-> at(2).oclAsType(uml::Class) in
(e1.getAppliedStereotype('UPDM::SystemsNode')>notEmpty() and (e2.getAppliedStereotype('UPDM::System')>notEmpty() or e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') >notEmpty() or e2.getAppliedStereotype('UPDM::OperationalNode')>notEmpty() or e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') >notEmpty() or e2.getAppliedStereotype('UPDM::Location')>notEmpty() or e2.getAppliedStereotype('UPDM::OrganizationalResource')->notEmpty()or
e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OrganizationalResource') ->notEmpty() or
e2.getAppliedStereotype('UPDM::SystemGroup)->notEmpty())
)<<<Note - I think this is an extra parenthesis here>>>
or (e2.getAppliedStereotype('UPDM::SystemsNode')>notEmpty() and (e1.getAppliedStereotype('UPDM::System')>notEmpty() or e1.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') >notEmpty() or e1.getAppliedStereotype('UPDM::OperationalNode')>notEmpty() or e1.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') >notEmpty() or e1.getAppliedStereotype('UPDM::Location')>notEmpty() or e1.getAppliedStereotype('UPDM::OrganizationalResource')->notEmpty() or
e1.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OrganizationalResource') ->notEmpty() or
e1.getAppliedStereotype('UPDM::SystemGroup')->notEmpty())
SystemsNodeElements should use Resource instead of OrganizationalResource so that SystemsNodes can be nested.
SystemsNodeElements should include SystemGroup so that we can include whole configurations.
MISSING Documentation, and thus missing a constraint number. [2] inserted and the rest incremented
[2] "Asserts that there is an association between a System and SystemSoftware."
self.getAllAttributes().association ->
any (getAppliedStereotype('UPDM::SystemSystemSoftware')>notEmpty())>notEmpty()
[1] [1] If a Needline exists between two OperationalNodes, then there must exist a SystemsNode that hosts each of the OperationalNodes and a SystemInterface must exist between them.
This OCL only checks for the existence of a SystemInterface it says nothing about the Needline and the Systems nodes.
The systemsNodes would have to have Systems that are connected by the System Interface, and the SystemInterfaceImplementsNeedline association to associate the Needline and the SystemInterface. The constraint as described in [1] would have to be on SystemsNode, not on an individual system. This constraint may be OK for :"There must be at least one SystemInterface defined on a System".
self.getAllAttributes()>asOrderedSet()>
select(association->notEmpty()).association->any
(getAppliedStereotype('UPDM::SystemInterface')> notEmpty())>notEmpty()
We need a usage statement like this:
Usage: Create a class and stereotype if <<PerformanceParameterSet>>. This Class will be associated with the Conforming Elements to which its instances apply.
Create attributes that specify the performance measurements that are to be performed
Create an instance of a the PerformanceParameterSet, and stereotype it <<PerformanceMeasurementSet>> this measurement set will have a PerformanceMeasurementPeriod that is one of Baseline, Target Actual.
Provide the slot values for each of the attributes specified in the PerformanceParamenter set for this performance period.
Do the same for the other two performance periods
Set the conformingElement property to the corresponding element to which the PerformanceParameterSet applies, and set the performanceMeasurements property in the element.
conformingelement : ConformingElement [1]
multiplicity is wrong - should be [1..*]
This association refers to SystemFunction but should refer to System and SystemFunctionSpecification. However, it also appears that this stereotyped association and its constraints is not necessary. If it is, then OperationalNode and OperatoinalNodeSpecification should have an "InformationElementOperationalNode" association.
[1] Asserts that this SystemState models the behavior of a System, one of its specializations or an OperationalActivityRealization
self.owner.getAppliedStereotype('UPDM::OperationalActivityRealization')->notEmpty() or
self.owner.getAppliedStereotype('UPDM::System')->notEmpty() or
self.owner.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') ->notEmpty())
Don't need self.owner.getAppliedStereotype('UPDM::OperationalActivityRealization')->notEmpty() or
Even is the stereotype generalizes other stereotype, its Extensions section should not be empty, since extension is inherited. Currently the spec if very hard to read.
"UPDM Class Library" or "Class Library". Both names are in the diagrams
conformingelement : ConformingElement [1]
multiplicity is wrong - should be [1..*]
PerformanceMeasureSet should be PerformanceMeasurementSet
MilestonePoint is duplicated by association between stereotypes
TimeInterval datatype conflicts with UML metaclass TimeInterval.
We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes.
Since Mission is associated with Vision and vision with Goal, then we can follow the association to Objective to obtain the objectives of the mission. (BMM).
Association end names should be on the diagrams
[4] Asserts that an OperationalActivity must be owned by an OperationalNode, one of its specializations or an OperationalCapabilityRealization.
let x:uml::Class = self.owner.oclAsType(uml::Class) in
x.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty() or
x.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
x.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty()
Don't need :
x.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty() or
[5]
In an SystemFunction, if a callBeahviorAction that references a stereotyped SystemFunctionbut is NOT contained in a partition that meets the OwnedBehavior_rule constraint, then the constraint fails. It should be valid if the context of the activity referenced in the call behavior action is owned by the context of theSystemFunction that owns the call behavior action.
[1] Asserts that there are zero or more Competencies provided by the Resource and that zero or more Resources provide a Competence and that these are the elements associated by this association
(self.endType-> at(1).getAppliedStereotype('UPDM::Competence')-> notEmpty() and
self.endType-> at(2).getAppliedStereotype('UPDM::Resource')-> notEmpty() or
self.base_Association.endType-> at(2).getAppliedStereotypes()> collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty()
) or
(self.endType-> at(2).getAppliedStereotype('UPDM::Competence')-> notEmpty() and
self.endType-> at(1).getAppliedStereotype('UPDM::Resource')-> notEmpty() or
self.base_Association.endType-> at(1).getAppliedStereotypes()> collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty() )
Don't need 'baseAssociation' clause
sematics statement uses terms from am earlier submission - e.g. OrganizationalRole
ArchitectureView::variation is missing description
[1] Asserts that a ResourceCapability association exists between a Resource and the Capabilities that it provides and that these are the elements associated with this association
(self.endType-> at(1).owner.getAppliedStereotype('UPDM::Capability')-> notEmpty() and
self.endType-> at(2).owner.getAppliedStereotype('UPDM::Resource')-> notEmpty()or
self.base_Association.endType-> at(2).getAppliedStereotypes()>collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty() ) or
(self.endType-> at(2).owner.getAppliedStereotype('UPDM::Capability')-> notEmpty() and
self.endType-> at(1).owner.getAppliedStereotype('UPDM::Resource')-> notEmpty()or
self.base_Association.endType-> at(1).getAppliedStereotypes()>collect(allParents())> any(qualifiedName = 'UPDM::Resource') ->notEmpty())
Don't need .'baseAssociation'clause
[1] Asserts that this StateMachine is owned either by an OperationalNode or an OperationalCapabilityRealization
self.owner.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
self.owner.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or
self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()
Don't need :
self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()
[1] Asserts that the owner of the OperationalEventTrace is either an OperationalNode or an OperationalCapabilityRealization.
self.owner.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
self.owner.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or
self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()
Don't need :
Or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()
[7] Asserts that the element has at least one Standard associated with it.
self.standards->forAll(getAppliedStereotype('UPDM::Standard')->notEmpty())
Standard multiplicity relationship to Architecture view should be *, not 1.
[1] Asserts that Concerns is not empty
self.concerns-> forAll(getAppliedStereotype('UPDM::Concern')->notEmpty())
Rule only checks for ArchitectureView, should check for all of the specializations of ArchitectureView.
Should be:
self.client->forAll(getAppliedStereotype('UPDM::ArchitectureView')->notEmpty() or
getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::ArchitectureView') ->notEmpty()) and
self.supplier->forAll(getAppliedStereotype('UPDM::Viewpoint')->notEmpty())
[1]
In an OperationalActivity if a callBeahviorAction that references a stereotyped OperationalActivity but is NOT contained in a partition that meets the OwnedBehavior_rule constraint, then the constraint fails. It should be valid if the context of the activity referenced in the call behavior action is owned by the context of the OperationalActivity that owns the call behavior action.
[1] Asserts that Concerns is not empty self.concerns-> forAll(getAppliedStereotype('UPDM::Concern')->notEmpty()
Concern multiplicity relationship to Architecture view should be *, not 1.
Fig 8.14 diagram shows AllView - all the names should be AllViews
[1] Asserts that one end of the associaiton is an Activity, either an OperationalActivity or a SystemFunciton and the other is an OperationalActivityRealization if the first end is an OperatinalActivity and an OpertionalCapabilityRealization if the first end is a SystemFunction
OpertionalCapabilityRealization is misspelled
Description says there is a CustomView along with all the other Viewpoints, but it doesn't exist:
"The ArchitectureView is an abstract concept that groups the following kinds of views: o All View o Operational View o System View o Technical Standards View o Acquisition View o Strategic View o Custom View "
"An ArchitectureView is a ConformingElement and thus can be related to Standards. "
However, it extends Package, and ConformingElement extends class, so it can't be a ConformingElement.
"In some cases, it is desirable to assemble elements of the model and export them for processing by an external process; perhaps to produce custom presentations or to transform them into different forms. Using the UPDMAttributes, an external URI can be designated as the processing element, and the components within the View can be assembled as needed to complement the external process. "
"UPDMAttributes" should be "ExternalReferences"
Description is confusing.
If the ArchitectureViews are Viewpoints, as described in the Viewpoint description:
"ArchitectureView can be used to implement the Viewpoint/View capability. As a UML Package, ArchitectureView is a nested construct. Using a CustomView, a new Viewpoint can be defined, and custom views can be defined within this new package. "
then the Views should not be subclasses of them. That is if OperationalView is considered a Viewpoint, then OV-1, a View should not be a specialization.
On the other hand, <<Vewipoint>> specializes ConformingElement that extends Class, so the ArchitectureViews, OperationalView, etc. can't be Viewpoints. So what is a Viewpoint?
Diagram 8.39 should be in section 8.4.2.3
Vision should be related to StrategicMission (BMM)
Policy needs to be applicable to a much wider range of elements.
SystemGroupMember should include all of System specializations
8.6.39.6 Constraints
[1] Asserts that there are zero or more System elements configured on the SystemGroup and that these are the elements associated with this association
let e1:uml::Class = self.oclAsType(uml::Association).endType-
>at(1).oclAsType(uml::Class) in
let e2:uml::Class = self.oclAsType(uml::Association).endType-
>at(2).oclAsType(uml::Class) in
(e1.getAppliedStereotype('UPDM::SystemGroup')->notEmpty() and
(e2.getAppliedStereotype('UPDM::System')->notEmpty() or
e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') ->notEmpty()) ))
or
(e2.getAppliedStereotype('UPDM::SystemGroup')->notEmpty() and
(e1.getAppliedStereotype('UPDM::System')->notEmpty() or
e2.getAppliedStereotypes()>collect(allParents())>any(qualifiedName = 'UPDM::System') ->notEmpty()) ))
[3] Asserts that there is a Capability Requirement for this OperationalNode
OCL for [4] is correct for [3], but need OCL for [4]
[3] Asserts that there is at least one OperationalNode associated with this CapabilityRequirement
self.getAllAttributes()>asOrderedSet()>select(association-> notEmpty()).association-> any(getAppliedStereotype('UPDM::OperationalNodeCapabilityRequirement')> notEmpty())>notEmpty()
[4] Asserts that an association exists between the CapabilityRequirement and at least one OperationalCapability
self.getAllAttributes()>asOrderedSet()>select(association-> notEmpty()).association-> any(getAppliedStereotype('UPDM::CapabilityRequirementCapability')> notEmpty())>notEmpty()
RealizedSystemSpecification should extend InterfaceRealization, not just Realization.
· InterfaceRealization (from UML 2)
Need an association between OperationalCapabilityRole and Goal so that we can model intent as a link between instance of a goal and an instance of OperationalCapabilityRole . If we define <<Objective>> then this relationship should be between Objective and OperationalCapabilityRole.
"EventTrace" should be "OperationalEventTrace"
CapabilityRequirement associates an OperationalNode and OperationalCapability. The OperationalCapability is defined as a collaboration among OperationalNodes whose behavior is reflected in an OperationalEventTrace, an OperationalActivity or an OperationalStateTrace. The CapabilityRequirement shows the deliverable requirements - metrics, time period and milestones.
Policy should be in the All Views package
[1] Asserts that this StateMachine is owned either by an OperationalNode or an OperationalCapabilityRealization. self.owner.getAppliedStereotype('UPDM::OperationalNode')>notEmpty() or self.owner.getAppliedStereotypes()>collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') - >notEmpty()
don't need
or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') - >notEmpty()
because OperationalCapabilityRealization is a specialization of OperationalNode
Description is wrong - it is the same as SV-5
Should be:
"The Systems Data Exchange Matrix specifies the characteristics of the data exchanged between Systems. This product focuses on automated exchange of information (from OV-3) as actually implemented from a variety of data sources. Non-automated exchange of information, such as verbal orders, is captured in the OV products only."
Forecast needs to apply to Capability, OperationalCapability and CapabilityConfiguration
PerformanceMeasurementSet needs to have conformingElement instance rule, in addition to the conforming element. The constraint makes sure the link exists.
Need to have a stereotyped association between ConformingElement and PerformanceParameterSet.
RealizedOperationalSpecification should extend InterfaceRealization, not just Realization.
· InterfaceRealization (from UML 2)
the 3 items in [1] are in the wrong font.
Description for OperationalState Trace is incomplete
<<ProjectType>> is superfluous unless it has much more semantics from MODAF.
Need association between Goal and OrgResource that "defines" the Goal (BMM)
This specification used the following design principles that support the domain needs and design rationale described above.
Change to:
This specification used the following design principlesthat support the domain needs and design rationale described
The paragraphs:
Needlines may be generated automatically, derived from InformationExchanges, from ActivityEdges in OperationalActivities, and from Messages in OperationalEventTraces.
Is a duplicate of the same paragraph in the previous section
The paragraph:
In structure diagrams where two OperationalNodes are depicted with a Connector belonging to a message, the Connector should be typed with the appropriate Needline that represent the message in an OperationalEventTrace or control flow in an OperationalActivity.
Does not make much sense
The SysML stereotype references in the UPDM specification need to be updated to reflect the latest results of the SysML FTF revisions.
There appears to be a typo in the table. Note that the elements repeat in the table
Should there be some association between ArchitectureDescription and Enterprise depicted? If not why is the Enterprise Stereotype shown here?
Constraint 4 documentation does not match OCL shown
There is a reference to PerformanceMeasurementPeriod, yet PerformanceMeasurementPeriod is not defined in the document.
Need a constraint that asserts that the DataExchange must be realized by at least one of the realizations
Need a constraint that asserts that the InformationExchange must be realized by at least one of the realizations.
9. UPDM Class Library Compliance Level 0
Change "Class" to "Model"
"Class Library" should be "Model Library"
Figure is shrunk down
Figure is messed
Image shown is to small to read
Footer is "Business Maturity Model" should be "UML Profile for DoDAF and MODAF, Beta 1
Is an OrganizationalRole different than an OperationalCapabilityRole? If so, this should be stated. UPDM spec should provide examples of the differences.
The text says that "The concept of an actor or resource that realizes an OperationalNode has been made explicit by using OrganizationalResource that plays an OperationalCapabilityRole in the context of an OperationalNode." There seems to be two interpretations in the DoDAF field of 'who' does 'what' on an OperationalNode (the 'where'). Some interpretations seem to be that the OperationalNode is conceptual, and can be a 'who' and a 'where'. However, in MITRE’s Activity Based Method, the metamodel specifically states that a Role performs an Operational Activity on an Operational Node. Therefore an Operational Node is a “where”, and a Role is a “who”. DoDAF 1.5 has introduced the concept of OperationalRole but it seems to be a different concept than specifying a 'who' – in other words, DoDAF 1.5 says an OperationalNode plays the OperationalRole of 'service provider', 'service consumer', or 'unanticipated user'. This is different than saying the OperationalRole is the 'who' that can be many different types of roles (besides those three). In this referenced paragraph in the UPDM spec, it would seem that the interpretation is that an OperationalNode can be a 'who', and that 'who' is specified by OperationalCapabilityRole, which can take on values "Service Provider", "Service Consumer", and "Unanticipated User". What of other roles then? Should OrganizationalRole (also in the UPDM domain metamodel) be used to specify 'who' does 'what' on an OperationalNode (the 'where')? All of this should be clearly sorted out in the UPDM domain metamodel and described clearly in the UPDM text.
Add stereotyped association between Milestone and Capability Configuration.
Chapter 1, paragraph 1, line 3 "Ministry of Defense" should be "Ministry of Defence" (note UK spelling of "Defence" in the name of the UK ministry concerned). I checked, and as far as I can tell all other instances of "Ministry of Defense" are correctly spelled.
Refine the L1 compliance example in Section 10 that was included in the approved December ballot of the resolution to Issue-11237. The page numbers 8-17 refer to the page numbers in the proposed resolution that was on the ballot.
resolve how vision, requirements, and view/viewpoint are extended in the UPDM compliance level 1 (SysML)
OperationalServiceProvider has been introduced because of DoDAF 1.5. If one is to assign an Operational Node the OperationalCapabilityRole of OperationalServiceProvider, shouldn’t they also specify the Service that the Operational Node is providing? If so, or if not, the text in the Description (paragraph B.4.19.3) should specify how one uses this property value. Right now it seems open to interpretation.
OperationalServiceConsumer has been introduced because of DoDAF 1.5. If one is to assign an Operational Node the OperationalCapabilityRole of OperationalServiceConsumer, shouldn’t they also specify the Service that the Operational Node is consuming? If so, or if not, the text should specify how one uses this property value. Right now it seems open to interpretation.
What UPDM elements/constructs relate to the DLOD elements. I think the first cut is: Training - competence (amplified by organization delivering competence) Equipment - material Logistics - ? Infrastructure - System Node Organization - Organizational Resource Doctrine/concepts - Doctrine Information - ? Personnel - roles/competence
Text describes three instances of OperationalRole, yet the picture only has two it is missing “Unanticipated User”. Note: In the DoDAF 1.5 spec, "Unanticipated User" is specified as one of the three types of OperationalRoles that should exist, so the text seems correct
There is no level identifier property for OperationalActivity