Add a 3-way Resource Traceability Matrix that includes function->Operational Activity->Capability where the matrix intersection displays the associated Capabilities.

Deferred to future versions of UAF

Deferred to future versions of UAF

ResourceInteractionKind should really be called ResourceExchangeKind.

ResourceIntercationKind renamed to ResourceExchangeKind

ResourceIntercationKind renamed to ResourceExchangeKind

Reported in behalf of NATO ACaT group.
DMM diagrams readability needs to improved:
-missing association role names need to be added;
-hidden attributes need to be shown;
-BPMN aliases need to be hidden;
-missing multiplicities needs to be shown.

Multiple diagram changes were done to improve readability of the document

Multiple diagram changes were done to improve readability of the document. At the same time cosmetic adjustments were done on Profile document diagrams.

modify title and text for DMM diagram legend

modify title and text for DMM diagram legend

modify title and text for DMM diagram legend

Sv-Pr has recommended implementations for BDD, IBD and Tabular format. This is for showing ServiceFunctions (i.e. Activities) so IBD isn’t going to work and Activity Diagram (the most obvious choice) is missing.

Update and modify desccription text for Sv-Pr MM and Profile

Update and modify desccription text for Sv-Pr MM and Profile
not required

In the mapping tables for UAF views to DoDAF/MODAF Views, you just have StV-6 mapped to St-Tr, but StV-6 (at least in part) would seem to be a good fit for Op-Tr as well.

StV-6 is now only mapped to Operational Traceability

StV-6 is now only mapped to Operational Traceability
Looks ok to me

Sc-Tx mapped to IBD doesn’t make sense – it doesn’t show any parts.

Update and modify desccription text for Sc Tx MM and Profile

Update and modify desccription text for Sc Tx MM and Profile so it is implemented as BDD

Not an issue as far as i can i see

Timeline as a recommended implementation for Sv-Tr doesn’t make sense – I think this should be tabular.

Recommended Implementations updated for Sv-Tr

Changed from:
"Recommended Implementation: timeline, SysML Block Definition Diagram, SysML Internal Block Diagram"
to
"Recommended Implementation: tabular or matrix format."

Pr-Ct mapping looks like it should include the OV-4 Actual as a potential mapping.

Pr-Ct mapping should include the OV-4 Actual as a potential mapping.

Update text

Inconsistent naming for State Diagrams – sometimes called State Machine Diagram (correct) but other times just called State Diagram (incorrect but matches our metamodel atm).

SysML State Diagram replaced with SysML State Machine Diagram

SysML State Diagram replaced with SysML State Machine Diagram

Ov-Ct has BDD as a recommended implementation but Sv-Ct (which is basically the same) doesn’t. Seems like one of them should be changed.

Update and modify desccription text for Op-Ct, Rs-Ct and Sc-Ct MM and Profile

Update and modify desccription text for Op-Ct, Rs-Ct and Sc-Ct MM and Profile to be implemented as either IBD or Table(s)

OV-1a is mapped as Op-Sr and SmOV – it should probably only be SmOV, as it’s an overview more than an operational structure.

*OV-1a should not be mapped as Op-Sr and SmOV *

Update traceability matrix, but yes OV1-a should be mapped to SM Ov as is it can be overview of scenario

OV-1b is not mapped to anything – I’m guessing it should be mapped to the SmOV?

OV-1b should be mapped to the SmOV

Update tracreability matrix

Sd mappings are wrong in Annex B:
a. Tx = TV-2 BDD
b. Sr = TV-2 IBD

Sd mappings are wrong in Annex B:

Not an issue

Pj mappings are wrong in Annex B:
a. Tx = AcV-3 BDD (typical)
b. Sr = AcV-3 BDD (actual)
c. Cn = AcV-3 BDD (actual & typical)
d. Pr = AcV-2 AD (missing completely, even though ProjectActivities were added back in)
e. Rm = AcV-2 Timeline & AcV-1 Tabular

Pj mappings are wrong in Annex B

Not an issue

The changes to KnownResource don’t make any sense to me. Why change it to a Class? What does it mean now? The text is the same as it was when KnownResource was used to show a Resource inside the context of a Node, but makes no sense now it’s not a part and can’t be used in the same way.

Definition for Known Resource revised

Definition for Known Resource revised

OV-1c and SV-7 are better fits for Pm-Me, rather than Pm-En. The UPDM views were responsible for showing performance attributes, which doesn’t really have anything to do with defining environments (though the performance attributes would contain environmental properties as well as other properties).

OV-1c and SV-7 are better fits for Pm-Me

Looking into UAF traceability document it is exactly the same mapping as requested. However, there is a problem with Figure 6.3 - Overlay of MODAF Views onto UAF/P Grid that needs to be updated.

the table looks ok to me GJB

<submission on behalf of James Johnson>
In the UAF Specification, the diagram for CapableElement (Figure 30) identifies EnterprisePhase as a CapableElement. The diagram for EnterprisePhase(Figure 42) does not show this relationship.
However, the specification for EnterprisePhase does identify CapableElement.

Capable Element shown in Enterprise Phase Diagram

Capable Element is added to Capable Element Diagram

<submitted on behalf of James Johnson>
The diagram for AssetRole (Figure 155) identifies SecurityProperty as an
AssetRole. The diagram for SecurityProperty (Figure 156) does not show this relationship.

Security Property does not exist anymore

