Figure 2.1 page 4 should be Figure 1.1
Figure 2.2 page 4 should be Figure 2.1
Figure 2.3 page 5 should be Figure 2.2
References to the original figure numbering in the text need to be modified
Table on page 9-10 should have title
Table 5.1 Glossary of Abbreviations and Acronyms
Table on page 11-12 should have title
Table 6.1 Additional Materials

As stated in the clause 6.2, this standard intends to facilitate end user who want to communicate with DoD and MOD.
If so, this standards need not to be an ISO or ISO/IEC standard.

Add the definition for NAF in clause 5.

Action:- Added NAF and its definition to the appropriate place in table 5.1

Action:- We modified text in the scope section.

UML2.3 should be changed to UML 2.4.1unless there is inevitable reason, since UML2.4.1 has been standardized as IS.

Response:- At the time the standard was published UML 2.3 was the current version of UML. A change to UML 2.4.1 would invalidate the references to UML in the XMI resulting in a major change to the standard. It is envisaged that a major release i.e. UPDM 3.0 aka UAF 1 would update the references to the latest versions of UML and SysML available.

What allows (arrows) in the diagram do mean? Are they support or consist of UPDM?

Action:- New diagram created using UML notation to replace original

Designate references like as other OMG PAS documents
See UML2.4.1

Action:- Modified the bullet

The title should be mentioned like;
Information technology - Object Management Group Unified Profile for DoDAF and MODAF (UPDM 2.1)

Action:-Added (UPDM 2.1) to the end of the title on page 3

Action:- Created new higher definition version of diagram and replaced it

from section 4 delete the sentences
No new terms and definitions have been required to create this International Standard. All terms should be available in the normative references or bibliographic citations for detailed explanation.
And add the sentence

Any additional terms created to implement UPDM have been defined within this standard.

GB remove title sections for 3.3 and 3.4
Delete section 3.4 completely
Add reference to
DoD Architecture Framework 2.02 http://dodcio.defense.gov/Library/DoDArchitectureFramework.aspx

References
• ISO 8601:2004 Data elements and interchange formats- Information interchange-Representation of dates and times, IS0/TC154
• ISO/IEC 19505-1 , Information technology — OMG Unified Modeling Language (OMG UML) Version 2.4.1 — Part 1: Infrastructure; pas/2011-08-05
• ISO/IEC 19505-2 , Information technology — OMG Unified Modeling Language (OMG UML) Version 2.4.1 — Part 2: Superstructure; pas/2011-08-06
• OMG Specification formal/ 2010-05-03, UML Infrastructure, v2.3
• OMG Specification formal/ 2010-05-05, UML Superstructure, v2.3
• OMG Specification formal/ 2005-09-01, XML Metadata Interchange (XMI), v2.1

• OMG Specification formal/2006-05-01, Object Constraint Language, v2. 0
• OMG Specification formal/2012-03-01, SoaML, v1.0
• OMG Specification formal/2010-06-01, SysML, v1.2

