Enterprise Mission in UAF is a specialization of Actual Enterprise Phase. But in what sense is a Mission some kind of Phase? Mission is defined in UAF as "captures at a high level what you will do to realize your vision". A Phase is not "what you will do" but rather organizing a collection of things to do to achieves goals assigned to that Phase. Need to put Mission into UAF the way it was done in UPDM. Mission is more like an Enduring Task. In UPDM a Mission was an extension of a Use Case. Need to also add a way to capture a Mission Thread.

See attached slides.

The UAF Modeling Language (UAFML) especially suited for modeling an enterprise and as such it is appropriate for modeling a large and complex mission architecture along with its variety of scenarios, vignettes, MTs, METs, etc. The following extensions to UAF will provide support for Mission Engineering and alignment with best practice.
The following elements need to be added to UAF to support Mission Engineering.
1 Mission The task, together with the purpose, that clearly indicates the action to be taken and the reasoning behind the mission. (JP 1-02)
2 MissionThread A sequence of end-to-end mission tasks, activities, and events presented as a series of steps to achieve a mission. (OUSD(R&E))
3 ActualMission A particular mission to accomplish assigned mission objectives
4 ActualMissionPhase A particular phase in the accomplishment of an overall actual mission
5 MissionScenario Description of the geographical location and timeframe of the overall conflict. A scenario includes information such as threat and friendly politico-military contexts and backgrounds, assumptions, constraints, limitations, strategic objectives, and other planning considerations. (OUSD(R&E))
6 MissionVignette Same contents as a MissionScenario except that it can represent small, ideally self-contained parts of a scenario. (OUSD(R&E))
7 ActualMissionScenario A particular mission scenario within which an actual mission is to be accomplished
8 ActualMissionVignette A particular mission vignette within which an actual mission is to be accomplished
9 MissionTask A clearly defined action or activity specifically assigned to a system, individual or organization that must be completed. (MEG 2.0).
10 MissionTaskAction The usage of a MissionTask within a MissionThread.
11 MissionEngineeringThread A sequence of end-to-end mission-related resources, functions, actions, states, and events presented as a series of steps that supports a mission thread
12 ConflictsWith Tuple that indicates elements acting against or in opposition to each other. This means that there are elements in the model that disagree about something important or are incompatible with each other in some way
13 Opposes Tuple that indicates an open clash between two opposing groups (or individuals). This means that elements in the model are fighting against each other or are providing strong resistance to progress towards some goals
14 OpposableElement Type of element that is categorized to allow for it to have an Opposes relationship to some other opposable element.
15 DesignationKind Defines the type of structural element with respect to purpose, intent and capabilities of that element.
16 Doctrine A formal expression of military knowledge and thought, accepted as being relevant at a given time, which covers the nature of conflict, the preparation of the military forces for conflict, and the method of engaging in conflict to achieve success... it is descriptive rather than prescriptive, requiring judgement in application.
17 Defines A tuple that links the Mission and the Activity that implements it.
18 MissionKind An enumerated list of kinds of missions. These include:
19 Battle A hostile encounter between opposing military forces
20 Campaign A series of related major operations aimed at achieving strategic and operational objectives within a given time and space. (JP 5-0)
21 Engagement A tactical conflict, usually between opposing lower echelons maneuver forces. See also battle; campaign. (JP 3-0)
22 MajorOperation A series of tactical actions (battles, engagements, strikes) conducted by combat forces, coordinated in time and place, to achieve strategic or operational objectives in an operational area. (JP 3-0)
23 NationalPolicy A broad course of action or statements of guidance adopted by the government at the national level in pursuit of national objectives. (JP 1)
24 Other A different kind of mission.
25 SmallUnitAndCrewAction Small unit and Crew Action is the combat deployment of platoons and smaller units in a particular strategic and logistic environment
26 TheaterStrategy An overarching construct outlining a combatant commander’s vision for integrating and synchronizing military activities and operations with the other instruments of national power in order to achieve national strategic objectives. See also national military strategy; national security strategy; strategy. (JP 3-0)
27 ForceDesignation Indicates whether the structural element is an enemy, ally, neutral or other force. The colors may vary according to country so can be replaced as required. These include:
28 BlueForce Structural elements corresponding to the instigating or friendly force.
29 RedForce The structural element is an enemy force.
30 GreenForce The structural element is an ally.
31 GrayForce The structural element is a third party force.
32 Unknown The structural element is unknown.
33 WhiteForce The structural element is neutral.
For support of Doctrine, a new element will need to be created called Doctrine which is a subtype of both requirement and standard. It will contain the following fields:
1 createdBy The organization or creator of the standard or doctrine.
2 publishedBy An entity responsible for making the resource available.
3 createdStandards A relationship between an actual organization and the standards created by that organization.
4 publishedStandards A relationship between an actual organization and the standards published by that organization.
For enterprise architectures and mission engineering we need to be able to define a new type of a constraint which is an assumption.
Assumption EnumerationLiteral added to RuleKind Enumeration indicating that the element is accepted as true or as certain to happen, without proof.
The following Diagrams will need to be created to support modeling of Missions:
1 Resources Processes: Mission Engineering Threads
Stakeholders: Solution Providers, Systems Engineers, IT Architects.
Concerns: captures activity based behavior and flows performed by resources and organizational assets.
Definition: describes the functions that are normally conducted in the course of implementing operational activity(ies) in support of capability(ies). It describes the functions, their Inputs/Outputs, function actions and flows between them.
Recommended Implementation: SysML Activity Diagram, SysML Block Definition Diagram."
2 Operational Processes: Mission Threads "[Need a new description according to the template below]
Stakeholders: Business Architect, Systems Engineers, Enterprise Architects
Concerns: captures activity based behavior and flows performed by mission actors and related operational and strategic assets.
Definition: describes the activities that are normally conducted in the course of achieving business goals that support a capability. It describes operational activities, their Inputs/Outputs, operational activity actions and flows between them.
Recommended Implementation: SysML Activity Diagram, SysML Block Definition Diagram, BPMN Process Diagram."
3 Strategic Processes: Mission "[Need a new description according to the template below]
Stakeholders: Program/Project Managers, Portfolio Managers, Enterprise Architects, Executives.
Concerns: capability phasing.
Definition: shows the relationship between strategic phases and the Capabilities that are intended to be developed during the strategic phases, and the actual organizations involved.
Recommended Implementation: SysML Block Definition Diagram."
4 Parameters: Mission Vignette and Scenario "[Need a new description according to the template below]
Stakeholders: Capability owners, Systems Engineers, Solution Providers.
Concerns: defines the environments and conditions for execution of mission(s)+C10
Definition: shows the elements and relationships that are involved in defining the environments and conditions applicable to capability, operational concept or set of systems.
Recommended Implementation: SysML Block Definition Diagram."

Many Standards prescribe particular processes (such as ISO 15288, DO-356A, etc). Having a Standards Activity with Standards Process Flows would allow us to model the Standards as processes with inputs and outputs, then show how Operational processes ConformTo the Standards Process.

Viewpoints are defined as a convention for creation, interpretation, and use of an architecture to frame one or more stakeholder concerns.
Views are defined as the information item governed by the Viewpoint that communicates some aspect of an architecture.
Stakeholder Concerns relate to a Viewpoint, and to a View only through its "governed by" relationship to the Viewpoint.
Views may only be governed by one Viewpoint, but Viewpoints can govern many Views.

The problem is that the traceability for a Stakeholder Concern only comes through the Viewpoint (not the View itself) and thus every View that is governed by the Viewpoint is said to relate to every Stakeholder Concern framed by the Viewpoint. This may not be true.

For instance, I will use Resource Connectivity diagrams as an example for a Viewpoint. I have multiple stakeholders that may want to see a Resources Connectivity diagram. One might want to understand the internal connectors of the system. One might want to understand the flow properties of the system. One might want to understand the external connections to the system. If I make three views (one that shows internal connections, one that shows flow properties, and one that shows external connections), then all three Views are governed by the Resource Connectivity Viewpoint, and every stakeholder Concern can be addressed by Resource Connectivity, but not every View does address every stakeholder Concern. Further, I can't use the model relationships to filter my Views by Stakeholder Concern because the traceability provides every view that is governed by the Viewpoint.

I can solve this by further specifying my Viewpoints. I can specialize Resource Connectivity Viewpoint and require external connections, or internal connections, as related to the Stakeholder Concern. This requires a very high degree of specificity in my viewpoints to ensure that a query across one Stakeholder Concern does not return Views intended for other Stakeholder Concerns.

It may be better to trace Stakeholder Concerns to the Views themselves (having an "answers" or some other relationship) to allow for limitation on this query.

Op-If is mapped with DIV-1, and Rs-If is mapped with DIV-2.

According to Appendix A the correct mappings should be: Op-If <-> DIV-2, Rs-If <-> DIV-3

Fig 3.38 is missing MotivatedBy

MilestoneDependency should be renamed MilestoneSequence to
be consistent with the definition and consistent with ProjectSequence

Dependency is too overloaded

in the standard there is no statement for Sequence about whether the client is assumed to be before or after the supplier... one could
reason it either way... clients should always be dependent on suppliers... and because suppliers should have to finish before
clients can proceed it is assumed that the suppliers are the before and the clients are the after... but this should be made explicit

VersionSuccession does not tell which is the successor in the documentation does not explain which is the successor to whom... the client or the supplier... I am presuming that the client is dependent on the supplier so the client is the newer version and the supplier is the older version... needs to be explicit in the standard