SecurityProperty was removed from the profile as a result of solving UAF11-16 issue. This issue is no longer relevant.

<submitted on behalf of James Johnson>
Text for ResponsibleRoleKind refers to ResponsibleRole. However, ResponsibleRoleKind is identified as an enumeration for ResponsibleFor (Figure 113). text and figure don't match. (p 92-93)

Text updated

Text changed for Resource Role Kind. Instead of "ResposibleRole"it is now "ResponsibleFor". Also typo corrected on ResponsibleFor documentation.

<submission on behalf of James Johnson>
For completeness, consider listing ActualProject and ActualResource as CapableElements. Additionally, Achiever and Desirer should be listed as CapableElements. Please investigate and add if deemed appropriate.

Actual Resource and Actual Service are now Capable Elements

It makes perfect sense to allow Exhibits relationship to be drawn between Actual Resource and Capability. The same applies to Actual Service as the Service Specification is Capable element. However, in case of Actual Project, we do not agree. Actual Project as well as project cannot directly exhibit capability. As for Achiever, all subtypes of achiever are already Capable elements except Actual Project. As for Desirer it would not make sense to have it as Capable Element because one of its subtypes is Capability. Capability cannot exhibit Capability.

If DataModel contains InformationElements as well as DataElements, should it really be part of the Resource domain? Similarly, if DataModel can be the subject of an OperationalConstraint, shouldn’t it also be subject of a ResourceConstraint too?

Data Model moved to Metadata and made a specialization of Subject of Resource Constraint

Data Model and Data Model Kind moved to Metadata and made a specialization of Subject of Resource Constraint

OperationalExchange.trustlevel should be called OperationalExchange.trustLevel, as “trustlevel” isn’t a word.

trustlevel changed to trustLevel

trustlevel changed to trustLevel

The ResponsibleFor.ResponsibleRoleKind tag should start with a lowercase letter like all of the others appear to be and, to be even more consistent, should probably just be called kind.

ResponsibleRoleKind tag now starts from lowercase

ResponsibleRoleKind tag now starts from lowercase to be consistent with other tags. The same is done with projectKind tag name in DMM.

Section 7 says “UAFP imports the entire SysML profile and contains a set of constraints that specify which SysML stereotypes are applied to the UAFP elements.”. This isn’t true. UPDM was done this way but UAF was done by inheriting from SysML stereotypes instead, so no dual stereotyping and constraints exist.

The text is updated (see description)

Replace:
"UAFP imports the entire SysML profile and contains a set of constraints that specify which SysML stereotypes are applied to the UAFP elements. This is intended to provide more seamless integration with system modeling using SysML and to be able to fully leverage the capabilities of SysML in UAFP. An example of this is the integration of Requirements into the UAFP and also the use of Parametric Diagrams and integration of elements based upon instance specifications to allow the assessment of measures within an architecture developed using UAFP."
with
"UAFP imports the entire SysML profile and a number of UAFP stereotypes inherit from SysML stereotypes. This is intended to provide more seamless integration with system modeling using SysML and to be able to fully leverage the capabilities of SysML in UAFP. An example of this is the integration of Requirements into the UAFP and also the use of Parametric Diagrams and integration of elements based upon instance specifications to allow the assessment of measures within an architecture developed using UAFP."

Operational Activities can be performed by any Operational Agent but only Operational Performers can own Operational Methods. This seems pretty inconsistent and means there’s some gaps in what you can model on things like a Sequence Diagram. Either Operational Methods should be owned by Operational Agents or only Operational Performers should be able to perform Operational Activities. I’m assuming that Operational Agents should be able to own Operational Methods.

Operational Method needs to be owned by Operational Agent

Operational Method ownership changed from Operational Performer to Operational Agent. Operational Performer inherits ownership of Operational Methods from Operational Agent. This appeared to be an issue in the profile only.

Figure 179 for ActualProjectMilestone has ActualOrganizationalResource shown but it isn’t attached to anything…

Actual Organizational Resource removed from Diagram

Actual Organizational Resource removed from Diagram

SubjectOfSecurityConstraint doesn’t allow you to constrain any elements from the SecurityDomain – is this correct?

Security Process added as a subtype of Subject of Security Constraint

Most of Security Domain elements are indirect subtypes of Subject of Security Constraint. The only really missing part was Security Process, which was added as a subtype of Subject of Security Constraint.

SecurityControlFamily has a constraint for annotedElement – this doesn’t belong to a Class…

Incorrect constraint removed

Incorrect constraint removed from SecurityControlFamily

Figure 211 for Strategic Connectivity shows a Capability with a Dependency, which is fine. However, the recommended implementations mention IBD, which doesn’t make sense with this subset of views. Should CapabIlityProperty be shown with Dependencies too – like we used to have in UPDM?

Role Dependency added to Strategic Connectivity

Role Dependency added to Strategic Connectivity. CapabilityProperty renamed to CapabilityRole to reflect DMM

Figure 260 for Security Processes contains additional items to those list in the elements list below it. Also, part of the description for the view mentions SecurityControls, which aren’t shown on the figure. I’m assuming the diagram is correct, as things like Security Process aren’t listed and the element list is wrong, as things like Security Control are shown on the Constraints diagram.

Security Control Properties removed from Security Processes Diagram

Most of the comments are already addressed except for Security Control Properties that needs to be removed from Diagram