• The MOD Architectural Framework (MODAF) Version 1.2.002 (https://www.gov.uk/guidance/mod-architecture-framework)
• The DoD Architecture Framework (DoDAF) Version 2.02 (http://dodcio.defense.gov/Library/DoDArchitectureFramework.aspx)

The clause 3.4 describes the DoDAF 2.02 Conformance. However, the “Compliance” is already described in clause 2. The structure is confusing.

Delete the section entitled 3.4.1 DoDAF 2.02 Conformance
Create section in section 2, 2.2 Compliance to DoDAF 2.02
Add text
UPDM 2.1 conforms with DoDAF 2.02

text should be

ISO 8601:2004 Data elements and interchange formats - Information interchange - Representation of dates and times, IS0/TC154 (http://www.iso.org/iso/home/store/catalogue_ics/ catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=40874)

Add these references to section 3

ISO/IEC 19505-1: 2012(UML 2.4.1 Infrastructure), ISO/IEC 19505-2: 2012 (UML 2.4.1 Superstructure), ISO/IEC 19507:2012 (OCL )

The “UPDM RFC” suddenly appears without a definition or a reference. It seems that this RFC is meaningless. This sentence is informative. It is obvious matter to follow the RFC.

Remove the description which mentions the “RFC”. Or if the RFC is inevitable, it is necessary to reference to RFC or remove the RFC.

Delete RFC from the paragraph
This International Standard reuses a subset of UML 2 and provides additional extensions needed to address the requirements of developing UPDM. We have used those requirements as the basis for this International Standard.

This clause describes the class library using class diagram. However, there is no class definition for each, that is, there is no attributes description and association description.

UPDM Group response
The OMG architecture board did not require this level of detail in the documentation so it was not added.

Modified the scope and sections 6.2.1 and 6.2.2 replace the original sections with this text

6.2.1 Intended Audience
This specification will be of interest to end users, military, industrial and commercial, who expect to use this profile, and to tool vendors interested in developing tool support for the development of enterprise and system of systems architectures.
Section 6.2.2 Organization of this specification
DoDAF and MODAF are formally expressed as domain-specific meta-models known as the DoDAF Meta Model (DM2) and the MODAF Meta Model (M3) respectively, this provides the foundation for the UPDM domain metamodel and profile. There is also a set of viewpoints and views that address the concerns of a well-defined set of stakeholders. This specification organizes the presentation of the UPDM 2.1 abstract and concrete syntax around the meta-models, with effort made to establish a maximum set of common Core models and a minimum set of DoDAF DM2 or MODAF M3 specific models. Significant effort has also been made to continue to support the now over 50 viewpoints that can be derived from these meta-models as well as "user-defined views". This allows tool-vendors to specify views, based upon a common metamodel that are more applicable to industrial and commercial concerns than just military, it also ensures that the discussion is well-connected to the domain experts required to produce these views. (See Section 1.5 for a more detailed description.)"The rest of this document contains the technical content of this specification. As background for this specification, readers may wish to review the UML, OMG SysML, and SoaML specifications that complement this specification.

This document refers to “DMM” which is defined as non-normative Annex A. However, it seems to be Normative. Besides, according to the text, it is necessary to refer to the colour legend. However, I couldn’t find the legend.

Clarify this sentence. If those were Normative, move DMM to the body parts.

Response,
add colour coding legend and explanations.

The DMM is intended to be informative and was used to develop an understanding of the foundational concepts from which the UPDM profile evolved. It remains useful for understanding the architectural concepts required to implement UPDM. It is expected that UML and SysML tool vendors who implement UPDM would implement this profile rather than the DMM; however, it is possible non-UML tool vendors may wish to implement UPDM in their by tool by following the DMM.
In annex A delete the second paragraph starting “Note that the” and replace with the text and diagrams below.
Note that the diagrams rely on color to aid the reader in understanding the model. Please refer to the legend below to understand the diagrams.
The following is the legend of element colors used in the DMM and what they denote.

Table 5.1 modify DOTMLP to DOTMLPF

According to the explanation, the “Partitioning” is the package. However, I couldn’t find the packaged diagrams except for the “Aliases”. It seems that it is necessary to define UPDM using Package diagrams.

Replace the Pertitioning section 7.3 with the following.
Partitioning: The UPDM profile is organized as a number of hierarchical packages that are used to group elements, and to provide a namespace for those grouped elements. The top level structure of these packages can be seen in Figure 2.2.(Packages are represented in the diagram by a rectangle with a tab in the upper left hand corner).

The UPDM classes are defined using class diagram and those descriptions. Some class diagrams specify association link. However, there is no description for association as text..

UPDM Group response
The OMG Architecture board did not require this level of detail in the documentation so it was not added.

In case of UML, inheritance is described as “Generalization” in texts. However, in this document, inheritance is described as “Specializations”. It is confusing.

Unify the representation style for the inheritance, that is, decide which representation is taken.

UPDM Group response
Although the relationship is called generalization in UML, the term is dependent upon the direction from which the relationship is being viewed. If taken from the perspective of the element which is the is focus of a specific diagram (which is the case in this specification), the term used is specialization.

There is no clause number & heading on the first paragraph right after “Subpart”. It is a hanging paragraph

Action:-These subheadings are in the OMG template and from reviewing other PAS submissions it reveals that these documents have been submitted to ISO using the same format.

"UAF" written in the explanatory report should be made an international standard.

Currently UPDM does not map a numer of elements that exist in DM2, namely those above the Type level, for example CapabilityType since UML does not support elements at higher type levels. There is however a possibility of doing this by recognising that a set of capabilities (as an example) contains a given capability instance but capability categoreis are really a larger subset of available capabilities. This would make it possible by allowing the elements to contain a tagged value that indicates whether they are to be considered at a higher type level. This would make it possible to provide a mapping between more DM2 elements and UPDM elements than currently possible. It is assumed that a tagged value would be easier to handle than the introduction of additional stereotypes since categories would imply elements with different stereotypes inheriting from one another.

ActualServiceInterface:
This would be an element that is the equivalent of the MODAF element ServiceLevel and would contain slots and instance values for the properties that have been defined for ServiceInterface. There would be a need to provide a tagged value to any usage of the ServiceInterface as a port either on a NodeRole or ResourceRole where the actual service interface would be indicated that is to be viewed as a requirement for this particular context. For the port used on the ResourceRole there would also be a need to indicate how many instances of the actualServiceInterface that the ResourceRole would need to accomodate, at least if a complete mapping to between MODAF and UPDM is to be achieved. (All of this actually exists already as part of the MODAF model that UPDM is supposed to implement).

Figure 7.8 uses <<metaproperty>> where it means <<metaconstraint>>

For IT and systems engineering experts who are not familiar with military matters it is unreasonably difficult to understand the title of this standard and its significance for IT and systems engineering in general.

Add, immediately under the heading “Subpart I – Introduction” on page 1, an introductory paragraph e.g. as follows: “This international standard provides a specification language, UPDM, that is readily understandable not only by the community of architects of information technology systems but also by a wide range of end users including executives and enterprise management that sponsor such systems, program managers that oversee their development, developers of supporting hardware and software (design, implementation, and testing), subject matter experts, and end users. UPDM bridges the gap from setting of requirements to high level system design and to visualization for practitioners. While designed in the context of military organisations and their procurement processes, UPDM can also be applied in entirely civilian industrial and service organisation contexts.”

Use of superSubType, wholePart and WholePartType in DoDAF 2
DoDAF 2 contains rules that indicate that superSubtype relationships can be formed between any type elements of the same kind. The same rule applies for wholePart (betwen individuals of the same type) and WholePartType (between types of the same kind). In UPDM terms this would correspond to Generalization as well as property handling. There are not enough stereotypes defined within UPDM 2 to allow these rules to be followed. This either needs to be rectified or a general statement made within UPDM that allows the use of the appropriate UML relationships to accomplish this.

I really need "Desired Effect" reinstated. This will act as the "Objective" in my strategy models. This was available in UPDM 1.0 now it's gone. This is actually very important to modeling a strategy.

However, when or if you can bring it back, it previously provided the output link of "Realizes Vision". That is wrong. It needs to "Realizes Enterprise Goal". It's the Enterprise Goals that realize the Mission. And it's the Mission(s) that realizes the Vision.

The sequence is as follows:

CAPABILITY-->DESIRED EFFECT->ENTERPRISE GOAL->MISSION-->VISION

While the proper implementation of a UPDM 2.0 Profile assures successful exchange of data models, the exact content of the VIEWS remain non-normative. There needs to be a definition of the minimum data elements to support each view as well as optional data elements. The UPDM RTF Group needs to discuss whether all (52?) Views need to be made NORMATIVE, how to support Optional data, and how to support the required USER-DEFINED VIEWS.

The Model library in the UPDM profile should be external to the UPDM profile

When the specification is generated, the generator should emit cross-references for references to model elements throughout the text.

An import use of architecture is to provide sufficient information to guide the design and implementation that realizes the architecture in the actual solution space. By definition, architecture dictates neither the design nor the implementation that realizes it, though this boundary is often blurred to a certain degree by a particular organizations methodology or pragmatic need of a projects.

As SOA is an a widely employed architectural pattern where by systems interact with each other, it would seem important that the expression of SOA in UPDM be fit for purpose, sufficiently accurate and information complete to reduce the conceptual gap between architecture and design+implementation. Further, the rendering or specification of SOA interfaces and used datatypes should be sufficiently fine grained to allow such possibilities as:

Transformation into constructs used in design and implementation workflows, e.g. Code Skeletons, XML Schema, etc.

Supporting the expression of test cases and declarative expressions of architectural instrumentation for such purposes as monitoring and analytics.

In this particular issue we focus on the SvcV-1 and SvcV-2, which would be the natural place to specify the actual SOA related elements. The following diagram provides a context from an external, classifier derived perspective.

Focusing on the services themselves, the diagram below shows an intended

The SvcV-1 that illustrate the specification down to the actual operations is shown in the following diagram

The issue submitter acknowledges that there are arguably some other ways to represent services, given such constructs as ServiceFunction, etc., but the method depicted above “feels” more accurate and aligned with downstream design and implementation, especially in the context of UML that might be used by teams independent of UPDM.

In conclusion, the issue submitter, along with project colleagues, wish to have a useful set of mechanisms/metamodel constructs that allow the expression on services, their interactions and the flow of data between them at the PIM/Logical level using, logical data captured as EntityItem that details conceptual data captured as ExchangeElement. This would allow direct traceablity from conceptual interchange expressed at the OV level with how it is addressed at the SV level. In simpler terms, when two activities exchange information at the business process level, we can easily find how this conceptual interaction is realized as SOA services. Once establishing this in the model we can then hand it off to design and implementation workflows in a more accurate, traceable and useful architectural specification form. Significantly, such and architecture might prove much more fit-for-purpose for model related practices, transformations and automations involving the instrumentation, simulation and observation of the architecture in its solution realized forms. Also tests might be expressed more tightly.

Resolution:
Part of the resolution would be related to the fact that and ExchangeElement is subtyped from ResourceInteractionItem whereas EntityItem is subtyped from Class. The result is that a logical data structure captured as an EntityItem cannot be the conveyed item in a ResourceInteraction. We would either need to revise the metamodel related to ResoureInteractionItem or add some new construct, say something like DataInteractionItem and DataInteraction that could be used to express the flow of logical data, which the issue submitter models using EntityItem in DIV-2 package structures.

On the profile diagram below, one can observe the absence of EntityItem

There are related traceablity issues that will the subject of further submissions, however, this submission focuses on the essential part of expressing the set of SOA ports, interfaces and data flows in an architecture.

Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and callOperationAction. Please enter issue against UPDM RTF 2.2.
Allow ( OperationalActivityAction, ServiceFunctionAction, ProjectActivityAction and FunctionAction ) to be represented as either CallBehaviorAction, CallOperationAction or Actions. Currently only CallBehaviorAction is allowed.

In UPDM 2.0 Exchange Elements emerged from Information and Data Elements used in UPDM 1.x. They can still be classified into information and data indicating different levels of abstraction. However, one cannot be connected to another as it used to be in UPDM 1.x. In other words there is no way to relate data to information.

Please enter this issue against UPDM RTF 2.2.
Simplify measurements in UPDM and make measurement compatible with SysML unit, value, and parametric constraint.
See diagrams below. No need for measurement set.

As shown in Figure 8.127 for CapabilityConfiguration to PhysicalArchitecture and Figure 8.130 for PhysicalArchitecture to SystemResource and in Figure 8.178 for System to ResourceArtifact, Figure 8.132 for ResourceArtifact to PhysicalResource, Figure 8.131 for PhysicalResource to SystemResource, one can see that System and PhysicalArchitecture are sibling concepts.

Now, FieldedCapability has this constraint: "Value for the classifier property must be stereotyped «CapabilityConfiguration» or its specializations." (see Page 172)

The consequence of this is that a self-contained System cannot be the Classifier of a FieldedCapability. That is, a FieldedCapability cannot be an instance of a System.

I claim that it is convenient to be able to specify that a FieldedCapability is an instance of a self-contained System. Having to model a separate CapabilityConfiguration to wrap just the System so that one can instantiate a FieldedCapability that is an instance of the System seems onerous.

The recommended remedy is to allow a System to be a proper CapabilityConfiguration in addition to being a property of a CapabilityConfiguration.

Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture.

The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"-which is poorly named and which suggests the means of accessing a single entity-and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc.

ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration".

Recommendation: either add <<SOAML::ServiceArchitecture [Collaboration]>> directly into UPDM or add <<UPDM::ServicesCollaboration [Class]>> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations.

Constraints and Parametric Blocks in the SysML notation have proven their value in enabling the use of models as parameters for discipline-specific analysis and simulation. Likewise, SysML Requirements have proven their usability for annotating models with Requirements and with Requirements Traceabilities (such as Satisfaction, Derivation, etc.)

The user community (including MITRE, Raytheon, Intercax, and professional services architects such as No Magic staff) requests that UPDM integrate the Requirements, Constraints, and Parametric Blocks into UPDM. Then, Enterprise Architects using UPDM can perform their systems and econometric analyses and their requirements engineering with their UPDM models that they can perform today in SysML modeling.

(How and Where such integration is accomplished is a topic worthy of deliberation but is beyond the scope of a customer-centric requirement request.)

In UPDM we are missing capability to differentiate between Logical and Physical Services. Note that this capability is already supported in DoDAF. It is also supported in other frameworks such as TOGAF etc.
In UPDM it is mixed up and not clear enough what kind of services we are allowing to define. If we use services in SVs, we suppose to have physical services. If we are using services in OVs, we suppose to have Logical (Business) services. Having a normal logical/physical pattern we are already using in UPDM, we should be able to have traces between the two. Unfortunately we cannot differentiate between logical and physical services. It implies we cannot have two different levels of details when we are dealing with services. And we are forced to do services in either Operational or System viewpoint, but not in both.
UPDM should:
• Enable user to model logical services
• Enable user to model physical services
• Allow traces between logical and physical services
• Provide means to integrate logical services to OVs
• Provide means to integrate physical services to SVs

SBVR, the Semantics of Business Vocabularies and Business Rules, provides a formal logical foundation for the expression of enterprise ontologies and rule constraints applicable to enterprise elements. SBVR also offers informative, non-normative notations for these vocabularies and rules.

Future increments of UPDM (i.e. UAFP v1) should not preclude an enterprise architect from using SBVR and its metaclass elements for the expression of ontologies and rules within their UPDM (to be known as UAFP) models.

These enterprise ontologies and enterprise rules appear throughout a traditional UPDM architecture description in the structural elements of the respective views (e.g. Performers, Operational Activities, Systems, Services, etc) and in the constraints on those elements.

According to the definition of ProjectSequence, "MODAF: Asserts that one ActualProject (MODAF::Project) follows from another - i.e. the target ActualProject cannot start until the source ActualProject has ended. DoDAF: NA".

The restriction "...cannot start until the source ActualProject has ended..." precludes practical project management.

In practice, projects can have a partial ordering yet not be strictly sequential. Projects can overlap each other in time, occurring partially contemporaneously.

One sees, in a common tool such as Microsoft Project, the ability to specify Start to Start, Finish to Finish, Start to Finish, and Finish to Start offsets.

Recommended Remedy: Enhance Project Sequencing to support SS, FF, SF, and FS offsets between prior and next ActualProjects. The kind of offset and the duration of the offset would each be Tag Values of ProjectSequence.

In the current DoDAF Project Viewpoints (PV1) the project element has a start date and an end date. Those attributes are not sufficient for the US JCIDS process. In the incremental development process described by JCIDS, we have increments, blocks and spirals. In the main we don't measure our programs in absolute start and stop dates but rather where they fall in the relative JCIDS process, priority and lifecycle. Start dates are usefull but with a 20-30 year lifecylce, the stop date is not as useful. Having these attributes (increment:string, block: int and spiral:int) in the Project Element would allow us to trace requirements and capability sets to the proper increment, block or spiral.

UPDM includes a <<Property>> stereotype with properties maxValue, minValue and defaultValue. <<CapabilityProperty>> specializes the Property stereotype and extends the Property metatype.

1. could you rename the Property stereotype to avoid confusion with the UML metatype of the same name?

2. since the UML metatype Property already has a defaultValue, could the UPDM one be removed?

3. the min/max/defaultValue properties have no multiplicity specified in the spec or XMI, so it defaults to 1. If these were intended to be optional they should be specified as [0..1]

These impact XMI (see MIWG TC22).

There is a constraint stated in Figure A.30 of the dtc/12-12-17 specification such that in MODAF (and therefore NAF), the MapsToCapability relationship is precluded from using OperationalActivities and is prescribed to only use StandardOperationalActivities.
This has resulted in defining another relationship in the spec called ActivityPartOfCapability for DODAF, that creeps into MODAF and NAF in vendor implementations, to allow one to associate an activity with a capability for the purposes of generating traceability diagrams and for generating NPV-2: Program to Capability Mapping (through Activity is part of project, and Activity is part of Capability). There is no need for both and it is redundant and a possible source of model inconsistencies to request the architect to define both MapsToCapability and another called ActivityPartOfCapability. Further, the MODAF constraint to use only StandardOperationalActivities when mapping to capabilities for the purposes of (MODAF policy?) can be accommodated in another manner.

In UPDM it seems that the Service to OperationalActivity matrix is non-editable. The relations are established after one creates capability to OpAct relations and capability to service relations (in CV-6 and CV-7/NSOV-3 respectively). This may be how it is explained in DODAF/ MODAF? (no direct relation between ServiceInterface and OperationalActivity:

But it is not how it should be. Here is why: CV-7 is useful when considering how services that may already be available (internally to subject architecture scope, or provided by third party entities) can be leveraged to enable the required capabilities. However, a true model-based approach to capability development and analysis will include an operational view model that further delineates the capability (stated as a term and a definition) and describes the ways and means needed or provided to enable the capability. Such an analysis usually uncovers issues with the defined capability taxonomy such as overlapping or non-mutually exclusive capabilities, and will lead to a better formulation of the capability taxonomy. The operational model is also used as a guide to develop or identify needed services in a service model. Thus, it is good SE discipline not to try and develop CV-7 starting with two sets of taxonomies, one for capabilities and another for services, without conducting the necessary modelling of operational and service artifacts needed, conducting the analysis, and “discovering” the relationships between capabilities and the services needed to enable them. So I propose that the order is like this:
1. develop a Capability taxonomy (CV-2);
2. develop Operational views (especially the behavior diagrams)
3. iterate on capability taxonomy and op behavior until one is somewhat satisfied that the capability taxonomy and operational elements (as modeled) are consistent and capabilities are well delineated. At this time a CV-6, (Capabilities x Operational Activities) matrix may be generated;
4. develop a service view model that supports the operational model and evaluate the ability of the enterprise to offer each Capability and make a Build versus Buy/Outsource decision. Some more iterations on elements in CV, OV, and SOV may take place again, especially as the services taxonomy and service orchestration diagrams are developed. That is, the service model may cause Operational Activities as well as capability taxonomy to change again. Once things stabilize, an SvcV-5/NSOV-3 (Services x Operational Activities) matrix may be generated;
a. For those Capabilities that will continue to use existing systems within the Enterprise, model their As-Is Systems Views;
b. For those that are to be Built, or are to be Bought, model the the Services Views to identify (conduct an analysis on what is available within and outside enterprise), and identify the contractual Service-Level Agreements and indicate the Service orchestration with the Enterprise's Performers.
i. For services to be built, proceed to detail in systems view
ii. For services to be outsourced stop detail here (services view) but show they are used in systems view (via service request interfaces for system components.
5. when one feels that the operational and services models satisfy the updated capability taxonomy, one can generate (from the relationships already established), the Capabilities x Services (CV-7) matrix
6. Develop Systems Views and then map (system) Functions to Services and Functions to Operational Activities.

Issue 18739:
Name: Fatma Dandashi
Employer: Mitre Corp.
mailFrom: dandashi@mitre.org
Terms_Agreement: I agree
Specification: UPDM Profile
Section:
FormalNumber: dtc/12-12-17
Version: 2.1
Doc_Year: 2012
Doc_Month: December
Doc_Day: 17
Page: 218
Title: use of Generalization to implement Aliasing
Nature: Enhancement
Severity: Significant
CODE:
B1: Report Issue
Remote Name:
Remote User:
Time:

Description:
DMM defines system as a DoDAF-only alias for ResourceArtifact:

Profile then defines the following: (this is probably true for all elements that are aliases).

Using generalization in this manner means that vendor implementations allow one to use both System as well as ResourceArtifact in the same model, regardless if one is using DoDAF or MODAF. System is an alias for MODAF’s ResourceArtifact in DODAF only. That is, System should not be available as a choice in MODAF/NAF. More importantly: generalization is really not the best UML construct to implement aliasing. If you choose System in NAF, you will not be able to use composition and aggregation relationships on SV-1. One should be able to use System in exactly the same manner as a ResourceArtifact, especially the a

Currently, one has to use ActualProject and ActualOrganization to get an organizational to project mapping. Why not organization and project types? Understand this theoretically, (only a “real” organization can undertake a “real” project), however what if the architecture description itself was all a pattern? I should be able to associate classes of organizations (a type) with classes of projects.

Profile:

Issue State machine issue: UML states the subject of a state machine can be behavior or structural: “The StateMachines package defines a set of concepts that can be used for modeling discrete event-driven Behaviors using a finite state-machine formalism. In addition to expressing the Behavior of parts of a system …, state machines can also be used to express the valid interaction sequences, called protocols, for parts of a system. These two kinds of StateMachines are referred to as behavior state machines and protocol state machines respectively.”
MODAF specifies both node and activity, DODAF says activity only:
Short Name DODAF DODAF MODAF/NAF MODAF/NAF
OV-6b OV-6b State Transition Description DoDAF: The Operational State Transition Description (OV-6b) DoDAF-described View is a graphical method of describing how an Operational Activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. OV-6b Operational State Transition Description MODAF: OV-6b: The Operational State Transition Description is a graphical method of describing how an Operational Node or activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action.
UPDM states node only?

Information Exchange (IEs) item or element: Currently all IEs are defined as elements of package AllView. This should not be the case. There needs to be a distinction between Operational View IEs and Systems View Exchange elements.
Discussed Resolution: Currently in MODEM, only InformationElement flows are allowed in OVs (see below). MODEM will use FlowedElement instead. Will consider changing its current type from abstract to make it a typed generic flow defined in OVs. An abstract ResourceType is defined for SVs. It will have as subtypes: human, non-human etc. as shown below. In addition, subtype InformationElement will be moved from current location to be a NonHumanResourceType defined in SVs. Allow any of the SV ResourceType leaf level elements (e.g. NaturalResourceType) to trace back to OV flows.

For UAFP. Include a Data and Information view (DIV). This view is to be used for domains where a DB is needed. Remove DIV-3/ SV-11 physical schema as a supported model/Diagram type. Make it an external reference only, either a physical schema in another tool, or an XML flat file etc. Change DIV-1 and DIV-2 to be defined/associated with Systems View elements only, since you only specify data conceptual and logical models at the solution level. In SV, the InformationElement will be a NonHumanResourceType that is associated with entities defined in DIV-1 and DIV-2, since only information can be stored in a database

Information flow instantiation. There is no UML construct to define flow and then to instantiate flows to use flow types and then flow instances that flow between two instances of two things.
Discussed Resolution: See simple exchange example in MODEM

Typical and actual posts, etc. should be introduced and defined in SV-1 as they are the human equivalent of systems, capability configurations, etc. It is in SV that we provide a PSM/white box/logical design model where we introduce elements (human as well as materiel) that are to be allocated to the problem domain described in OV.
Resolution discussed: introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them. Checked this in MODEM. Below is how it is currently defined.

Please enter this issue against UPDM RTF 2.2.

In UPDM 2.1 we are missing capability to decompose Enterprise Goals, e.g. goal, objective pattern supported by BMM. This capability is already available in MODAF 1.3 witch UPDM claims to support.

Why is EnterprisePhase to EnterpriseVision a one to one relationship? Composition relationship is also not needed.
Discussed resolution:
• change relationship to: one to many on EnterprisePhase end and 0..1 on EnterpriseVision end.
• delete composition relationship

Why are rules in OV-6a and SV-10a not parsed? They need to be specified as OCL constraints. Similarly for SOVs, use OCL to define performance level supported by each provider to each type of consumer as in a Service Level Agreement (SLA).

The term NodeRole is more applicable to MODAF than DoDAF and does not derive from Performer, Ron Williamson sugested PerformerRole.
There are other terms that could be affected in the this way like NodeOperation.

Even though I understand the need, I am against creating more Stereotypes that are Aliases for DODAF. It becomes harder to maintain and more problematic for implement. I would suggest that we rationalise the name of the stereotype for instances of Nodes/Performers to be aligned with both MODAF and DoDAF, i.e. OperationalNode.

Why does a user need to build an SOV-3? The relationship from services to capabilities should be transitive. Once a user establishes traceability from operational activity to capability and from ServiceFunction to Operational Activity, then there is already a trace from owning service (service that owns that ServiceFunction) to a capability and SOV should b au-populated. Further, a service(Interface) should map to a node and not to an OperationalActivity or to SystemFunction. This change is to be discussed with respective requirements representatives.

Desired affect targets "state" in UPDM 2.1, states must have a context and this causes the architects to think too low down in the model (at the OV and SV level) where implementation exists. Desired affect needs to be tied to something in the CV/Stv that is not a "state", called Effect in the CV/StV.

It would help if the tools flagged or restricted Capability definition to encourage the definition of:

• Effects and metrics
• Activities involved
• Conditions under which conducted
• Performer (optional – often not known during pre-MS A)
• Desirer of the Effect (optional)

Rationale from Dave McDaniels:

Capabilities vs Activities. As you know, the DM2 Capability model is built about the JCIDS definition and centers around effects (resource states) that are measureable (have metrics so you can tell if they've happened) and is produced by ways (Activities) and means (Performers) under specified Conditions (i.e., PMESII, DIME). Thus they are quite a bit different from Activities which transform inputs to outputs or change their state. Many comments are being generated and much argument and rework because many CV's are missing pieces or are clearly Activities being described, not Capabilities. For example, I just turned in a comment on the IdAM RA on their CV in which they defined the Capabilities in terms of their Inputs, Controls, Outputs, and Mechanisms – ICOM – the exact prescription for Activities in IDEF0.

Note that a PES file that did not have the required pieces and that claimed to contain CV information would fail validation. Also note the DoDAF-DM2 formulation of CV's fits the JCIDS-DAS-SE processes by linking ICD threshold and objective attributes and CDD/CPD KPP/KSA/OSA to the CV's and to the T&E process by aligning the architecture and JCIDS documents to test metrics. This method was also designed to allow flow down of operational metrics (MOEs) to SV/SvcV (e.g., SV-7) metrics (MOPs). It also aligns with training since UJTL tasks have measure types (several defined per task), UJTLs map to JCAs, and JCAs are the organizing construct for ICD attributes and are also required in CDD/CPD. There are probably many other elements of architecture and systems engineering that align by defining Capabilities the way we did in DoDAF. DoD CIO A&I and Joint Staff J6 are in very close agreement on all this.

A tool that is DoDAF conformant should encourage the user to fill in the Authoritative Source field whenever they define a new architecture element (AV-2). The Authoritative Source should provide specific locator for the source of the term and definition. Multiple AS may be occur.

Rationale from Dave McDaniels:

Almost every JIE architecture gets a comment from JS J6 that the AV-2 is missing the Authoritative Source for the term and definition which they say is a DoDAF conformance requirement. The problem they’re really getting at is the proliferation of inconsistent AV-2 terms even in a single project like JIE, even worse across all the mission areas. The number of AV-2 terms in the WMA repository is in the tens of thousands if not more by now. Mapping, reconciling, adjudicating, etc. is impractical. Their approach is to encourage reuse of terms to encourage standardization, e.g., the Joint Common System Functions List (JCSFL), JCAs, UJTLs, … Everyone agrees but the AV-2 Authoritative Source fields remain blank – once the toothpaste is out the tube, very hard to get back in.

One or more clients of No Magic Professional Services seek to be able to model the systems, services, test case behaviors, test data, and so forth of the verification and validation of their UPDM-specified Systems and Services.

These clients are already using SysML within UPDM for their Requirements engineering and for their Systems Viewpoint modeling.

SysML delegates Verification concerns to the UML Testing Profile via SysML's <<verify>> Relationship between Requirements and Test Case activities.

These clients of No Magic ask that No Magic champion the integration of the UML Testing Profile-or any other standardized set of concepts-into UPDM.

Figure 8.1 on page 23 has two symbols for the same element: InformationAssuranceProperties appear twice on the diagram.

One instance of the symbol would suffice.

This issue relates to the readability of the specification on the various "view diagrams", DoDAF elements are left of off these diagrams it becomes hard to recognise which diagrams use specific DODAF elements, it is only through understanding what things have DoDAF aliases that you can see what needs to be added to the correct diagram.

These elements need to be added to the diagrams that they can participate in by showing the MODAF elements that they alias/inherit properties from.

There is no support for the specification. The DoD CIO is not updating or supporting DoDAF documentation. The IDEAS group is defunct. No one is maintaining DM2. The website udpmgroup.org is for sale. See http://www.omg.org/syseng/UPDM.htm. The specification appears to be generated from a model, and is way below the quality standards for other OMG specifications.

Add support for Value Streams in UAF. Please consider Value Streams implementation as described in Business Architecture Metamodel. Provide support for strategic value streams, value stream stages, before/after relationship between different value stream stages, value networks, operational value streams, and outcome (value) produced by the value stream.

Reported in behalf of Boeing

we need to be able to add requirements in UPDM, define test cases and use requirement relations (refine, verify). by adding stereotype <<requirement>> to current class-type capability, we can do all of the above. or at least add in profile a defined relation to relate requirements to capabilities.