architectureFramework as a String should be in the Attributes... and shown as such in the diagram and the text below needs to be altered

Forcast needs to specify explicitly in the documentation that the supplier end is the older subject and the client end is the newer subject

ComparesTo is ambiguous ... which is the desired, which is the achieved... presuming desired is the supplier and achieved is the client but should be made explicit in the standard

Forcast needs to specify explicitly in the documentation that the supplier end is the older subject and the client end is the newer subject

ProjectSequence is ambiguous ... needs to specify before and after with supplier and client

UAF is missing a CourseOfAction element... would suggest looking at ArchiMate's version of CourseOfAction as an example

Figure 9:336 – ActualService is italics yet it is not abstract... need to change

ActualService in Metamodel is abstract... it is not in profile... need to fix

some places are Project some place are Projects

e.g.
View Specifications::Projects::Roadmap::Project Roadmap

need to have a separate MilestoneSequence from MilestoneDependency

and should add a ProjectDepdency as well

Figure 9:321 – ActualProjectMilestone
Constraints
[1] unnamed1
startTime=endTime

non-named constraint

also ActualState has attributes startDate and endDate... not startTime and endTime

The word ‘realizingArchitecture’ between the [Abstract]Architecture and [Tuple]Implements is misspelled in Figure 8:11 - Summary & Overview. The letter d is redundant.
In addition, thanks to the OMG organization for developing the documentation about UAF, which made me learn a lot.

The description in this section is a copy of View Specifications::Resources::Traceability and View Specifications::Personnel::Traceability. The desciption os also not in accordance with the example problem in section 14.3 of the Sample Problem (dtc/2021-12-12). Also, Ar-Tr is missing from the UAF Grid. In summary, it is difficult to understand the view specification Actual Resources::Traceability. However, we do understand the need for a view specification according to Figure 4:82.

endDate is multiplicity 0

The Achiever abstraction bundles in the same hierarchy "production agents" (actual resources) and "transformation agents" (actual strategic phases, actual projects).
While both produce effects: the former (actual resources) are about outcomes delivered by the enterprise, while the latter are about change of the enterprise itself.
Shouldn't we distinguish these two kinds of "changes".
In page 39, indeed, the EA guide states that measurements of effect are different for 'transformation effect" versus "ways and means effects":
"A Measure of Effect (MOE) parameter describes qualitative or quantitative states or levels that directly relate to outcomes. Outcomes are sought by stakeholders, whose interests and perspectives are addressed by the actual measurements of effects. These outcome measurements are different from measurements of associated ways and means."

Proposed resolution:
1. Rename "Achiever" in initiative
2. Remove "Actual Resource" as a sub-type of Achiever

The concept of "Concept Role" is missing in the DMN while it is available in the UML profile specification.
As a consequence, ConceptItems (Location and Asset) are owned by HighlevelOperationalConcept which should not be the case.

"Enterprise Visions" & "Enterprise Goals" are supposed to be valid for the whole life of the enterprise whereas "Enterprise Objectives" are time time-targeted.

Proposal:
1. Remove "Enterprise Vision" as a sub-type of Phaseable Element. Enterprise Vision is "owned" by a "WholeLifeEnterprise" as a kind of "DesiredResult" (Ends versus Means).

2. Potentially remove "Enterprise Goal" as sub-type of Phaseable Element. "Enterprise Goal" is "owned" by a "WholeLifeEnterprise" as a kind of "DesiredResult" .
This was the original intent in MODAF (see quote below from MODAF Handbook")
"Within the StV-1 view, certain Enterprise Goals are identified. These goals relate to the entire enterprise lifetime, they are not specific to an
Enterprise Phase"

3. Add "Enterprise Objective" to enterprise phases. "Enterprise Objective" is owned by enterprise phases as a kind of "DesiredResult" .

PS: The current "Phases" relationship mixes relationhip to "Ends" (Vision, Goals, Objectives) and relatonship to Means (Capabilities).
The best practice is to separate Ends and Means.

The names of Ends on MotivatedBy to not match the EA Guide and the principles establishes by the BMM on which it is grounded.
The EA Guides says that "Enterprise Goals" are "motivated by" Drvers.

Proposal:
Rename "motivatingEnterpriseGoal" in "MotivatedEnterpriseGoal"
Rename "motivatedDriver" in "motivatingDriver".

It is not clear why "Opportunity" and "Challenges" are part of "Motivatedby" as it seems to be a separate topic.

Multiple conflicting [1.1] multiplicities on Implements

Proposed solution:
(1) "Implements" is made abstract
(2) "Implements" relates UAFElement (or better "Class of UAFElement").
(3) Appropriate concrete sub-types are created for Resource, Function, OperationalAgent, etc..

Multiple conflicting [1.1] multiplicities on PerformInContext

Proposed solution:
(1) PerformInContext is made abstract
(2) PerformInContext is relates ProcessUsage to AssetRole
(3) Appropriate concrete sub-types are created for FunctionAction, OperationalActivityAction, etc.

ActivityPerformableUnderCondition bounds "process" (a class) to an individual to individual state (ActualCondition).
This breaks the BORO principle that classes should not be time bounded.

Proposed resolution:
(1) Have actualCondition as a Type
(2) or .. have ActivityPerformableUnderCondition be related to "Condition" instead of "ActualCondition".

Multiple conflicting [1.1] multiplicities on IsCapabletoPerform.

Desirer bounds "Class Entities" (Capability, Resource Performer, ..) to individual state (Actual State).
This breaks the BORO principle that classes should not be time bounded.
There is no way to relate Capabilities to Effect (class).

Proposed resolution:
1. Desirer is made deprecated and kept for compatibility
2. A new relationship is added between capability and effect

Reported in behalf of Boeing.

Continuing the progress we have been doing on getting rid of tag properties and replacing them by dependency type of relationships, there are still some tag properties to be replaced between the view, viewpoint, concern, architecture description, and stakeholder. Having tags, they cannot be properly displayed on the diagram, where dependencies can.

UAF is currently trying to be compliant with ISO 42010. To continue with being compliant, UAF needs to be updated to conform to new term and concepts in the new version of 42010 to be published in 20022.

Since UAF is published as an ISO document, the ISO version must be compliant with the ISO style guide which has specific requirements on structure, formatting and style. Recommend that v1.3 of UAF be restructured and reformatted to be ISO compliant.

In UAF metamodel, Personnel view concepts use the Organizational Resource elements which are specialization of Resource Performers. In other words, Resource Performer is a more "abstract" concept than Organizational Resource "performers".

So, given the general pattern of rows in the grid start with most abstract at the top and most concrete at the bottom, it would be better to swap Personnel and Resources viewpoint rows so that Resources (being more abstract) appear above the Personnel (which are more concrete than resource performers).

Both the Strategic row and the States column are designated as "St" which can sometimes lead to confusion. Suggest changing Strategic viewpoint designator to "Sg" to avoid this confusion. (Similar thing was done in v1.2 when Personnel row was changed from "Pr" to "Ps" to avoid confusion with Process (Pr) column.)

NATO framework grid shows three behavioral like aspects as being grouped by Behavior. Suggest doing same for UAF Grid. Also, Taxonomy, Structure and Connectivity columns are three forms of "structure", so we should group these three columns and call that grouping Structure.

Taxonomy views are about more than "typology" and specialization since they can also include referentialization (i.e., references) and composition. These views are typically captured using SysML Block Definition Diagrams (BDD), so it would be better to call this column "Definitions".

Structure views are really about compositions, so it would be better to call this column "Compositions". Connectivity views are about dependencies, interactions or flows, so would be better to call this column "Interactions".

Actual Resources domain covers more than just instances from the Resources domain. Also covers instances from the Personnel domain (i.e., Post, Organization, Person, Responsibility). Suggest changing name to Actualization. Or perhaps merely “Actuals”?. Or perhaps “Instantiations”?. Better represents what is going on here.

See attached slides

Should be more than indication of ToBe or not ToBe. Should be a timeline of planned/expected evolution of the architecture IAW defined
states and transitions in States view. Versions should correspond to which capabilities, missions, actual measurements, etc. will be achieved for that version.

This should show more than merely “Status”. Should be a view showing the progression of maturity states for the architecture.

Should be more than just identification of a methodology (Besides, a methodology is not a process…). Should allow for capturing a process-like diagram.

One of the AM views shown in the Grid does not have corresponding View Specifications in UAFML: Architecture Taxonomy: Architecture Extensions. Add the necessary view specification in UAFML.

See attached slides

Problem with Using Portfolio element (portfolio kind of Project). The Portfolio (kind of) Project does not have the necessary semantics with the features and relationships enumerated below. Can possibly use Whole Life Configuration (WLC) element to represent a Portfolio but this only gives part of the picture of what is in the Portfolio. (a) Acts as a “collection” of things with an associated Gantt chart for deployment timelines, (b) Does not tell us who “owns” that collection of things in the Management Accountability sense, (c) A Portfolio can consist of multiple Whole Life Configurations.

Portfolio needs to have the following features: a) Things it is delivering (e.g., in its Whole Life Configurations), b) Who runs it (i.e., the Actual Organization), c) Particular programs within it (e.g., actual Projects or project elements), d) Alignment with budget elements, assigned Opportunities and Risks, etc., e) Assigned responsibility for execution of particular Enduring Tasks (and associated Capabilities), f) Accountability towards achieving Effects (e.g., MOE target levels) for a given time period, g) Can be assigned responsibility for certain Missions, Enterprise Goals and Enterprise Phases, h) Can be jointly managed with another Enterprise for shared Operations and Resources.