Should have an IBD version for the Operational Taxonomy view – it is for showing ConceptRoles after all…

Recommended implementations of Operational Taxonomy now includes SysML ibd

Recommended implementations of Operational Taxonomy now includes SysML ibd

Diagrams and text out of date.

Update DMM sections on UAF grid, Domain interelatiohips and descriptions

delete original section 1 in DMM 17-12-02 and add content of UAF 11 DMM 7-9. docx

Update OMG boiler plate and add new sections describing UAF background, conformance, references, terms and definitions and symbols

Update and add sections 1 through 6.5 from UAFP and move to UAF DMM document

delete and update sections 1-6.5 from 17-12-01
add text in UAF 11 DMM sect 1-6.4.docx to front of UAF DMM document
Should cover sections 1-6.4
add text in UAFP introduction.docx to front UAFP document

Will need to renumber the CB document

Op-Cn is mapped to OV-3 and OV-6, but only OV-3 would seem to make sense (especially since OV-6a/b/c are mapped to other diagram types).

Operational Connectivity is mapped to OV-2 and OV-3

Operational Connectivity is mapped to OV-2 and OV-3 as both capture Operational Exchanges between OperationalPerformers.

Required environment on the LocationHolder is currently linked to Environment which is a type. It does not make sense to link it to a type. Required environment needs to be linked to ActualEnvironment.

Required Environment changed to Actual Environment

Required Environment changed to Actual Environment

Security Property name does not reflect the meaning of the concept. It needs to be renamed.

Information Role and Data Role elements introduced to substitute Security Property

Security Property was introduced in UAF to capture whole-part between Operational Performers and Information Elements and Resource Performers and Data Elements. The name of the Security Property was misleading and it had to be changed.

From UAF patterns presentation.

Add 3D UAF representation

Needed to give an overview of the logical relationships between the UAF Aspects

Move requirements row to be a column.
Add recommended visulizations.

Update UAF Grid

Update grid to take into account NAF 4

Due to the missing mandate that UAF support DoDAF 2.02 views and viewpoints, for presenting content, UAF is considered non-compliant to DoDAF 2.02 by some. Require the implementation of the DoDAF perspective using UAF to provide DoDAF 2.02 Views for compliance.

Duplicates UAF11-7

Duplicates UAF11-7

Describe how UAF conforms to NAF 4 (when it is released).

Updated NAF 4 Grid Graphic and Table

Updated Grid and Table

"A. The Unified Architecture Framework (UAF) is required to conform to the Department of Defense Architecture Framework Version 2.02 (DoDAF 2.02). ..." See attachment for details.

Proof of DoDAF conformance

We have mappings in the UAF documentation (Appendix B, formal/17-12-03) that map UAFP elements to DODAF 2 elements and also to map UAF/P Viewpoints/Views to DODAF 2 Viewpoints/Views.

This mapping is complete and shows that UAF/P can implement the development of DODAF 2 architectures and also fulfill the need for fit for purpose views.

Figure 53 for Achiever shows AchievedEffect twice.

Diagram updated to show Achieved Effect once

Duplication of Achieved Effect shape removed from the Achieved Effect diagram

Figure 43: EnterpriseVision.statement should be derived or removed. EntepriseVision is connected to VisionStatements through the fact they annotate them (as shown on Figure 44) so a non-derived tag as well seems superfluous…

Vision Statement is made derived

Vision Statement is made derived

Figure 39: Actual Enterprise Phase: Concern.systemConcern seems like the inverse name of what the tag should be. I’d expect it to be something like addressingPhase/addressedBy for Concern > EnterprisePhase and systemConcern (if we really must use that name) for EnteprisePhase > Concern…

Name of the association end changed on both sides of the association

Name of the role change on both sides of the association:
-systemConcern changed to enterprisePhase
-concern role name added on the other side of association
-association made navigable on both ends
-multiplicity set to many to many

Figure 39: Actual Enterprise Phase: The forecastPeriod tag is set to 0..*, but it should be (I think) set to 0..1. This assumption is based on the textual description of forecast (which says “an EnterprisePhase”) and my understanding of what this is for.

Multiplicity changed to 0..1

One or zero Actual Enterprise Phases can be associated with one Forecast.

Page 43, under Figure 38: Constraints [c] and [d] for Implements.supplier should be merged together like the one above.

Constraint body updated

Constraints [c] and [d] for implements supplier merged.

There should be a depiction for ServiceObjectFlow and ServiceControlFlow, tied to ServiceFunctionAction, to be consistent with OperationalActivityAction and FunctionAction

Duplicates UAF11-126

Duplicates UAF11-126

Multiple diagrams show inconsistencies between themselves, including
a. Metadata (Figure 35) shows a link to UAFElement, but UAFElement (Figure 214) does not show link to Metadata
b. Implements (Figure 38) shows a link to ResourceConnector, but ResourceConnector (Figure 126) does not show link to Implements
c. CapableElement (Figure 30) shows a link to EnterprisePhase, but EnterprisePhase (Figure 42) does not show link to CapableElement
d. ActualEnduringTask (Figure 49) shows a link to ResponsibleFor, but ResponsibleFor (Figure 113) does not show link to ActualEnduringTask
e. ConceptRole (Figure 61) shows a link to HighLevelOperationalConcept, but HighLevelOperationalConcept (Figure 62) does not show link to ConceptRole
f. OperationalStateDescription (Figure 84) shows a link to OperationalAgent, but OperationalAgent (Figure 64) does not show link to OperationalStateDescription
g. ServiceSpecification (Figure 89) shows a link to ServiceInterface, but ServiceInterface (Figure 95) does not show link to ServiceSpecification
h. ServiceMethod (Figure 90) shows a link to ServiceParameter, but ServiceParameter (Figure 91) does not show link to ServiceMethod
i. ServiceParameter (Figure 91) shows a link to OperationalExchange, but OperationalExchange (Figure 74) does not show link to ServiceParameter
j. Consumes (Figure 101) shows a link to OperationalActivity, but OperationalActivity (Figure 78) does not show link to Consumes
k. Command (Figure 107) and Control (Figure 108) show a link to DataElement, but DataElement (Figure 139) does not show links to Command or Control
l. CompetenceForRole (Figure 111) shows a link to Competence, but Competence (Figure 110) does not show link to CompetenceForRole
m. RequiresCompetence (Figure 112) shows a link to OrganizationalResource, but OrganizationalResource (Figure 103) does not show link to RequiresCompetence
n. ResponsibleFor (Figure 113) shows a link to ActualProject, but ActualProject (Figure 185) does not show link to ResponsibleFor
o. ResourceRole (Figure 125) shows a link to ActualOrganizationRole, but ActualOrganizationRole (Figure 201) does not show link to ResourceRole
p. ResourceConnector (Figure 126) shows a link to Environment, but Environment (Figure 15) does not show link to ResourceConnector
q. VersionedElement (Figure 146) shows a link to ActualProjectMilestone, but ActualProjectMilestone (Figure 186) does not show link to VersionedElement
r. ProtocolImplementation (Figure 150) shows a link to Protocol, but Protocol (Figure 189) does not show link to ProtocolImplementation
s. Asset (Figure 151) shows a link to MeasurementSet, but MeasurementSet (Figure 23) does not show link to Asset
t. SecurityProperty (Figure 156) shows a link to AssetRole, but AssetRole (Figure 170) does not show link to SecurityProperty
u. ActualRisk (Figure 163) shows a link to ActualResponsibleResource, but ActualResponsibleResource (Figure 199) does not show link to ActualRisk
v. OwnsRisk (Figure 172) shows a link to OrganizationalResource, but OrganizationalResource (Figure 103) does not show link to OwnsRisk
w. Project (Figure 174) shows a link to OrganizationalResource, but OrganizationalResource (Figure 103) does not show link to Project
x. ActualProject (Figure 184) shows a link to ActualResponsibleResource, but ActualResponsibleResource (Figure 199) does not show link to ActualProject
y. ActualProjectMilestone (Figure 186) shows a link to ActualOrganizationalResource, but ActualOrganizationalResource (Figure 194) does not show link to ActualProjectMilestone
z. ActualResponsibility (Figure 198) shows a link to ActualOrganizationalResource, but ActualOrganizationalResource (Figure 194) does not show link to ActualResponsibility
aa. ActualResourceRole (Figure 202) shows a link to ResourceRole, but ResourceRole (Figure 125) does not show link to ActualResourceRole
bb. OwnsProcess (Figure 209) shows a link to OperationalActivity, but OperationalActivity (Figure 78) does not show link to OwnsProcess

All comments resolved

The list of actions taken:
UAFElement Diagram now shows link to Metadata
Resource Connector Diagram now shows links to ResourceMessage and Implements
Responsible For removed from Actual Enduring Task Diagram
ConceptRole added to HighLevelOperationalConcept Diagram
OperationalStateDescription added to OperationalAgent Diagram
ServiceSpecification added to ServiceInterface Diagram
ServiceParameter added to OperationalExchange Diagram
Consumes added to OperationalActivity Diagram
Command and Control added to DataElement diagram
CompetenceForRole added to Competence diagram
ResourceRole added to ActualOrganizationalRole diagram
Resource connector added to Environment diagram
VersionedElement added to ActualProjectMilestone Diagram
Asset added to MeasurementSet Diagram
ActualRisk added to ActualResponsibleResource Diagram
ActualResourceRole added to ResourceRole Diagram

Other issues were duplicates and were already resolved by solving other issues.

Affected Diagrams:
Profile
UAFElement
ResourceConnector
ActualEnduringTask
HighLevelOperationalConcept
OperationalAgent
ServiceInterface
OperationalExchange
OperationalActivity
DataElement
Competence
ActualOrganizationalRole
Environment
ActualProjectMilestone
MeasurementSet
ActualResponsibleResource
ResourceRole

There is no example of an Op-Tr.

Merged with UAF11-83

Merged with UAF11-83

There should ideally be an example of every recommended implementation for a diagram, so implementers have an idea of what is required – not just one of them.

Merged with UAF11-83

Merged with UAF11-83

The worked example is still structured as if it was UPDM – not UAF. It’s got Personnel Views listed under Operational Views, All Views with a mishmash of things under it (with All Views not even being a view in UAF). It’s massively out of date and confusing…

Refactor example model

Refactor example model

There are inconsistencies between the worked example and the specification. Here are some examples:
a. St-Tr Strategic Traceability
i. States that the recommended implementation includes timeline, but the specification only states tabular and BDD.
ii. It doesn’t include anything connecting things to ActualEnduringTasks.

Merged with UAF11-83

Update descriptions in document