Might be that Portfolio could be a kind of Whole Life Enterprise (i.e. subtype) that has the features and relationships noted above.

See attached slides.

Two Architectural Descriptions must be able to reference each other which have no containment relationship to each other. Purpose: This supports the ability for architectures to reference each other when they sit in other separate projects and repository locations. Two Architectural Descriptions must be able to reference each other when there is an intervening containment organization.

See attached slides.

UAF specifies three kinds of Actual Measurements: Actual, Required, Estimate. But if only 1 of the 3 kinds is “actual” then the other 2 kinds are “non-actual”. Only one of the three kinds of Actual Measurement is truly an “actual” measurement kind. This is a logical inconsistency, which is a source of confusion for some modelers. Suggest changing the kinds to: Achieved, Required, Estimated (past tense). Suggest adding new kinds: Expected, and Desired.

See attached slides.

There is often a confusion between typical and actual measurements. Causes some modelers to use these elements incorrectly. Modelers sometimes insert the expected or desired “value” of a measurement into the Measurement element rather than in the Actual Measurement element. Does not make sense to allow Measurement to have any values since the Measurement element is intended to be the “standard” for doing the measuring. That would be like having a meter stick and marking 27 cm on the stick itself. For comparison purposes, look at definitions of Measurement and Measure in dictionary.

Definition of measurement: the dimension, quantity or capacity determined by measuring. Which is really what “actual measurement” element is dealing with. Definition of measure: a reference standard or sample used for the quantitative comparison of properties [e.g., a “yard stick” or “meter stick”].

Proposed element name changes to address this issue. Change name of Measurement element to Measure. Change name of Actual Measurement element to Measurement. As noted above, measurement is defined as being the result of measuring. Change Measurement Set to Measure Set (to align with changes above).

See attached slides.

Need to add Use Cases as a modeling construct in UAF

Need to update the EA Guide to correct some errors with respect to v1.2. Also need to update based on changes to be made in v1.3 of the metamodel and modeling language.

Need to update the sample model to finish incorporating new model views for all of v1.2. Also need to update based on changes to be made in v1.3 of the metamodel and modeling language.

NATO has a methodology for capturing NAF compliant architecture models. Instead of changing UAF to include the specialized NAF concepts, create a separate NATO Framework Guide for UAF.

Location concept in dictionary is "determination" of the "place where something is". Would Location be a more accurate term for Location Holder concept? Location in UAF is currently enumerated with *geometric" parameters such as solid volume, surface, line, point, etc. However, Location is a more general concept.

Sometimes the Operational Architecture uses concept of Platform as the "place where something is" rather than describing the location geometrically. A Platform could be thought of a special case of Location. Also, sometimes the "place where something is" will be called an Organizational Node (agnostic to an Organization resource per se).

Make Location abstract with three kinds of Location elements: Physical Location (for current notion of Location), Platform (where something is mounted or situated), and Organizational Location (a place that has a definite purpose or a place that is responsible in an organizational sense).

See attached slides.

Node was a concept in UPDM but was replaced by Operational Agent in UAF. Needline was a concept in UPDM but was replaced by Operational Connector in UAF. Since Node and Needline are commonly used concepts in the world of operational architectures and mission modeling, add these to UAF as specializations of Operational Agent and Operational Connector, respectively.

See attached slides.

In UPDM there was a Trust Line between Nodes (now called Operational Agents in UAF). There is need to have a Trust Line for security reasons which will help in modeling the security architecture for the enterprise. Add Trust Line concept back into UAF.

There is a need for the concept of Operational Scenario which can perform Operational Activities. Many modelers use an Operational Architecture as the entity to capture notion of a Scenario or Vignette or Use Case. Add Operational Scenario as new kind of Operational Agent. May also need to add Resource Scenario as new kind of Resource Performer.

See attached slides.

An architecture is defined as "fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes" [ISO 42020] An Architecture has no "agency", i.e., an architecture cannot do anything since it is a property of the thing that is being architected. Therefore, Architecture cannot be a kind of Operational Agent since an architecture cannot be "capable to perform" operational activities.

Change Operational Architecture to Operational Configuration. Change Architecture to Configuration. Change Resource Architecture to Resource Configuration. Add Architecture as new separate element and add relationship Configuration <has> Architecture. Architecture is still <described by> Architectural Description. Make Operational Architecture a Capable Element and likewise for Resource Architecture and Service Architecture. Add Service Architecture to Figure 9:130 in DMM since it is missing.

See attached slides.

Capability is defined as an "ability to do something". As such, a capability cannot desire some state or some effect. Only things with "agency" can desire something. Agency is defined as the "means or mode of acting". Operational agents and resource performers have the "means of acting" while a capability does not possess this quality. Only some kind of "action" can lead to effects or state changes. See briefing slides.

Add relationships Operational Activity <leads to> Actual State and Function <leads to> Actual State (and same for Service Function). Remove Capability as a Desirer but link it to Actual State directly with <enables> relationship. Make Capability Configuration <exhibits> Capability.

See attached slides.

To be consistent, a Service should be a kind of Desirer that can desire an Actual State, Actual Effect or Actual Outcome. This would make this parallel to Operational Agent and Resource Performer which are both kinds of Desirers.

See attached slides.

It can be expected that a Service would perform necessary Service Mitigations to deal with expected threats to that Service, similar to what is done by Operational Mitigation and Resource Mitigation for Operational Agents and Resource Performers, respectively. Add Service Mitigation as specialization of Service Architecture.

See attached briefing.

Currently a Service Function can implement an Operational Activity and a Service Interface can implement an Operational Interface. To be consistent, UAF should allow a Service to directly implement an Operational Agent. Add this new relationship Service <implements> Operational Agent.

See attached briefing.

Currently a Resource Service can implement a Service. However, the implementing performer could also be a System, Capability Configuration, Software, Technology, Organization, Person, Post, etc.

Therefore, UAF should allow any kind of Resource Performer to implement a Service. Add new relationship Resource Performer <implements> Service. Also, to be consistent, add new relationship Function <implements> Service Function. Note that a Resource Interface can currently implement a Service Interface.

See attached briefing.

Operational Agent has specializations of Operational Architecture and Operational Performer. To be consistent, UAF should allow a Service to have a specialization of a Service Performer to go along with the specialization of Service Architecture. Add new element of Service Performer.

Currently, a <<SecurityControl>> is the source of the <<mitigates>>relationship to the target <<SecurityRisk>>. Further research shows that a security control (a type of requirement) in and of itself does not actually mitigate a <<SecurityRisk>>. Rather, the <<ResourceMitigation>> that<<satisfies>> the <<SecurityControl>> requirement is the actual UAFElement that <<mitigates>> the <<SecurityRisk>>.

The only allowable relationship between <<Capability>> and any Requirement element is <<trace>>. In US Department of Defense acquisition processes, stakeholder needs are defined as capabilities within a Capability Description Document. These capabilities are high-level system requirements from which system and sub-system requirements should be derived. The recommended solution is to enable the <<deriveReqt>> to have <<Capability>> as the target and any type of <<AbstractRequirement>> as the source of a <<deriveReqt>> relationship. An alternative would be the <<refine>> requirement relationship.

the term DataElement is no longer used. should update definition of ResourceExchange.conveyed from:
"ResourceCommunication, the conveyed element must be stereotyped «DataElement» or its specializations,"
to
"ResourceCommunication, the conveyed element must be stereotyped «ResourceInformation» or its specializations,"

The method redefinition changes the type from SysML Behavior to SysML String, which limits the usefulness of the UAF viewpoint stereotype unnecessarily without providing any benefit. The description of the method attribute is, "The methods employed in the development of the Viewpoint." Redefining this to a string precludes defining executable methods that generate a view from the viewpoint, while leaving it as a behavior would not preclude defining the method as a string, since the body attribute of UML OpaqueBehavior is a string.

Allowing the definition of the method as a behavior would also allow explicitly defining the types of inputs from the model needed to produce the view from the viewpoint as the types of input parameters to the behavior.

p213 Viewpoint is defined as 'An architecture viewpoint frames (to formulate or construct in a particular style or language) one or more concerns.'

1) Doesn't conform to ISO 42010 'work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns'
2) This definition doesn't define what an Architecture Viewpoint is - only one of the relationships with Concern. Definitions should be atomic and not include related elements otherwise a change in model structure invalidates the definition. Also, semantically, they have to be standalone.

3) The element should be named 'Architecture Viewpoint' as the definition states. This is important as pointed out earlier to differentiate it from the casual use of 'Viewpoint' and anchor it to ISO 42010.

4)There is a general problem with diagrams where role names are used which have the same name/label as an adjacent element - see Fig 9:215.
The role names provide no additional information and in effect you have unlabelled relationships. In this particular case the relationships should take the names from the 42010 conceptual model. 'language' should be 'architecture description language'. Unclear why 'purpose' is there as distinct from framing one or more concerns i.e is the purpose different from framing the concerns, if so, how?

5) 'View' should be 'Architecture View' to differentiate it from other meanings e.g. as a collection of view definitions.