The Sc-Pr example doesn’t seem to match the specification. It’s showing SecurityControls related to Resources via Protects relationships, with Resources being related to SecurityControls with IsCapableToPerform relationships. There’s a few issues with this:
a. Protects isn’t on the list of items to show in the view (though it probably should be as it isn’t listed anywhere).
b. You can’t connect IsCapableToPerform relationships between Resources and SecurityControls – it goes from Resources to SecurityProcesses.
c. You should be showing some SecurityProcess composition.

Merged with UAF11-83

Merged with UAF11-83

Pr-Sr is not equivalent to OV-4 Actual – it doesn’t show any instances (i.e. Actual things)… I’m guessing the Pr-Sr should be equivalent to the OV-4 Typical and Actual, but the list of shown elements is wrong, as well as the mapping.

Personnel Structure is now mapped to OV-4 Typical only

Personnel Structure is now mapped to OV-4 Typical only
In UAF Traceability doc.

There’s no example of the Sv-Rm view.

Merged with UAF11-83

Merged with UAF11-83

IBD mapped to Ar-Sr doesn’t make sense – you can’t show InstanceSpecifications on an IBD…

Ar-Sr recommended implementation is now BDD only

In UAFP 17-12-01
A.2.9 View Specifications::Actual Resources
Text changed from
"Recommended Implementation: SysML Block Definition Diagram, SysML Internal Block Diagram."
to
"Recommended Implementation: SysML Block Definition Diagram."

OwnsProcess should be shown on Figure 76.

Owns Process added to Operational Activity diagram

Owns Process added to Operational Activity diagram

ServiceOperation should be shown on Figure 89.

Service Method added to Service Parameter diagram

Service Method added to Service Parameter diagram

ProtocolImplementation should be shown on Figure 182.

Protocol Implementation added to Protocol diagram

Protocol Implementation added to Protocol diagram

Class for Operational Port is constrained to be Operational Performer, which means that Operational Architecture cannot own it. Class for Operational Port meeds to be Operational Agent.

Operational Port can be owned by Operational Agent

Operational Port can be owned by Operational Agent which means both Operational Performer and Operational Architecture can both own it.

The ServiceFunction diagram (Figure 96) is depicted different then the Operational Activity diagram Figure 78) and the Function diagram (Figure 132). For OperationalActivity and Function the Implements and IsCapableToPerform relationships is depicted with a stereotype while for the ServiceFunction these same relationships ae depicted as stereotyped relationships. There should be some consistency between the three diagrams.

Service Function Diagram updated to be consistent with Operational Activity and Function Diagrams

Service Function Diagram updated to be consistent with Operational Activity and Function Diagrams.

1) The UAFElement stereotype has multiple child stereotypes but none appear on the diagram. UAFElement children include:
a. LocationHolder
b. MeasureableElement
c. PropertySet
d. ActualState
e. ISO8601DateTime
f. CapableElement
g. Achiever
h. Desirer
i. ConceptItem
j. SubjectOfOperationalConstraint
k. SubjectOfResourceConstraint
l. SubjectOfSecurityConstraint
m. SubjectOfForecast
n. VersionedElement
o. ProtocolImplementation
p. AssetRole
q. ProjectStatus
r. ActualResourceRole
s. ActualResourceRelationship
t. Architecture
u. Stakeholder

Subtypes of UAF element are added to the UAFElement diagram

Subtypes of UAF element are added to the UAFElement diagram

ActualOrganizationalResource (Figure 194) has no Metaclass

Metaclass Displayed

Metaclass for ActualOrganizationalResource displayed in ActualOrganizationalResource diagram

Text for ActualMilestoneKind refers to ActualMeasurements instead of ActualProjectMilestone

Actual Milestone Kind Description Changed

Actual Milestone Kind Description Changed to "Enumeration of the possible kinds of ActualProjectMilestone."

On Figure 186, there is no line between ActualOrganizationalResource and ActualProjectMilestone

Actual Organizational Resource removed from Actual Project Milestone Diagram

Actual Organizational Resource removed from Actual Project Milestone Diagram

ProjectRole (Figure 177) does not show as a child of ResourceRole (Figure125)

Project Role added to Resource Role Diagram

Project Role added to Resource Role Diagram

There is an inconsistent depiction of VisionStatement between the VisionStatement diagram (Figure 44) and the EnterpriseVision diagram (Figure 43)

Duplicates UAF11-39

Duplicates UAF11-39

CapabilityForTask is duplicated on the Capability diagram (Figure 40)

Duplication Removed

Duplication of CapabilityForTask removed

The OperationalExchange diagram (Figure 73) uses Implements as a stereotyped relationship, not as a stereotype There should be some consistency for all diagrams.

OperationalExchange Diagram is now consistent with other diagrams

Implements relationship displayed on the diagram like in other diagrams

<Submitted on behalf of James Johnson>
ActualOrganizationalResource (Figure 148) does not list
ActualResponsibility as an ActualOrganizationaIResource. The diagram for ActualResponsibility (Figure 198, p 150) designates ActualResponsibility as an ActuaIOrganizationalResource. UAFSpecification needs to resolve this discrepancy.

Actual Responsibility shown on the Actual Organizational Resource Diagram

Actual Responsibility shown on the Actual Organizational Resource Diagram

<submission on behalf of James Johnson>
ActualService (Figure 205) should not appear as both ActualPropertySet (Figure 14) and ActualMeasurementSet (figure 13) The dual inheritance is confusing. Please clarify

Generalisation to ActualPropertySet removed

Actual Service transitively Inherits from Actual Property Set via Actual Measurement Set. Direct Generalisation to Actual Property Set was redundant and has been removed.

<submitted on behalf of James Johnson>
In Figure 14 of the UAF Specification, the line between ActualProject and ActualPropertySet is missing. This relationship is also not reflected in Figure 185 (ActualProject). Not certain whether ActualProject is or is not an ActualPropertySet. Please clarify.

ActualProject removed from ActualPropertySet diagram

ActualProject indirectly inherits from Actual Property Set. ActualProject removed from ActualPropertySet diagram.

Figure 40 – Capability, shows CapabilityForTask twice.

Duplicates UAF11-150

Duplicates UAF11-150

Figure 163 for Risk doesn’t show a specialization to Block but the text above the figure states that Risk does specialize Block.

Block is now shown on the Risk diagram

Block is now shown on the Risk diagram

Figure 140 for DataModel doesn’t show an extension to a UML type.

Data Model extension added to Data Model diagram

Data Model extension added to Data Model diagram

The ResourceRole.RoleKind tag should start with a lowercase letter.

*RoleKind tag name starts with lowercase r *

RoleKind tag name starts with lowercase r

Figure103 for OrganizationalResource is missing some relationships. For example, RequiresCompetence.

Diagram updated adding missing elements

Missing elements added to the OrganizationalResource diagram:
Project,
OwnsRisk,
RequiresCompetence

Figure 277 for Services Connectivity doesn’t show ServiceSpecificationRole, so you’re very unlikely to ever be able to show ServiceConnectors as part of this view…

Services Connectivity updated to show Service Specification Roles

Services Connectivity updated to show Service Specification Roles

ActualService doesn’t need to directly inherit from ActualPropertySet - is already indirectly inheriting via ActualMeasurementSet.

Duplicates UAF11-125

Duplicates UAF11-125

Figure 182 for Protocol should show the relationship to implementers.

Duplicates UAF11-112

Duplicates UAF11-112

SubjectOfSecurityConstraint is specialized by Asset but not AssetRole – is this correct? (probably related to the previous question)

*Asset role is now a subtype of Subject of Security Constraint *

Asset role is now a subtype of Subject of Security Constraint

SecurityControl cannot be a specialization of PropertySet and a specialization of Requirement. The SysML 1.4 specification states Requirements can’t have ownedAttributes or be involved in Associations. This conflicts with PropertySet that has Measurements (Property). Also, Requirements can’t be used to “type any other element”, which is very vague, but could be read as it can’t be (amongst other things) the classifier for an InstanceSpecification (i.e. ActualPropertySet). Either SecurityControl shouldn’t be a Requirement or it can’t be a PropertySet…

Security Control inherits from MeasurableElement.

SecurityControl updated to inherit from MeasurableElement rather PropertySet.
Affected Diagrams:
Profile:
-SecurityControl
-PropertySet
-MeasurableElement

Figure 277 for Services Connectivity doesn’t show anything related to provided/required interfaces, as mentioned in the description for the view…

Description of the Service Connectivity is updated

Description of the Service Connectivity is updated

Figure 76 for OperationalActivity is missing OwnsProcess.

Duplicates UAF11-111

Duplicates UAF11-111

The example for the Pr-Tx is incorrect. It’s only supposed to show generalizations, not structure. Structure is supposed to be shown on the Pr-Sr.

Helps to show structure on taxonomy diagrams

Gudiance from NATO is that they are allowing mix of structure and generalization on taxonomy diagrams, UAF Group also feels that this is acceptable practice

In quite a few places the Tx and Sr views overlap. My understanding was that the taxonomy views provide somewhere to get a list of all the items and the inheritance between them, with the structure views providing somewhere to show the structure. However, the Tx views quite often contain composite structure as well, which makes no sense to me…

Helps to show structure on taxonomy diagrams

UAF Group allows this overlap. As it can reduce the number of views required to express an archtecture.

The OwnsRiskInContext has the wrong constraint text (looks like it was copied and pasted from OwnsProcess).

Owns Risk in Context constraint text updated

Owns Risk in Context constraint text updated from OwnsProcess to OwnsRiskInContext

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

ResourceStateDescription can be assigned to ResourcePerformer and all subtypes. It is considered to be a state machine. However, no definition of state machine given

Yes, the definition of Statemachines is derived from the UML MM.

modify relevant diagrams to show relationship to UML semantics

modify state machines diagrams in MM

Operational States
Resource States
Services States
Personnel States

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

No evidence found to show structure of InformationElement, or any of its superclasses. However, Figure 6-14 of the example shows InformationElements with relationships. What is the UAF concept for this?

Yes. Aggregation and composition relationships of types are implicitly derived from UML MM.

Update Information model MM and profile diagrams

Modified information models diagrams in MM and Profile diagram to show data aggregation.

Information Model MM Shows WholePart
Information Model Profile Shows Class, Type on role

need to add descriptions to Metada row

Update descriptions for MetaData row of Grid

Update descriptions for MetaData row of Grid

Constraints OwnsProcess.* should be renamed to OwnsRiskInContext.*

Duplicates UAF11-108

Duplicates UAF11-108

AchievedEffect is duplicated on the Achiever diagram (Figure 53)