6) The cardinality between View and Viewpoint is wrong if conforming with 42010 - it should be 1:1 between an Architecture View and its governing Architecture Viewpoint.
7) To conform with ISO 42010 the relationships should take the same names i.e. Viewpoint governs View, Viewpoint frames Concern (and should show Stakeholder has Concern)

8) There is an error in ISO 42010 conceptual model replicated - the requirement for an Architecture Description to contain one or more Architecture Viewpoints - Architecture Viewpoints may be held externally as what used to be termed Library Architecture Viewpoints.

On page 4 the document states 'The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description'. It also states in section 4 Terms and Conditions 'No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation'

Despite these claims the document frequently uses 'viewpoint' with a different meaning from that of ISO 42010 i.e. not as a specification against which an architecture view is prepared and interpreted but:-
1) 'viewpoint' = collection of architecture view definitions having a common subject area (e.g MODAF::Viewpoint)

It does this with no identification of any difference in meaning and nor any definition. It often uses the different senses of 'viewpoint' in the same sentnce and paragraph:

'The aligned and renamed viewpoints from the various frameworks provide a common generic name for each viewpoint. It should be noted that the term viewpoint is in the context of ISO 42010 where a viewpoint is the specification of a view. The UAF viewpoints are mapped to the corresponding viewpoint in the relevant contributing framework. It is the viewpoints described in the DMM that provides the basis for the Unified Architecture Framework (UAF)...'

It looks like the 'viewpoints' and 'UAF viewpoints' are collections of view definitons which is confusingly and erroneously compared with the ISO 42010 definition wjhich is not the same thing at all. It also looks like the last use of 'viewpoints' might be a collection but by this point it's impossible to tell because the authors do not define the terms that they use.

In 7.2 UAF Grid it presents what seems like MODAF::viewpoint, ISO::architecture viewpoint and UAF::view specification in the same place/graphic.

p5 Type 1 Conformance 'Type 1 Conformance: - UAF View specification conformance. A tool demonstrating view specification conformance shall implement a version of all the view specifications defined in the UAF Grid, with the exception of the view specifications in the Metadata Domain. Optionally the tool vendor can implement other donor framework viewpoints, for instance DoDAF, MODAF or NAF ..'

Here 'viewpoint' = collection not a single specification. 'view specification' appears to be indistinguishable from ISO 42010:architecture viewpoint

It is extremely confusing and far from clear and non-ambiguous which are key qualities of any good requirement.

No where in the document is 'view specification' defined despite it being used in 7.2 and as a package name in the metamodel.

In ISO 42010:2011 an 'Architecture Viewpoint' is defined as 'work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns' and in the ISO 42010 conceptual model is has a 'governs' relationship with Architecture View i.e. an Architecture Viewpoint is a specification containing a set of requirements against which an Architecture View is prepared and interpreted. How then is 'View Specification' different? This is particularly the case as 'View Specification' seems not to merit a UAF metamodel element.

'CapabilityConfiguration. A composite structure representing the physical and human resources (and their interactions) in an enterprise, assembled to meet a capability'

'System. An integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements (INCOSE SE Handbook V4, 2015).'

1) As defined CapabilityConfiguration in including interactions and providing a capability is closer to being able to represent a System than the System element itself
2) CapabilityConfiguration is a legacy MODAF element. In the early days of MODAF in the MOD Architectures Lab it was common place to use the CapabilityConfiguration element to represent a system. The MoD never really addressed the problem and left the two distinct elements. There seems to be no good reason to have both or, if there is, what is the differentiation [remembering that the definitition shouldn't refer to any other metamodel element as it must be atomic and self-contained. Being connected to different other metamodel elements doesn't mean that the type is distinct - this can be corrected by changing the metamodel wiring to the CapabilityConfiguration or System element.

'No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation'

This is clearly untrue - there are terms, such as 'View Specification', which if distinct from Architecture Viewpoint needs to be defined to differentiate it.

As an authorative standard that claims to have semantic underpinnings this is wholly unacceptable - what is the master source to be used/referenced in an implementation? There is no traceability. From an engineering perspective any design implementation must be provided with the means to create full traceability to the UAF spec and, where appropriate, the particular source definition.

Definition: 'A type of a human being used to define the characteristics that need to be described for ActualPersons (e.g., properties such as address, telephone number, nationality, etc.).'

1) 'sub-' anything is never a type. The 'sub' simply indicates a position in a hierarchy but the type is the same.

2) An Organization is not a Human Being

3) The definition of a type should be atomic and self-contained - it cannot depend on any other element such as 'ActualPersons'

Organization is defined as 'A group of OrganizationalResources (Persons, Posts, Organizations and Responsibilities) associated for a particular purpose'. This shouldn't include other metamodel elements for the same reason i..e not OrghanizationalResource etc.

Fig 7:3
Definition - 'A Tuple denotes a relationship that exists between elements.'

This is incorrect - it defines a relationship (as it says). A tuple has to also include the start and finish nodes as well to form the smallest tuple - a triple.

Looking at the diagrams it is the legend definition that is incorrect because the green coloured elements are relationships not triples. A clue is in Fig 8:28 on p49 ActualResourceRelationship is identified in green and is clearly just a relationship.

'Further, The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description, where the terms .... form correspondence rules specified as constraints on UAF.'

This is incorrect. Terms / definitions cannot form correpondence rules.

It isn't obvious whether there are any correpondence rules in the UAF given that it is the definition of the individual AF that defines the rules for the content of any particular view - the UAF just provides the "kit of parts" to enable the user to create them. If the UAF does itself define its own correspondence rules this would need to specified separately and somehow deal with potential inconsistencies wrt what does conformance etc then mean.

Definition: 'A type of a current or future state of the enterprise.'

This looks as thought it's a legacy MODAF 1.2.003 definition.

1) A state is an abstract reference to a set of property values or conditions. A phase is a reference to a duration. This would be better defined as a distinct stage in the life? of an Enterprise. The problem is otherwise that there is no connection between the element name and definition.
2) 'current' or 'future' is irrelevant and incomplete - if it occurs in the past is it therefore no longer an EnterprisePhase? The definition shouldn't depend on a particular time value.
3) 'type of' shouldn't be in the definition. All the elements in a metamodel are types so it cannot form part of any differentiating feature.

toBe: Boolean[1] Indicates whether the ArchitecturalDescription represents an Architecture that exists or will exist in the future.

This is incorrect. This is a property of the Architecture not the ArchitectureDescription i.e. an ArchitectureDescription of a future Architecture not a future ArchitectureDescription of an Architecture.

This is another consequence of not differentiating properly between 'architecture' and 'architecture description'.

Definition
'Interest in an EnterprisePhase (EnterprisePhase is synonym for System in ISO 42010) relevant to one or more of its stakeholders'

1) This doesn't conform to the ISO 42010 definition of a Concern and hence invalidates claim to be compliant
2) An EnterprisePhase is not a synonym for System, and certainly not in ISO 42010

In Fig 9:211

1) the 'concern' role name placed against Concern on the Viewpoint - Concern relationship is meaningless - using the same label as the name of the adjacent node element is in effect leaving the relationship with no name whatsoever - it proviode no information about that relationship. In ISO 42010 this relationship is named 'frames' - this should be . The cardinality is incorrect - it should be 1..*.

2) the relationship between Stakeholder and Concern should be named 'has'. The cardinality is incorrect - it should be 1..*

3) There should be no relationship between ActualEnterprisePhase and Concern

'A type used to denote a model of the Architecture, described from the ResourcePerformer perspective.'

A model is not an architecture - it might, however, describe an architecture description. The definition is therefore that for a type of architecture description not architecture. The definition is wrong and needs to be changed - suggestion is to base on the ISO 42010 conceptual model - 'architecture'.

It is also an error to include in any definition any relationship - definitions of elements should be atomic / self-congtained and not depend on any other element or relationship otherwisse a) you're not defining the element - it might be a triple b) if the structure/ relationships change then the element definition no longer holds.

'The UAFP can be used to develop architectures compliant with:
• Department of Defense Architecture Framework (DoDAF) version 2.02'

This is incorrect. Architecture Descriptions might be compliant with an AF such as the DoDAF but architectures them selves are certainly not. This is a general problem - the lack of differentiation between 'architecture' (the thing being described) and 'architecture description' (the description). It probably isn't helped by loose casual everyday talk but in a document with defined semantics it is an error - it's the equivalent of confusing the 'duck' with the 'photo of the duck'.

It also looks as though this has affected some of the metamodel element definitions e.g. ResourceArchitecture

(typo) Page 72, View Specifications::Resources::Roadmap::Resources Roadmap: Evolution has a Stakeholder named "Implements" and I think you mean "Implementers" as is used in other areas.
(typo) Page 83, View Specifications::Projects::Taxonomy::Project Taxonomy doesn't put the Stakeholders, Concerns, Definition, and Recommended Implementation on separate lines like every other View Specification does.

Page 31, View Specifications::Operational::Connectivity::Operational Connectivity and Page 37, View Specifications::Operational::Constraints::Operational Constraints both have a Stakeholder named "Architects" whereas all other View Specifications specify one or several types of Architects. Are all other named types of Architects assumed?

In general, what are your definitions/assumptions for Business Architects versus Enterprise Architects versus IT Architects, all of which are used as Stakeholders in various View Specifications?
What are your definitions/assumptions for Solution Providers versus Implementers, both of which are used as Stakeholders?
What are your definitions/assumptions for Decision Makers versus Executives versus Owners Responsible for Operational Agents, all of which are used as Stakeholders in various View Specifications?