Duplicates UAF11-43

Duplicates UAF11-43

<Submitted on behalf of James Johnson>
Diagram for UAF Specification for MeasurableElement (Figure 21) only identifies 13 UAF Elements that are considered MeasurableElements (Exchange, OperationalConnector, OperatlonalRole, OperationalActivityAction, ProvidesCompetence, Rule, ServiceParameter, Activity, FunctionAction, ResourceRole, ServicePort, OperationaISignalProperty, ResourceSignalProperty). However, when going through the specification an additional 68 UAF Elements are identified as MeasurableElements. If representing all 81 MeasurableElements in
MeasurableElements diagrams too cumbersome, suggest adding a table identifying all MeasurableElements. MeasurableElements not depicted in diagram include:
1. Achieved Effect
2. Affects
3. AffectsInContext
4. Alias
5. ArbitraryConnector
6. ArchitecturaIDescription
7. ArchitecturalReference
8. CapabilityForTask
9. CapabilityProperty
10. CompetenceForRole
11. CompetenceToConduct
12. ConceptRole
13. Consumes
14. Definition
15. DesiredEffect
16. Enhances
17. EnvironmentProperty
18. Exhibits
19. FillsPost
20. Forecast
21. FunctionEdge
22. Implements
23. Information
24. IsCapabIeToPerform
25. MapsToCapability
26. Measurement
27. Metadata
28. MilestoneDependency
29. Mitigates
30. OperationalActivityEdge
31. OperationalMessage
32. OperationalMethod
33. OperationaIParameter
34. OperationalPort
35. OperationaIStateDescription
36. OrganizationlnEnterprise
37. OwnsProcess
38. OwnsRisk
39. OwnsRisklnContext
40. PerformslnContext
41. ProjectMiIestoneRole
42. ProjectSequence
43. ProjectTheme
44. Protects
45. ProtectslnContext
46. ProtocolLayer
47. RequiresCompetence
48. ResourceConnector
49. ResourceMessage
50. ResourceMethod
51. ResourceParameter
52. ResourcePort
53. ResourceStateDescription
54. ResponsibleFor
55. SameAs
56. SecurityProperty
57. ServiceConnector
58. ServiceFunctionAction
59. ServiceMessage
60. ServiceMethod
61. ServiceSpecificationRole
62. ServiceStateDescription
63. Statuslndicators
64. StructuralPart
65. TemporalPart
66. VersionOfConfiguration
67. VersionSuccession
68. VisionStatement

All subtypes of MeasurableElement displayed on the diagram

All missing subtypes visualized on the diagram

<Submitted on behalf of James Johnson>
Diagram for UAF Specification for PropertySet (Figure 21) only identifies 13 UAF Elements that are considered PropertySets (Asset, ProjectMilestone, Capability, Resource, Competence, Servicelnterface, Condition, ServiceSpecification, EnterprisePhase, WholeLifeConfiguration, MeasurementSet, Resourcelnterface, Risk). However, when going through the specification an additional 10 UAF Elements are identified as PropertySets. lf representing all 23 PropertySets in the PropertySet diagram is too cumbersome, suggest adding a table identifying all PropertySets.
PropertySets not depicted in diagram include:
a. Concern (p 158-159)
b. EnduringTask (p 52)
c. EnterpriseGoal (p 45-46)
d. EnterpriseVision to (p47)
e HighLevelOperationalConcept (p 59)
f Operationallnterface
g. SecurityControl
h. Standard
i. View
j. Viewpoint

All subtypes of Property Set are displayed in Property Set diagram

All subtypes of Property Set are displayed in Property Set diagram.

Figure 88 for ServiceMethod shows a ServiceMethod having its owner constrained from two different directions. It shows the ownership being constrained using the ownedOperation role from ServiceInterface and via the owner role to ServiceSpecification. It should be consistent.

Owner metaconstraint changed to ownedOperation metaconstraint

Direction of metaconstraint connecting ServiceMethod and Service Specification reversed and uml role changed to ownedOperation. This makes diagram consistent with the generic style of specification.

Figure 214 for Strategic Roadmap – Deployment shows a ResponsibleFor Abstraction going between an ActualResponsibleResource and an ActualProjectMilestone. Similar to the previous issue, this doesn’t appear to be allowed. Also, this is (as far as I can tell) so you can define who the Resources from the Milestone are being deployed to/removed from, but the name ResponsibleFor really doesn’t work and neither do any of the ResponsibleForKind literals. I think a new, different relationship should probably be added. At the moment, I can’t see a way to fulfil the requirements of this view.

Duplicates UAF11-40

Duplicates UAF11-40

Figure 49 for ActualEnduringTask shows that it is a valid supplier for the ResponsibleFor Abstraction. However, the definition for ResponsibleFor states (textually and diagrammatically) that only ActualProject and ActualResponsibility can be the supplier. I’m assuming Figure 49 is incorrect. We also don’t have ActualProjectMilestone in the text.

ResponsibleFor is removed from ActualEnduringTask diagram and added to ActualProjectMilestone diagram

ResponsibleFor is removed from ActualEnduringTask diagram and added to ActualProjectMilestone diagram

Figure 34: The constraint text for Information’s annotatedElement role does not match the diagram. The text says it can only annotate ConceptItems but the diagram shows UAFElement. I believe the diagram is correct.

Constraint text changed to align with Diagram