Page 37, View Specifications::Operational::Constraints::Operational Constraints contains a Stakeholder called Program Sponsor. What is your definition for "Program" or that overall Stakeholder?

UAF::ProtocolImplementation is really a subset of all UAFElement.conformsTo Standards. Aka if a UAF::ProtocolImplementation implements a UAF::Protocol it should also count as conformingTo it. Recommend making the implements tag a subsetted property of the conformsTo tag. Also, to allow Standards to actually enforce parametric constraints or execute behavioral simulations as part of UAF models, recommend creating a <<ConformsTo>> property stereotype that has <<Standard>> as a target and <<UAFElement>> as a Source (or maybe just limit to PropertySet), and/or add a derived Tag to UAFElement that derives a subset of conformsTo relationships from classifier.properties that have <<Standard>> or stereotypes derived from <<Standard>> as their type.

LocationHolder.physicalLocation and requiredEnvironment tags could be derived from Asset.properties when those Asset.properties have defaultValue UML::InstanceSpecifications with the ActualLocation and ActualEnvironment stereotype applied, respectively.
This would save UAF modelers time in populating the tags when they also want to leverage SysML parametrics and fUML behavioral simulation capabilities that rely on UML::Class.properties. There are no simulation semantics developed for LocationHolder.physicalLocation ot requiredEnvironment so duplication of effort would be required to both execute simulation and comply with current UAF semantics.

Since all UAF::Stereotypes that extend UML::Property metaclass are all UAF::MeasurableElement, that means that the UML::Property.defaultValue is an InstanceSpecification that has an ActualPropertySet with a PropertySet as its classifier. If that defaultValue has a ValueSpecification with ActualMeasurementSet applied, then one of the actualMeasurementSet tagged values could be derived from this defaultValue.

This would save time for modelers that use defaultValues for executing SysML parametrics and fUML, as they would not need to also fill in the tag manually. Clearly these defaultValues should be included in the tagged values as intent is the same or subset of.

IsCapableToPerform (ICOP) connects client UML::Classes to supplier UML::Activities. This is the same purpose as UML::Operation, through featuringClassifier and method. While UAF::OperationalMethod, ServiceMethod and ResourceMethod exist, their link to IsCapableToPerform is apparent but absent. Recommend adding ICOP as an extention of not just Abstraction, but also Operation with additional caveats that it can only be applied as a stereotype when the Method is not Empty. An alternate strategy is to add a Tag to ICOP that points to the UAF::*Method that implements it, kind of like the SysML::AdjunctProperty.. Or the reverse, create a tag on UAF::*Method that points to it’s ICOP.

Each UAF::*Constraint specialization of UAF::Rule has a constrainedElement metaconstraint on SubjectOf*Constraint, none of which include SysML::ConstraintBlock as a specialization. This complicates the use of SysML Parametric analysis using UAF stereotyped UML::Constraints, since ConstraintBlocks can not own them. UAF SubjectOf*Constraint elements that are specializations of UML::Class should be allowed to own ConstraintProperties typed by ConstraintBlocks that have UAF::*Constraints. Need to also allow alternate metaconstraint so that UAF::*Constraint can be owned by ConstraintBlocks that are used as ConstraintProperties by the associated UAF::SubjectOf*Constraint

Suggestion is to add ConstraintBlock as an alternate metaconstraint target for UAF::*Constraints AND a 3rd alternate metaconstraint that allows existing UAF::SubjectOf*Constraint to own ConstraintBlocks that have no or properly stereotyped owned constraints.

The Implements DMM relationship is primarily used in Traceability views between Viewpoints. While currently encoded in the UAF ML as the Implements element specializing the Allocate relationship, this is not the only way to encode that concept and be consistent with the DMM. According to SysML v1.6 15.1 Allocations Overview "Allocations can be used early in the design as a precursor to more detailed rigorous specifications and implementations."
Given the current set of UAFElements that can participate in Implements relationships I recommend 2 additional ways that the DMM Implements concept can and is given more rigorous specification and implementation in SysML models. These are the UML::Generalization and UML::RedefinableElement concepts.

7 of 11 Implements clients can participate in Generalization relationships, 2 clients can participate in RedefinedElement relationships. Methods should be explored to leverage these as alternate methods of encoding the DMM Implements relationship.

I can't think of a super clean method of doing this, a few come to mind. First is to use a Taxonomy of Implements stereotypes that separately extend Abstraction and Generalization, but that can't solve RedefinableElement since it's a metaproperty that is not reified into a UML::Relationship. So, an alternate method is to make all 11 Implements clients specializations of a common more general stereotype that has a tag that is derived from all 3 UML methods of encoding Implements. The use of tagged values in this way will change the UAF ML::View Specifications where UAFMP::Implements in currently the only method shown. Lastly thought of, force tool vendors to automatically create a UAFMP::Implements when one of the 9 clients participates in a Generalization or RedefinedElement relationship that matches the DMM Implements constraints. The UAF ML can force this by adding constraints on use of Generalization or Redefinition on the 9 and 2 client elements respectively.

Currently there is no constraint that the Classifier of any of the ActualMeasurementSets used in a UAF:MeasureableElement actualMeasurementSet tag be related to the MeasurementSets used in the measurementSet tag. Recommend that the Classifier of any ActualMeasurementSets used as tagged values of a UAF:MeasureableElement actualMeasurementSet tag be used to derive a subset of the measurementSet tagged values.

By constraining UAF ControlFlows to just the associated viewpoint Actions as sources and targets we are preventing users from using the full range of UML::ActivityNodes that they could use in Process Views. Significally, ControlNodes, such as the Initial,Fork,Join,Merge,Final Nodes are all excluded but of major importance to good description and visualization.
Recommendation:
1) Either elevate UAF::*ActivityAction up to UML::ActivityNode and specifically add UML::InterruptingActivityRegion.interruptingEdge
2)or remove .source and .target constraints on UAF::ControlFlows

SysML has very tight constraints on ProxyPorts and InterfaceBlocks that are bypassed by using FullPorts. Specifically the no_behavior and no_part constraints on InterfaceBlocks. By constricting UAF::*Ports to ProxyPorts, it prevents UAF architects from taking full advantage of behaviors and parts on UAF::*Ports. Just like SysML, an alternate method for having ports with parts and/or behaviors should be allowed.
I don't see any perfect specific recommendation, there will probably have to be a change that tool vendors will have to create a mapping for.
Alternate 1: Make UAF::*Port an Abstract Stereotype, removing the Generalization to ProxyPort. Then create 2 new specializations of ResourcePort, one for "ResourcePortProxy" and another "ResourcePortFull" each specializing SysML::ProxyPort or SysML::FullPort respectively.

Alternate 2: Remove/Obsolete the stereotype altogether or remove it's dependence on Proxy or Full and require double stereotype like UPDM l1 compliance. Instead place constraints on *Performer.ownedPort metaproperty based on if it's port is either Proxy (using *Interface type) or Full (using *Performer type).

Alternate 3: Just switch generalization of UAF::*Ports from SysML::ProxyPort to SysML::FullPort. There are no constraint violations as FullPorts can be typed by InterfaceBlocks, so no changes needed for users or UAF::*Interface. Requires update to UAF::*Port.type constraints to allow addition of <<OperationalAgent>>, <<Service>>, or <<ResourcePerformer>> as valid types.

While UAFML is "intended to be relatively easy to implement for vendors who support UML 2.x and SysML 1.x", it is not as easy for organizations with existing UML 2.x and SysML 1.x models. Organizations are currently faced with adding UAF::Stereotypes to existing UML/SysML models (sometimes not possible for Configuration Management reasons), "copying" UML/SysML elements and adding UAF stereotypes, or not adopting UAF.
I recommend providing a normative default mapping of some UML/SysML model elements without UAF:Stereotypes applied and/or a standard way of "copying" these elements.

Specifically UML and SysML elements, by default, should be allowed to be used in place of Resources Stereotypes. This would mean some Constraints would need to be relaxed on Connectivity, Process, Constraint and other Dependency or metarelationship where the source or target or other role must be a Resource Stereotype.

In addition or alternately, allow the SameAs relationship to explicitly allow the target end to not have to be a UAFElement.

Also, allow SameAs to extend UML::Generalization as well as Dependency. While technically this makes the UAF source of the relationship a specialization, not exactly SameAs, it achieves the intent especially if the UAF element is not further constrained. It also then supports redefinition, subsetting and all other inherited properties that UML::classifiers get from being the source, specific metaproperty/role, of the generalization relationship.

UML has a rich diversity of Actions that are not usable within UAF because the View Specifications for Processes and Connectivity only mention UAF::*Action in the view Specification. First recommendation is that all UML::Actions are explicitly mentioned as allowed in these View Specifications.

Second recommendation is to specifically support the use of UML::CallOperationAction.operation:>UML::Operation.method be used as an alternate to UML::CallBehaviorAction.behavior. This will allow UAF::OperationalMethod, ServiceMethod, ResourceMethod to be used in these View Specifications. Specifically, recommend elevating the UAF::*Action stereotypes from extending UML::CallBehaviorAction to either:
1. Also extend CallOperationAction
2. Or extend CallAction (also supports StartObjectBehaviorAction (aka classifierBehaviors))
3, Or extend InvocationAction (also supports Send/BroadcastSignal as well as SendObjectAction).
4. Or extend UML::ActivityNode or UML::Action (everything)