Information's Annotated element constraint text changed to be aligned with Information Diagram

Energy is mentioned in a few places in the UAF specification, in particular around Exchanges. However, the Energy stereotype no longer exists and doesn’t appear to have been replaced by anything. I’m think this is a mistake.

ResourceArtifact or NaturalResource can be used to capture Energy

Resource Artifact can be used to capture human converted Energy, e.g. Electricity
Natural Resource can be used to capture natural energy, e.g. Solar Power
Having Energy would be confusing to distinguish the origin of the energy.

Figure 178 for ActualProject shows it specializing ActualOrganizationalResource and Achiever, but the text states ActualPropertySet and Achiever. Based on the XMI, I believe the figure is correct and the text is wrong.

Both Text and Diagram are aligned in UAFP spec. formal/17-12-01

Both Text and Diagram are aligned in UAFP spec. formal/17-12-01

Figure 261 for Security Constraints shows SecurityContol and EnhancedSecurityControl, etc, but the elements list does not. I’m assuming the diagram is correct.

Security Control and Enhanced Security control are in both Diagram and List

Security Control and Enhanced Security control are in both Diagram and List in UAF 1.0 spec.

Figure 262 shows an invalid relationship. OwnsRisk is shown going between ResourceRole and Risk, when it should go between ResourcePerformer and Risk. OwnsRiskInContext goes between ResourceRole and Risk though… Same for Affects, etc, too.

In the UAF 1.0 spec. the issue does not exist

In the UAF 1.0 spec. the issue does not exist.

Listing abstract stereotypes in the Elements list within Annex A, when they’re only shown in the figure to get inherited features is potentially misleading. For example, Figure 128 for Operational Structure lists Asset, but I’m imagining you wouldn’t want every kind of Asset displayed for this View, just the specific specializations that are also listed (e.g. OperationalPerformer, etc).

Abstract Elements should be in the list

Abstract Elements should be in the list because you need to be able to easily navigate to them to check what is underneath them.

The diagram for OperationalObjectFlow (Figure 82) does not show links to OperationalActivityAction as does OperationalControlFlow (Figure 81). These should be consistent.

Links to action are not shown because object flow does not connect actions

Links to action are not shown because object flow does not connect actions. It connects object nodes, like pins, parameters, etc. In UAF there are no stereotyped object nodes to show this connection.

The diagram for FunctionObjectFlow (Figure 136) does not show links to FunctionAction as does FunctionControlFlow (Figure 134). These should be consistent.

*Links to action are not shown because object flow does not connect actions *

Links to action are not shown because object flow does not connect actions. It connects object nodes, like pins, parameters, etc. In UAF there are no stereotyped object nodes to show this connection.

Op-Tx has a recommended implementation of BDD – it should be IBD, as it’s for showing ArbitraryConnector relationships (Dependencies) between ConceptRoles (Properties), which you can’t do on a BDD.

It is already captured in the description of the view specification

It is already captured in the description of the view specification

Rs-Rm looks to have a copy and paste error. It shouldn’t have recommended implementations as timeline, IBD and BDD – it should be matrix/tabular and BDD.

Correct as is

Correct as is

Typo in the figure 235 text.

No Typo found

No Typo found

Sv-Tr looks to have a copy and paste error. It shouldn’t have recommended implementations as timeline, IBD and BDD – it should be matrix/tabular and BDD.

Refers to issue in old spec

Refers to issue in old spec, fixed in FTF

St-Rm mapped to IBD doesn’t make sense. It doesn’t show parts anywhere, just instances. This should be mapped to an Object Diagram instead.

Refers to issue in old spec

Refers to issue in old spec, issue was corrected in FTF

The XMI has ProjectActivityAction extending Activity and CallBehaviourAction – shouldn’t include Activity.

*Extension removed. *

Project Activity Action is only Extending Call Behavior Action

ServiceMessageHandler looks to have been removed because AsynchronousMessage is no longer being used. However, now that OperationalSignal, etc, have been added, we need Receptions to link the Signals to the Performers that can handle them. Looks like something important has been missed.

There is no need to add additional stereotypes

There is no need to create stereotypes for signal receptions. UML signal receptions can be successfully used for this purpose as they can be associated with Operational and Resource Signals.

RequiresCompetence has been changed to an Abstraction and set to specialize Allocate but ProvidesCompetence hasn’t. Is that a mistake?

Provides Competence is dependency

Provides Competence connects Competence to Actual Organizational Resource which is an instance spec. The only reason to change it to abstraction would be inheritance from SysML Allocate. However, as Actual Organizational Resource is Instance Specification the use of Allocate doesn't make sense.

Submitted on behalf of Torsten Graeber in response to comments made by UAF group to queries previously submitted queries made by Torsten Graeber, June 2017

No evidence found in UAF M2 that supports decomposition of activities. Reviewed elements: OperationalActivity->Activity->MeasurableElement->UAFElement. Potentially OperationalActivityAction is the intended concept (see e.g. Figure 11-20 in the UAF example).

Yes, it is implicitly derived from the UML Metamodel which allows the decomposition and reuse of Operational Activities as OperationalActivityActions.

Modified relevant diagrams to relfect relationship with UML semantics

Added UML elements to relevant diagrams to capture relationship to UML MM Semantics

Operational Processes,
Resource Processes,
Services Processes,
Operational Interaction Scenarios
Resource Interaction Scenarios
Services Interaction Scenarios