Also, of minor concern, the constraints that an OperationalExchange must occur over an realizingActivityEdge stereotyped by OperationalActivityEdge that, at least for OperationalControlFlow, have constraints where the source and target must be OperationalActivityAction.

I learned that the OMG has deprecated UML 1.x XMI 1.x well over 10 years ago when it was replaced by UML 2.x XMI 2.x.

Also learned that the OMG UAF.xmi file is in UML XMI version 1.x. Probably generated from a tool like Sparx Enterprise. Because UML 1.x is an outdated version it is not possible to import the current UAF.xmi file posted on your site for analysis, causing import errors.

This requires providing the UAF.xmi files using the current UML 2.x XMI 2.x version.

Please provide/replace the UAF.xmi files posted on your site with UML 2.x XMI 2.x version to import the specification in to a modeling tool for analysis.

We keep getting error while importing. It tries to load the file and fails when trying to read the first character, with a "invalid byte" message. Not sure if this has been reported before. If so would it be possible to share updated UAF.xmi? If not, would it be possible to share the name of the tool it was created with?

In the traceability appendix, the undefined "Services Sequences" view is referenced in the DoDAF and MODAF tables, mapping to the SvcV-10c and SOV-4c, respectively. I assume this should be "Services Interaction Scenarios".

The view traceability tables in the body of Appendix A are not numbered in a logical order. They're shown as Table 2:1,1:2, 2:2, 2:3, 2:5. The numbers in the List of Tables (p. v) appear to be correct.

In the UAF DMM document (https://www.omg.org/spec/UAF/1.1/DMM/PDF), starting right after "7.2 Domain Interrelationships", there seems to be an error causing the Table of Contents (TOC) to incorrectly "Domain Metamodel Diagram Legend" as Chapter 8 insead of section 7.3. This offset continued through TOC the document such that Chapters 8 and 9 are mislabeled.

SysML allows the use of CallOperationAction as an alternate means of mapping Behaviors (via Operation->Method metaproperty).
UAF 1.1 includes OperationalActivityAction, ProjectActivityAction, ServiceFunctionAction, FunctionAction or SecurityProcessAction which all extend CallBehaviorAction.
UAF 1.1 also includes OperationalMethod, ServiceMethod, ResourceMethod, which extend Operation, and even has metaconstraints requiring appropriately UAF stereotyped Activity used as the Method.

We recommend allowing CallOperationAction to also be stereotyped by the UAF extensions to CallBehaviorAction listed above.
We also recommend creating ProjectMethod and SecurityMethod as extentions to Operation to be consistent with other Domains.
This would facilitate it's use in Operational::Connectivity, Operational::Processes and Security Processes, Project Processes, Personnel Processes, Resource Processes and Resources Connectivity Diagrams and Tables.
This is especially useful to visualize and take advantage of CallOperationAction target pin and method resolution per UML 2.5 13.2.3.5 Behavioral Features and Methods. It is also useful for fUML 1.2.1 Polymorphic Operation Dispatching ability to execute method resolution during simulation and analysis. Thus a tighter integration of UAF with UML method resolution semantics and executability can be achieved both visually and from a simulation and analysis perspective.

Actual Resource Relationship is described as: An abstract element that details the ActualOrganizationalResources that are able to carry out an ActualResponsibility.

This appears to be incorrect. First, this element is not abstract. Second, it should not be restricted to Organizational Resources since it should apply to any Actual Resource. Third, it does not help understand responsibilities of organizational resources.

Description of this element should be changed to read something like: An element that details the ActualResources that are involved in exchanging resources through a realized ResourceExchange.

The elements in the Actual Resources views are instances of the "definitional" elements in other domains. For example, Actual Resource (classified by Resource Performer element types in Resources domain); Actual Post, Actual Person, Actual Organization (<all classified by elements from Personnel domain); Actual Resource for a Resource Mitigation (from Security domain). The new Resource Service element will be classified by a Service in the Services domain.

Notice that not all the elements shown in Actual Resources views come from the Resources domain views (ie, they also come from Personnel, Security, and Service domains). So, the name "Actual Resources" is somewhat misleading in this respect. Therefore, it would better if this domain is renamed to more accurately reflect its intended content. Suggest the name be changed to "Actualization" (Az) domain.

Portfolio management involves changes to the future plans and current deployments.When to add new capabilities? When and where to change operations or change resources?. When to retire legacy resources, or re-purpose them?

Overall “score” for alternative portfolio configuration is extent to which Outcomes are achieved for the enterprise as a whole. Possibilities for change come from identified Opportunities and their associated Risks. Also these come from identified new/modified Capabilities and their associated Effects.

Portfolio is normally divided into Portfolio Segments
-Could be divided by timeframe (eg, “epochs” such as near, mid, far term)
-Could be divided by “color of money” (eg, R&D, acquisition, operations)
-Could be divided by mission area

Currently using Whole Life Configuration as the Portfolio elements in EA model. WLC is a “set of Versioned Elements”. But would be more convenient to have a different model element for “Portfolio”.
-Alternative Portfolios would be examined for most cost-effective combinations
-Each Portfolio option is a provisional “set of Versioned Elements”
-Then the selected combination gets promoted to a new Whole Life Configuration (becoming the new “baseline” for program planning and scheduling)

Portfolio (kind of) Project does not have the necessary semantics with the features and relationships enumerated below.

WLC element only gives part of the picture of what is in the Portfolio.
-Acts as a “collection” of things with an associated Gantt chart for deployment timelines
-Does not tell us who “owns” that collection of things in the Management Accountability sense
-A Portfolio can consist of multiple Whole Life Configurations

Portfolio needs to have the following features:
-Things it is delivering (eg, in its Whole Life Configurations)
-Who runs it (ie, the Actual Organization)
-Particular programs within it (eg, actual Projects or project elements)
-Alignment with budget elements, assigned Opportunities and Risks, etc
-Assigned responsibility for execution of particular Enduring Tasks (and associated Capabilities)
-Accountability towards achieving Effects (eg, MOE target levels) for a given time period
-Can be assigned responsibility for certain Missions, Enterprise Goals and Enterprise Phases
-Can be jointly managed with another Enterprise for shared Operations and Resources

Might be that Portfolio could be a kind of Whole Life Enterprise (ie subtype) that has the features and relationships noted above

Identify and update the DMM to reflect new concepts and relationships to existing concepts. Additionally, identify all impact to existing diagrams.

ISODateTime is currently mapped to literal string. In my opinion it does not make sense. This mapping does not allow to reuse dates in the easy way. Plus we also have the same approach with milestones implemented very differently. I do believe that both approaches need to be aligned. Dates should be easily reusable all over model.

Current drescription is "An abstraction relationship relating an ActualOrganization to an ActualEnterprisePhase to denote that the ActualOrganization plays a role or is a stakeholder in an ActualEnterprisePhase."

However, since a stakeholder can also be an OrganizationalResource (see definition in Figure 7.208) maybe the OrganizationInEnterprise could also relate an OrganizationalResource to an ActualEnterprisePhase? Otherwise, only a subset of the stakeholders can be related to an ActualEnterprisePhase.

Flow properties needs to be stereotyped in the profile to better integrate interfaces to exchanges and signals. Stereotypes are needed for Operational, Service, and Resource Interfaces

The Standard Operational Activity definition is not clear ("standard operating procedure" is fairly ambiguous). Would be important to clarify where it should be used instead of an Operational Activity. It is also listed as a Doctrine of the Capability Configuration, which should be checked against the doctrine elements being added to UAF 1.3 to support mission engineering.

all the *ActivityAction's extend CallBehaviorAction... but there are other Actions one might want to have in the Activity ... e.g. we have people that just want an OpaqueAction...
so would like OperationalActivityAction, ProjectActivityAction, FunctionAction, SecurityProcessAction, ServiceFunctionAction should all extend Action (not CallBehaviorAction)

Decisions within a process often conform to standards and require measurements to determine the quality of the decision. However, because the DecisionNode element is inherited without modification from SysML/UML, the <<ConformsTo>> relationship and <<MeasurableElement>> are not available on decision nodes. Adding a UAF DecisionNode as a MeasurableElement would improve traceability in the model.

So UAF should remind people using Exchanges that in SysML the standard says...

"A Connector or an Association, or an inherited Association shall exist between the source and the target of the InformationFlow"

not that I like this or think it is correct... but for an ItemFlow this is the restriction given in the standard...

exchanges across ActivityEdges and Messages need to have this...

notice on fig 3.107 ServiceParameter relates to ServiceExchangeItem

but on serviceEchangeItem fig 3.112 it is missing the ServiceParameter

should Service relate to ServiceExchangeItem
similar to how OperationalActivity
relates to OperationalExchangeItem?

p74 8.1.7 View Specifications::Resources::Structure

1) identifier - Rs-Sr, missing'

Definition: defines the physical resources, e.g. capability configuration(s)/system(s) and interactions necessary to implement a specific set of OperationalPerformer(s).'

2) CapabilityConfiguration and System are not physical resources (as Figure 8:56 shows)

3) ResourceArchitecture specialised elements - System, SecurityEnclave allowed but missing from Fig 8:56. All elements of a taxonomy tree should be shown. If not then the parent should not be shown and particular individual child elements shown.

'Concerns: reference the resource structure, connectors and interfaces in a specific context.'
4) Meaningless - what does 'reference the ...' mean? 'In a specific context'? Back inAbitraryConnector territroy. How can you possibly determine that these elements represent the allowed view content when there is no clear set of concerns which triples formed from the elements should address?

5) Is nothing carried by a ResourceExchange? If so elements are needed on Fig 8:56 to describe this.

6) Protocol is not involved in any triple. There appears to be a triple involving ProtocolImplementation but not Protocol. If there is a triple involving Protocol expected then additional elements are required. If there is no triple involving Protocol delete it.

7) Similarly there is no triple involving Measurement - again define one including a relationship element or remove.

8) The 'ResourcePerformer IsCapableToPerform Function' triple has no connection to the structural and interface concerns. It makes no sense to try and describe functional, interfaces and structure on the one architecture view. Function should be the subject of e behaviour-oriented 'view specification' e.g. Resources Process - Rs-Pr. The IsCapableToPerform and Function elements should be remoed from Fig 8:56

since PropertySet types things... one can be tighter about what it extends... it should extend Classifier rather than Element

p72 8.1.7 View Specifications::Resources::Structure Rs-Sr Fig 8:56

'Concerns: reference the resource structure, connectors and interfaces in a specific context.'

1) Fig 8:56 requires 1 or more Measurement for each ResourcePerformer i.e. have to show Measurement(s)?
2) No triples provided to describe applicable measurements
3) No concerns require Meaurements to be shown - so the elements shown are surplus to requirements for the architecture view
4) The semantics of Asset is a PropertySet are incorrect. An Asset property or characteristic might be quantified by one or more Measurements. This does not mean, however, that a set of measurements is an asset - it's a meaningless and incorrect assertion. How can the UAF claim any semantic rigour?

Even thought the UML Standard does not explicitly state this, extends are inherited by specializations of Stereotypes...

1. The UML standard show examples of specializations of stereotypes that do not extend metaclasses indicating that extends are inherited see Fig. 12.21
2. ExtendEnds are forms of Association Ends which are inherited normally (and there is nothing to the contrary in the standard that they are treated any differently)
3. SysML also uses this... e.g. see Fig. 8.8 of SysML 1.7 where BoundReference does not show an extends (but gets it from EndPathMultiplicity)...

so given UAF... I think most everything that extends Element is wrong... because for example, you do not want to be able to put the stereotype
<<OperationalActivity>> on anything but a UML/SysML Activity... but Activity is MeasureableElement which is a UAFElement which extends Element, so therefore <<OperationalActivity>> can be put technically on anything (e.g. a Comment)... so this is wrong and needs to be fixed

For Protocol it extends Class which is redundant and probably unhelpful...

since Protocol is a specialization of Block (which extends Class) this is not helpful, because one needs to know that this stereotype
would be used instead of <<Block>> (since one can not have both a generalization and specialization of a stereotype on the same element)...

Block here is the more fundamental than the metaclass Class... but neither should be specified redundantly in the model...
it is just not helpful... what would be helpful is defining the fundamental thing in the definition of the UAF elements

p245 9.1.12 Domain Metamodel::Parameters - PropertySet & Fig 9:363

PropertySet is defined as 'An abstract type grouping architectural elements that can own Measurements.'

1) Incorrect. The definition is not atomic - refers to 'owns' which implies a relationship that isn't present with PropertySet in the metamodel. 'Architectural Element' is actually an AD element (cf ArchitecturalReference). Things don't own measurements - they have characteristics that are quantified by measurements. The definition should only define the concept not the use or application of the element - this would then highlight the problem wrt what the concept actually represents. It appears to be an implementation artefact that has nothing to do with the fundamental metamodel concepts.

2) Figure 9:363 shows that many metamodel elements specialise PropertySet, most of which are semantically incorrect. We have, for example, 'System is a PropertySet', 'Viewpoint is a PropertySet', 'StrategicPhase is a PropertySet', 'OperationalInterface is a PropertySet'. The full class hierarchy needs to be shown including all types of Asset, Resource and MotiovationalElement otherwise the sense (or error) of what is being asserted cannot be verified. The only assertion that is probably correct is 'MeasurementSet is a PropertySet'

3) There is a reflexive PropertySetGeneralization on PropertySet - presumably to assert a specialisation of successive PropertySets. However, because it is on PropertySet - the parent - and because the child elements inherit this relationship with any PropertySet element it therefore asserts that 'System PropertySetGeneralization Viewpoint', 'EnterpriseGoal PropertySetGeneralization Service' i.e. the child PropertySet elements can be connected together using PropertySetGeneralization which is semantically meaningless.

4) There are several elements - possibly many - where a triple including PropertySetGeneralization can never appear in any architecture view (doesn't appear in the definition of allowed content of any 'view specification'). For example the View, Viewpoint elements. You might expect these particular triples to appear in the Summary & Overview 'view specification' if valid - but there is nothing shown in 8.1.2 and doesn't address the concerns. If triples do not address concerns and do not appear in any 'view specification' they should be deleted from the metamodel - they serve no defined purpose.

5) There is no defined relationship between Measurement and PropertySet that can be used in any 'view specification' - this would require a relationship element to be shown and there is only the reflexive PropertySetGeneralization

CompetenceToConduct in the metamodel is in traceability
and in the profile is in Process

should they not be in the same place?

CompetenceToConduct in the metamodel is in traceability
and in the profile is in Process

should they not be in the same place?

used "Function" in some places and "Activity" in others... e.g. OperationActivity and Function in Resources

Domain MetaModel::Architecture Management::Sequences::InteractionMessage has no metamodel

No Description for CapabilityRoleDependency

no metamodel for StrategicExchangeItem

Missing metamodel for StrategicInformation

What is called a Method in UAF is really an Operation... this is confusing as the semantics for Method and Operations are set in
SysML via UML

Sm is not defined in Table 7.1

Fig 7.1 in the DMM and the UAF Grid in Appendix C are different...

for example... one has Am-St and the other one does not... there are other differences

Ar-Tr is missing on both Graphics of the UAF Grid

p71 8.1.7 View Specification - Rs-Tx Resources Taxonomy, Fig 8:55

states
'Concerns: resource types.
Definition: shows the taxonomy of types of resources.'

1) Architecture viewpoint has no identifier (a package containment isn't a unique identifier) - should be Rs-Tx according to the Traceability document.

2) Figure 8:55 shows ResourceExchange - this is a connector. It isn't used in the architecture viewpoint - a taxonomy uses 'is a' (specialises / generalises). This shouldn't be in the diagram

3) The Measurement element isn't a Resource and also isn't involved with taxonomy - it doesn't address the concerns of the architecture viewpoint and should be removed.

4) The realisation of an OperationalPerformer by a ResourcePerformer doesn't involve taxonomy and doesn't address any of the concerns. This should be removed.

p158 9.1.4 Domain Metamodel::Operational - Operational Architecture, Figure 9:187

OperationalArchitecture is defined as:
'A type used to denote a model of the Architecture, described from the Operational perspective.'

1) We incorrectly have a model of the architecture being a type of architecture (OperationalArchitecture specialises Architecture).

2) The description of the 'operational architecture' is the set of operational node elements and relationships (forming triples), perhaps augmented by some standards - it is incorrect then to have a concrete single element representing the same thing.

It isn't really any different as a type from Architecture - it seems to be purely a mechanism to show relationships with different operational elements. It isn't a distinct concept in what is supposed to be an abstract metamodel.

So what then is the relationship between 'OperationalArchitecture' and the description of an operational architecture (if the element really is 'architecture' and not 'architecture description'? It ought to conform to ISO 42010 ie something like 'expresses' or in the reverse sense 'is described by'

p99 8.1.10 View Specifications::Standards::Traceability

The concern for the 'UAF::view specification' is:-
'Concerns: standards that need to be taken in account to ensure the interoperability of the implementation of architectural elements.'

1) Why is a view needed to describe the standards affecting the interoperability of an architecture description?
2) 'implementation of architectural elements' is meaningless - do mean the standards that affect the system of interest? Standards don't just affect implementation

'Definition: shows the applicability of standards to specific elements in the architecture'

3) Difficult to make sense of given the endemic conflation of 'architecture' to mean both 'architecture' and 'architecture description'. Standards apply to the system of interest. 'elements' is too much like 'architecture description element' used to form an AD.

Figure 8:82 Standards Traceability

This shows Standard, Protocol elements and the generic UAFElement.

4) There are no relationship elements provided to establish what looks like a 'conforms to' relationship between a UAFElement and a Standard or Protocol

5) Either the diagram doesn't provide the elements to address the concerns or the concerns are incorrect. The diagram describes conformance not a trace ('standards that need to be taken in account'). Which is it? The concerns and the triples shown in the diagram need to be consistent with each other.

p40, 41 - 8.1.4 View Specifications::Operational::Processes - View Specification Op-Pr Operational Processes BPMN Semantics

The DMM is supposed to be an agnostic specification. This clearly shows the bottom-up derivation of the DMM by chopping bits out of the UML profile.

1) The title is invalid - no architecture viewpoint should be named after a particular ADL implementation - the name ought to be 'Operational Processes' if that reflects the purpose/ concern not the means of realising this.

'Concerns: captures activity-based behavior and flows using BPMN notation.'
2) This is invalid - the ADL or method is never part of a valid concern. The stakeholders presumably only care about the processes not how they are represented.

'Definition: describes the BPMN processes that are normally conducted in the course of achieving business goals that support a capability. It describes operational activities, their Inputs/Outputs, operational activity actions and flows between them using BPMN notation.'

3) This is invalid. It should describe processes. It shouldn't contain any reference to any particular ADL, UML or SysML element names et al

Recommended Implementation: BPMN Process Diagram.

4) It shouldn't make reference to any technology or ADL. In any case why can't processes be described using a UML ACtivity Diagram? What's so special that this has to be BPMN?

5) Figure 8:27 shows many BPMN elements. Delete them - they have no valid place in the DMM

p38 8.1.4 View Specifications:Operational - Operational Connectivity, Figure 8:25, p165 9.1.4 Domain Metamodel::Operational - OperationalActivityEdge Figure 9:202

The OperationalActivityEdge element is defined as :-

'A tuple that shows the flow of Resources (objects/information) between OperationalActivityActions'

Figure 8:25 shows that this element realises the OperationalExchange element (indicated by the realizedByActivityEdge role name on OperationalActivityEdge and the realizes role name on OperationalExchange).

An ActivityEdge is a particular UML method to provider a connector to join two Activity node elements on a UML Activity Diagram. This is a particular UML implementation. It should be in the UML profile for the UAF but not in an agnostic metamodel or architecture viewpoints in the DMM. How someone chooses to implement an OperationalExchange is up to them - it isn't the subject of the DMM.

in UAFML Operational::Structure concern is
identifies the operational exchange requirements between OperationalPerformers

where as in UAF DMM Operational::Structure concern is:
identifies the operational exchange requirements between nodes

so need to replace nodes with OperationalPerformers

EA guide p 136 - Appendix B - Glossary - Viewpoint

This states that the ISO 42010 term 'Viewpoint is '“conventions for the creation, interpretation and use of an architecture view to frame one or more concerns” [ISO 42010] that governs the creation of views'

It then states that the UAF term 'viewpoint' is 'frames (to formulate or construct in a particular style or language) one or more Concerns. A Concern can be framed by more than one Viewpoint.'

1) the ISO 42010 term is 'Architecture Viewpoint' not 'Viewpoint' - this distinguises it from incorrect casual uses of 'viewpoint'.
2) If anyone sees 'Viewpoint' how will they know whether it's the ISO 42010 'viewpoint', the first meaning of UAF 'viewpoint' defined above or indeed the MODAF viewpoint which is used within the documents bit not defined anywhere?
3) If you modify the ISO 42010:2022 definition by appending anything it isn't then the ISO 42010 definition and shouldn't be labelled as such because it misleads. If you need to add notes use a footnote so that there is clear physical separation of what is a local annotation. Adding a description of relationships etc shouldn't be part of the definition of any concept - it should be atomic - it is an element in the 42010 conceptual model and describing the conceptual model shouldn't be in the table itself. Or create an additional 'Comments' column and move the non standard text there.
4) Until all references to (MODAF) viewpoint are removed the UAF cannot claim and a 'viewpoint' = ISO 42010:: architecture viewpoint because in many places in the text it isn't

Simnilarly for 'View' above - there is not such thing in ISO 42010 as 'View' - the correct term is 'Architecture View' because there are many casual and incorrect meanings of 'View' (as the UAF element is named)

This is a self-inflicted error - if the UAF stuck to the name and definition defined by ISO 42010 it wouldn't arise - there wouldn't be 2 (actually) 3 uses of 'viewpoint' with different meanings. That's the point of standardisation - only 1 term, 'architecture viewpoint', used throughout with the one consistent meaning.

EA Guide p17 - 3.1 Architecture Management Concepts (more correctly, 'Architecture Description Management Concepts' as the subject is 'Architecture Description' not 'Architecture'

States:
'illustrated in the conceptual schema shown in Figure 3:1. These key concepts are highlighted in italics within the Narrative and some of the less obvious concepts are listed with the associated ISO-42010 2 meaning or the UAF meaning of that concept'

The DMM 1.3 states - 'Further, The UAF conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description'

1) If any definitions differ in the UAF vs ISO/IEC/IEEE 42010 then the UAF does not conform to the standard and any such claims need to be removed.
2) Any references should be at the beginning of the document as other UAF documents not spread throughout the document on footnotes

p117 of A.4.1 Standards and Practices in the EA guide:-

states - 'ISO/IEC/IEEE 42010:2021 – Software, systems and enterprise – Architecture description: provides core terms, definitions and relationships for architecture descriptions'

1) The correct version is ISO/IEC/IEEE 42010:2022 - see https://www.iso.org/standard/74393.html
2) The DMM refers to the 2011 version under Normative references. Not incorrect but likely inconsistent with any claims of conformance by the UAF

2.2 Core Principles - Compliance Levels p 5 states:

'Compliance levels: UAFML has a single compliance level based upon a combination of the reuse of UML and SysML elements. It is expected that the views that are created as result of this profile have frames that reflect the underlying SysML diagram type that is used as the basis for the view. It is also expected that the graphical notation used to display elements within those views correspond to the standard SysML graphical notation of the SysML/UML metaclass that the stereotype extends.'

1) What does 'the UAFML has a single compliance level' actually mean?

2) This makes no sense. The UAFML must conform to the DMM - the DMM defines the concepts, their meaning etc with which the UML + SysML implementation in this profile is required to conform. The DMM essentially defines the set of input requirements which any implementation, including the OMG's own UML + SysML profile, must meet

3) Where is the traceability mapping to the DMM? This is missing and is required as part of the evidence of conformance to the DMM.

4) This conformance is local to this UML profile. Given that there is a normative profile file what does conformance mean? The OMG define both so either the UML profile that the OMG also produces either conforms or it doesn't . If the OMG are stating that in order to conform some extra requirements have to be met which are not defined by the UML profile these requirements must be identified to enable a fully-traceable conformance assessment i.e. to UML profile + to other atomic requirements. At the moment this is incomplete - where is the evidence that the OMG with their UML profile for the UAF + 'something else' conform to the DMM?

5) There is no reference to and this might be inconsistent with the conformance types stated in the UAF DMM section 2 (Type 1 to Type 3). The UAF DMM defines conformance levels for an implementation which have nothing to do with this local conformance and vice versa.

9.1.1 Domain Metamodel::Architecture Management - Architectural Reference. p128 , Fig 9:125

ArchitecturalReference defined as 'A tuple that specifies that one architectural description refers to another.'

1) The name of the element should be 'ArchitectureDescriptionReference' as it isn't 'architecture' that's being referred to - it's an ArchitectureDescription element
2) ArchitecturalReference isn't a tuple. The shortest possible tuple, a triple, is either node - relationship - node or node - relationship - (same) node if reflexicve. ArchitecturalReference is a relationship.
3) The definition of a metamodel element must define the concept itself. This must be atomic. The 'one architectural description refers to another' defines how it may be connected - it doesn't define what 'ArchitecturalReference' is. If the element were defined you'd probably correctly decided that it isn't a concept for a metamodel because there is no atomic definition other than 'undefined' because it's semantically equivalent to the other "universal stuff" releationship, ArbitraryConnector. This sort of error would be much easier to trap if there was rigour in the definition of individual metamodel elements.
4) A 'tuple' does not specify anything. This connector element is purely a description or assertion that there is some unknown relationship between 2 ArchitecturalDescription elements
5) If a reference is required why isn't a trace relationship used? Then we'd have one less arbitrary metamodel element.

View Specifications::Architecture Management::Motivation

Am-Mv Architecture Principles 'View Specification' p19, Figure 8:1

States: 'Concerns: alignment of architecture with architecture heuristics, guidelines, and principles.
Definition: identifies relevant architectural principles and other guidelines to be used in architecture development and evaluation.'

1) What does 'alignment of..' 'with' mean? Do you mean identification of the reference sources? Do you mean identification of input requirements? Do you mean conformance with requirements (process, technical etc)? The current is unspecific and will therefore yield inconsistent results. Should be 'alignment of architecture description' ('architecture description' not 'architecture')

2) Fig 8:1 only provides a 'Driver' element and possibly typed by DriverKind (this isn't clear because of the notation. Is this a normative value - if so this needs to be made clear. At the moment it looks like an error of ommission. ''Architecture Principle' should be 'Architecture Description Principle'.

3) Is the notation supposed to indicate that Driver has an attribute 'DriverKind' which has a set of enumerated values? Even in the UML you'd show an attribute on Driver and link this to the enumeration so this notation doesn't look to be complete. It could be interpreted as a form of specialisation of Driver

4) There are no means to describe the 'alignment of architecture (description) with architecture heuristics, guidelines, and principles' - no relationships provided, no target elements to link Driver to etc. As shown a compliant architecture view wouldn't even constitute architecture desctiption since it'd be pemissible to provide a single Driver element not linked to anything - an orphan or soliton - which isn't describing anything.

5) The multiplicity on DriverKind is incorrect - shows 0..1 which allows Driver to take an empty undefined value. This not only fails to address the architecture viewpoint concerns but is indeterminate. Should be '1'.

6) The enumeration shown for DriverKind and on Fig 9:138 has no default value specified.

7.2 Viewpoint Interrealtionships p 16

The errors in this section are:-
1) title - consistency 'Viewpoint' here is MODAF::Viewpoint NOT ISO42010::Architecture Viewpoint (or indeed the casual meaning of 'viewpoint'). None of this is clear. This is the UAF not the MoDAF - there is no need to use MODAF::Viewpoint and it's confuysing when the text uses 'viewpoint' to mean different things without defining terms. The section doesn't identify relationships between (MODAF) Viewpoints either.