Issues for UPDM Finalization Task Force

To comment on any of these issues, send email to updm-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 11165: Section 6: list of XMI files for the compliance levels (updm-ftf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 6 lists the XMI files 'for the compliance levels' which include those for the 'formal metamodel'. However the formal metamodel is currently in a non-normative Annex. Personally I would like to make the metamodel a proper compliance point.

Resolution:
Revised Text:
Actions taken:
July 19, 2007: received issue

Issue 11166: Section 6: 'Class Library' should be 'Model Library' (updm-ftf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

in section 6 and elsewhere I think 'Class Library' (which does not exist as a UML concept) should be 'Model Library' (which does).

Resolution:
Revised Text:
Actions taken:
July 19, 2007: received issue

Issue 11237: SysML stereotype references in the UPDM specification need to be updated (updm-ftf)

Click here for this issue's archive.
Source: Raytheon (Dr. Ron C. Williamson, Ph.D., ron_c_williamson(at)raytheon.com)
Nature: Revision
Severity: Minor
Summary:

The SysML stereotype references in the UPDM specification need to be updated to reflect the latest results of the SysML FTF revisions.

Resolution:
Revised Text:
Actions taken:
July 31, 2007: received issue

Issue 11325: Section: 4.3.3.3 (updm-ftf)

Click here for this issue's archive.
Source: Visumpoint (Mr. Robert Lario, robert.lario(at)visumpoint.com)
Nature: Clarification
Severity: Minor
Summary:

Should there be some association between ArchitectureDescription and Enterprise depicted? If not why is the Enterprise Stereotype shown here?

Resolution:
Revised Text:
Actions taken:
September 5, 2007: received issue

Issue 11326: Section: 5.3.4.2 (updm-ftf)

Click here for this issue's archive.
Source: Visumpoint (Mr. Robert Lario, robert.lario(at)visumpoint.com)
Nature: Clarification
Severity: Minor
Summary:

There appears to be a typo in the table. Note that the elements repeat in the table

Resolution:
Revised Text:
Actions taken:
September 5, 2007: received issue

Discussion:

Issue 11327: Section: 4.3.14.4 (updm-ftf)

Click here for this issue's archive.
Source: Visumpoint (Mr. Robert Lario, robert.lario(at)visumpoint.com)
Nature: Revision
Severity: Significant
Summary:

There is a reference to PerformanceMeasurementPeriod, yet PerformanceMeasurementPeriod is not defined in the document.

Resolution:
Revised Text:
Actions taken:
September 5, 2007: received issue

Issue 11329: Section: 4.2.10.6 (updm-ftf)

Click here for this issue's archive.
Source: Visumpoint (Mr. Robert Lario, robert.lario(at)visumpoint.com)
Nature: Revision
Severity: Minor
Summary:

Constraint 4 documentation does not match OCL shown

Resolution:
Revised Text:
Actions taken:
September 6, 2007: received issue

Issue 11330: Page: 29 - Image shown is to small to read (updm-ftf)

Click here for this issue's archive.
Source: Visumpoint (Mr. Robert Lario, robert.lario(at)visumpoint.com)
Nature: Clarification
Severity: Minor
Summary:

Image shown is to small to read

Resolution:
Revised Text:
Actions taken:
September 6, 2007: received issue

Issue 11344: UPDM -- title (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Footer is "Business Maturity Model" should be "UML Profile for DoDAF and MODAF, Beta 1

Resolution:
Revised Text:
Actions taken:
September 12, 2007: received issue

Issue 11345: 8.4.8.6 Constraints (updm-ftf)

Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 Need a constraint that asserts that the InformationExchange must be realized by at least one of the realizations.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11346: Section: 8.6.11.6 Data Exchange (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Need a constraint that asserts that the DataExchange must be realized by at least one of the realizations

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11347: Section: 8.4.12.8 Notation (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

The paragraphs:
Needlines may be generated automatically, derived from InformationExchanges, from ActivityEdges in OperationalActivities, and from Messages in OperationalEventTraces. 

Is a duplicate of the same paragraph in the previous section

The paragraph:
In structure diagrams where two OperationalNodes are depicted with a Connector belonging to a message, the Connector should be typed with the appropriate Needline that represent the message in an OperationalEventTrace or control flow in an OperationalActivity. 

Does not make much sense

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11348: Section: 7.1 Design Principles for the Architecture (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

This specification used the following design principles that support the domain needs and design rationale described above. 

Change to:
This specification used the following design principlesthat support the domain needs and design rationale described

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11349: Section: Figure 7.1 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

"Class Library" should be "Model Library"

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11350: Section: 7.3.2 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

pages are blank

Resolution:
Revised Text:
Actions taken:

Issue 11351: Section: Part III (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 9. UPDM Class Library Compliance Level 0 
Change "Class" to "Model"

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11352: Section: Figure 8.1 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Figure is messed

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11353: Section: Figure 8.11 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 Figure is shrunk down

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11354: Section: 8.6.34.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Minor
Summary:

the 3 items in [1] are in the wrong font.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11355: Section: 8.4.43.1 Extension (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 RealizedOperationalSpecification should extend InterfaceRealization, not just Realization.
�	InterfaceRealization (from UML 2)

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11356: Section: 8.6.18.1 Extension (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

RealizedSystemSpecification should extend InterfaceRealization, not just Realization.

�	InterfaceRealization (from UML 2)

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11357: Section: 8.7.5.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 [3] Asserts that there is a Capability Requirement for this OperationalNode 
 
OCL for [4] is correct for [3], but need OCL for [4]
[3] Asserts that there is at least one OperationalNode associated with this CapabilityRequirement
self.getAllAttributes()->asOrderedSet()->select(association-> notEmpty()).association-> any(getAppliedStereotype('UPDM::OperationalNodeCapabilityRequirement')-> notEmpty())->notEmpty() 

[4]  Asserts that an association exists between the CapabilityRequirement and at least one  OperationalCapability 
self.getAllAttributes()->asOrderedSet()->select(association-> notEmpty()).association-> any(getAppliedStereotype('UPDM::CapabilityRequirementCapability')-> notEmpty())->notEmpty()

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11358: Section: 8.5.7.7 Semantics (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

  "EventTrace" should be "OperationalEventTrace"
CapabilityRequirement associates an OperationalNode and OperationalCapability. The OperationalCapability is defined as a collaboration among OperationalNodes whose behavior is reflected in an OperationalEventTrace, an OperationalActivity or an OperationalStateTrace. The CapabilityRequirement shows the deliverable requirements - metrics, time period and milestones.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: reeived issue

Issue 11359: Section: 8.4.16 OperationalCapabilityRole (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Need an association between OperationalCapabilityRole and Goal so that we can model intent as a link between instance of a goal and an instance of OperationalCapabilityRole . If we define <<Objective>> then this relationship should be between Objective and OperationalCapabilityRole.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11360: Section: 8.3.13.5 Association (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 Need association between Goal and OrgResource that "defines" the Goal (BMM)

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11361: Section: 8.6.39.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

SystemGroupMember should include all of System specializations

8.6.39.6 Constraints 
[1] Asserts that there are zero or more System elements configured on the SystemGroup and that these are the elements associated with this association 
let e1:uml::Class = self.oclAsType(uml::Association).endType-
>at(1).oclAsType(uml::Class) in
let e2:uml::Class = self.oclAsType(uml::Association).endType-
>at(2).oclAsType(uml::Class) in
(e1.getAppliedStereotype('UPDM::SystemGroup')->notEmpty() and
(e2.getAppliedStereotype('UPDM::System')->notEmpty() or
e2.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::System') ->notEmpty()) ))
or
(e2.getAppliedStereotype('UPDM::SystemGroup')->notEmpty() and
(e1.getAppliedStereotype('UPDM::System')->notEmpty() or
e2.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::System') ->notEmpty()) ))

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11362: Section: 8.4.41 Policy (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Policy needs to be applicable to a much wider range of elements.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11363: Section: 8.6.12.5 Forecast Associations (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Forecast needs to apply to Capability, OperationalCapability and CapabilityConfiguration

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11364: Section: 8.6.26 SV-6 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Description is wrong - it is the same as SV-5
Should be:
"The Systems Data Exchange Matrix specifies the characteristics of the data exchanged between Systems. This product focuses on automated exchange of information (from OV-3) as actually implemented from a variety of data sources. Non-automated exchange of information, such as verbal orders, is captured in the OV products only."

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11365: Section: 8.3.10 ConformingElement (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Need to have a stereotyped association between ConformingElement and PerformanceParameterSet.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11366: Section: 8.3.14.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

PerformanceMeasurementSet needs to have conformingElement instance rule, in addition to the conforming element. The constraint makes sure the link exists.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11367: Section: 8.2.11 ProjectType (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

<<ProjectType>> is superfluous unless it has much more semantics from MODAF.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11368: Section: 8.4.28.3 OperationalStateTrace Description (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Description for OperationalState Trace is incomplete

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11369: Section: 8.4.28.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that this StateMachine is owned either by an OperationalNode or an OperationalCapabilityRealization. self.owner.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or self.owner.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') - >notEmpty() 

don't need 
or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') - >notEmpty() 

because OperationalCapabilityRealization is a specialization of OperationalNode

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11370: Section: 8.4.41 Policy (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 Policy should be in the All Views package

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11371: Section: 8.3.4.3 ArchitectureView Description (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Description is confusing.
If the ArchitectureViews are Viewpoints, as described in the Viewpoint description:

"ArchitectureView can be used to implement the Viewpoint/View capability. As a UML Package, ArchitectureView is a nested construct. Using a CustomView, a new Viewpoint can be defined, and custom views can be defined within this new package. "

then the Views should not be subclasses of them. That is if OperationalView is considered a Viewpoint, then OV-1, a View should not be a specialization.
On the other hand, <<Vewipoint>> specializes ConformingElement that extends Class, so the ArchitectureViews, OperationalView, etc. can't be Viewpoints. So what is a Viewpoint?

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11372: Section: 8.3.23 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Description says there is a CustomView along with all the other Viewpoints, but it doesn't exist:
"The ArchitectureView is an abstract concept that groups the following kinds of views: o All View o Operational View o System View o Technical Standards View o Acquisition View o Strategic View o Custom View "

"An ArchitectureView is a ConformingElement and thus can be related to Standards. " 
However, it extends Package, and ConformingElement extends class, so it can't be a ConformingElement.

"In some cases, it is desirable to assemble elements of the model and export them for processing by an external process; perhaps to produce custom presentations or to transform them into different forms. Using the UPDMAttributes, an external URI can be designated as the processing element, and the components within the View can be assembled as needed to complement the external process. " 
"UPDMAttributes" should be "ExternalReferences"

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11373: Section: 8.3.21 Strategic Mission and 8.3.24 Vision (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Vision should be related to StrategicMission  (BMM)

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11374: Section: 8.4.2.7 ActivityRealization (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Diagram 8.39 should be in section 8.4.2.3

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11375: Section: 8.4.2.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that one end of the associaiton is an Activity, either an OperationalActivity or a SystemFunciton and the other is an OperationalActivityRealization if the first end is an OperatinalActivity and an OpertionalCapabilityRealization if the first end is a SystemFunction
OpertionalCapabilityRealization is misspelled

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11376: Section: 8.3.2 Figure 8.14 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Fig  8.14  diagram shows AllView - all the names should be AllViews

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11377: Section: 8.5.16.6 Constratints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that a ResourceCapability association exists between a Resource and the Capabilities that it provides and that these are the elements associated with this association
(self.endType-> at(1).owner.getAppliedStereotype('UPDM::Capability')-> notEmpty() and
self.endType-> at(2).owner.getAppliedStereotype('UPDM::Resource')-> notEmpty()or
self.base_Association.endType-> at(2).getAppliedStereotypes()->collect(allParents())-> any(qualifiedName = 'UPDM::Resource') ->notEmpty() ) or
(self.endType-> at(2).owner.getAppliedStereotype('UPDM::Capability')-> notEmpty() and
self.endType-> at(1).owner.getAppliedStereotype('UPDM::Resource')-> notEmpty()or
self.base_Association.endType-> at(1).getAppliedStereotypes()->collect(allParents())-> any(qualifiedName = 'UPDM::Resource') ->notEmpty())

Don't need .'baseAssociation'clause

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11378: Section: 8.3.4.4 Attributes (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

 ArchitectureView::variation is missing description

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11379: Section: 8.3.4.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that Concerns is not empty 
self.concerns-> forAll(getAppliedStereotype('UPDM::Concern')->notEmpty()) 
Rule only checks for ArchitectureView, should check for all of the specializations of ArchitectureView.
Should be:
self.client->forAll(getAppliedStereotype('UPDM::ArchitectureView')->notEmpty() or
getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::ArchitectureView') ->notEmpty()) and
self.supplier->forAll(getAppliedStereotype('UPDM::Viewpoint')->notEmpty())

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11380: Section: 8.3.4.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[7] Asserts that the element has at least one Standard associated with it. 
self.standards->forAll(getAppliedStereotype('UPDM::Standard')->notEmpty()) 
Standard multiplicity relationship to Architecture view should be *, not 1.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11381: Section: 8.3.4.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that Concerns is not empty self.concerns-> forAll(getAppliedStereotype('UPDM::Concern')->notEmpty() 

Concern  multiplicity relationship to Architecture view should be *, not 1.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11382: Section: 8.4.13. Constraints - OperationalActivity (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1]
In an OperationalActivity  if a callBeahviorAction that references a stereotyped OperationalActivity but  is NOT contained in a partition that meets the OwnedBehavior_rule constraint, then the constraint fails. It should be valid if the context of the activity referenced in the call behavior action is owned by the context of the OperationalActivity  that owns the call behavior action.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11383: Section: 8.6.36.6 Constraint (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[5]
In an SystemFunction, if a callBeahviorAction that references a stereotyped SystemFunctionbut  is NOT contained in a partition that meets the OwnedBehavior_rule constraint, then the constraint fails. It should be valid if the context of the activity referenced in the call behavior action is owned by the context of theSystemFunction that owns the call behavior action.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11384: Section: 8.4.13.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[4] Asserts that an OperationalActivity must be owned by an OperationalNode, one of its specializations or an OperationalCapabilityRealization.

let x:uml::Class = self.owner.oclAsType(uml::Class) in
x.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty() or
x.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
x.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty()

Don't need : 
x.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty() or

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11385: Section: 8.4.20.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1]   Asserts that the owner of the OperationalEventTrace is either an OperationalNode or an OperationalCapabilityRealization.
self.owner.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
self.owner.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or
self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()

Don't need : 
Or self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11386: Section: 8.4.28.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that this StateMachine is owned either by an OperationalNode or an OperationalCapabilityRealization
self.owner.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or
self.owner.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or
self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()

Don't need : 
self.owner.getAppliedStereotype('UPDM::OperationalCapabilityRealization') ->notEmpty()

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11387: Section: 8.4.29.7 Semantics (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

sematics statement uses terms from am earlier submission - e.g. OrganizationalRole

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11388: Section: 8.4.44.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that there are zero or more Competencies provided by the Resource and that zero or more Resources provide a Competence and that these are the elements associated by this association
(self.endType-> at(1).getAppliedStereotype('UPDM::Competence')-> notEmpty() and
self.endType-> at(2).getAppliedStereotype('UPDM::Resource')-> notEmpty() or
self.base_Association.endType-> at(2).getAppliedStereotypes()-> collect(allParents())-> any(qualifiedName = 'UPDM::Resource') ->notEmpty() 
) or
(self.endType-> at(2).getAppliedStereotype('UPDM::Competence')-> notEmpty() and
self.endType-> at(1).getAppliedStereotype('UPDM::Resource')-> notEmpty() or
self.base_Association.endType-> at(1).getAppliedStereotypes()-> collect(allParents())-> any(qualifiedName = 'UPDM::Resource') ->notEmpty() )

Don't need 'baseAssociation' clause

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11389: Section: 8.6.33.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] [1] If a Needline exists between two OperationalNodes, then there must exist a SystemsNode that hosts each of the OperationalNodes and a SystemInterface must exist between them.
This OCL only checks for the existence of a SystemInterface it says nothing about the Needline and the Systems nodes.
The systemsNodes would have to have Systems that are connected by the System Interface, and the SystemInterfaceImplementsNeedline association to associate the Needline and the SystemInterface. The constraint as described in [1] would have to be on SystemsNode, not on an individual  system. This constraint may be OK for :"There must be at least one SystemInterface defined on a System".
self.getAllAttributes()->asOrderedSet()->
select(association->notEmpty()).association->any
 (getAppliedStereotype('UPDM::SystemInterface')-> notEmpty())->notEmpty()

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11390: Section: 8.6.33.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

MISSING Documentation, and thus missing a constraint number. [2] inserted and the rest incremented
[2] "Asserts that there is an association between a System and SystemSoftware."
self.getAllAttributes().association -> 
any (getAppliedStereotype('UPDM::SystemSystemSoftware')->notEmpty())->notEmpty()

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11391: Section: 4.6.50.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that this SystemState models the behavior of a System, one of its specializations or  an OperationalActivityRealization
self.owner.getAppliedStereotype('UPDM::OperationalActivityRealization')->notEmpty() or
self.owner.getAppliedStereotype('UPDM::System')->notEmpty() or
self.owner.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::System') ->notEmpty())

Don't need self.owner.getAppliedStereotype('UPDM::OperationalActivityRealization')->notEmpty() or

Resolution:
Revised Text:
Actions taken:
September 13, 2007: reeived issue

Issue 11392: Section: 8.6.10 DataElementSystemFunction (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

This association refers to SystemFunction but should refer to System and SystemFunctionSpecification. However, it also appears that this stereotyped association and its constraints is not necessary. If it is, then OperationalNode and OperatoinalNodeSpecification should have an "InformationElementOperationalNode" association.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11393: Section: 8.6.48.6 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

[1] Asserts that the SystemsNodes are required to be deployed to zero or more Locations, have OrganizationalResources, HardwareItems, SoftwareItems, Networks, SystemGroup,or Systems deployed on them, and house OperationalNodes; and that these are the elements associated with this SystemsNode. 
let e1:uml::Class = self.oclAsType(uml::Association).endType-> at(1).oclAsType(uml::Class) in let e2:uml::Class = self.oclAsType(uml::Association).endType-> at(2).oclAsType(uml::Class) in 
(e1.getAppliedStereotype('UPDM::SystemsNode')->notEmpty() and (e2.getAppliedStereotype('UPDM::System')->notEmpty() or e2.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::System') ->notEmpty() or e2.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or e2.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or e2.getAppliedStereotype('UPDM::Location')->notEmpty() or e2.getAppliedStereotype('UPDM::OrganizationalResource')->notEmpty()or
e2.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OrganizationalResource') ->notEmpty() or
e2.getAppliedStereotype('UPDM::SystemGroup)->notEmpty())
)<<<Note - I think this is an extra parenthesis here>>>
 
or (e2.getAppliedStereotype('UPDM::SystemsNode')->notEmpty() and (e1.getAppliedStereotype('UPDM::System')->notEmpty() or e1.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::System') ->notEmpty() or e1.getAppliedStereotype('UPDM::OperationalNode')->notEmpty() or e1.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OperationalNode') ->notEmpty() or e1.getAppliedStereotype('UPDM::Location')->notEmpty() or e1.getAppliedStereotype('UPDM::OrganizationalResource')->notEmpty() or
e1.getAppliedStereotypes()->collect(allParents())->any(qualifiedName = 'UPDM::OrganizationalResource') ->notEmpty() or
e1.getAppliedStereotype('UPDM::SystemGroup')->notEmpty())

SystemsNodeElements should use Resource instead of OrganizationalResource  so that SystemsNodes can be nested.

SystemsNodeElements should include SystemGroup so that we can include whole configurations.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11394: Section: 8.5.2 Capability and 8.3.21 StrategicMission (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

Capability and StrategicMission should have an association between them  (BMM, where Capability is mapped to Strategy of BMM)

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11395: Section: 8.3.13 Goal (updm-ftf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes.
Since Mission is associated with Vision and vision with Goal, then we can follow the association to Objective to obtain the objectives of the mission. (BMM).

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11396: Section: 8.3.14 PerformanceMeasureSet (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

PerformanceMeasureSet should be PerformanceMeasurementSet

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11397: Section: 8.3.14.5 Associations (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

conformingelement : ConformingElement [1] 
multiplicity is wrong - should be [1..*]

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11398: Section: 8.3.15.5 Associations (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

conformingelement : ConformingElement [1] 
multiplicity is wrong - should be [1..*]

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11399: Section: 8.3.15.7 Semantics (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Revision
Severity: Significant
Summary:

We need a usage statement like this:
Usage: Create a class and stereotype if <<PerformanceParameterSet>>. This Class will be associated with the Conforming Elements to which its instances apply.
Create attributes that specify the performance measurements that are to be performed
Create an instance of a the PerformanceParameterSet, and stereotype it <<PerformanceMeasurementSet>> this measurement set will have a PerformanceMeasurementPeriod that is one of Baseline, Target Actual.
Provide the slot values for each of the attributes specified in the PerformanceParamenter set for this performance period.
Do the same for the other two performance periods
Set the conformingElement property to the corresponding element to which the PerformanceParameterSet applies, and set the performanceMeasurements property in the element.

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11419: Section 7.3, 8.1 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"UPDM Class Library" or "Class Library". Both names are in the diagrams

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Discussion:

Issue 11420: Extensions section should not be empty,ie section 8.2.2.1 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Even is the stereotype generalizes other stereotype, its Extensions section should not be empty, since extension is inherited. Currently the spec if very hard to read.

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Discussion:

Extensions section should not be empty

Issue 11421: Association end names should be on the diagrams (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Association end names should be on the diagrams

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11422: Section 9.3.7 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

TimeInterval datatype conflicts with UML metaclass TimeInterval.

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11423: Section 8.2.9 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

MilestonePoint is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11424: Section 8.2.10.3 Diagram (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Diagram is too small

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11425: Section 8.3.4.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Dependency "Conform" has no sematic meaning between stereotype and confuses reader.

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11426: Section 8.3.8.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are 2 associations between Concern and stakeholder

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11427: Section 8.3.8.3 StakeholderConcern (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

StakeholderConcern is duplicated by association between steretype

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11428: Section 8.3.9 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Possible conflict between Conform stereotype in SysML and UPDM

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11429: Section 8.3.14.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"A PerformanceMeasurementrSet includes a set of PerformanceMeasures for each PerformanceMeasurePeriod. The set is applied to ConformingElements. (See UPDM Class Library). This stereotype is applied to instances of classes stereotyped PerformanceParameterSet.
ConformingElements are not part of UPDM Class Library anymore"

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11430: Section 8.3.15.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"This Stereotype is applied to the PerformanceMeasurementSet in the UPDM ClassLibrary.
PerformanceMeasurementSet is not part of UPDM Class Library"

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11431: Section 8.3.16.9 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Possible conflict between Requirement stereotype in SysML and UPDM

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11432: Section 8.3.16.9 Wrong chapter number for requirements (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Wrong chapter number for requirements

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11433: Section 8.3.17.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ResourceCapability is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11434: Section 8.3.17.3 ResourceCompetence (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ResourceCompetence is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11435: Section 8.3.17.3 OperationalCapabilityRoleResource (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalCapabilityRoleResource is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11436: Section 8.3.17.3 ResourceCapabilityConfiguration (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ResourceCapabilityConfiguration is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11437: Section 8.3.18.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"Specification is the ancestor of all the stereotypes that extend Instance Specification. It implements the common attribute, description.
Attribute is missing"

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11438: Section 8.3.24.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Association between Vision and Enterprise is duplicated by UML ownership

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11439: Section 8.4.2 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityRelazation could be potentially implemented as ownedBehavior

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11440: Section 8.4.5.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalCapabilityRoleCompetence is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11441: Section 8.4.8.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Associations between InformationExchange and Needline/SystemInterface are navigable to one direction only, so you cannot "reach" SystemInterface/Needline from InformationExchange. Is this done deliberately?

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11442: Figure 8.46 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Lot of "MaterieBehavior". Typo

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11443: Figure 8.46 MaterielBehavior (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

MaterielBehavior is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11444: Figure 8.50 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityRealization is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11445: Figure 8.51 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CapabilityOperationalCapability is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11446: Figure 8.51 CapabilityRequirementCapability (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CapabilityRequirementCapability is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11447: Figure 8.52 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Realization between stereotypes has no semantic meaning

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11448: Section 8.4.45.6 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"NodeCasuseEffect.
Typo"

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11449: Figure 8.59 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Needline is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11450: Section 8.4.22.5 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Two "effect" association end for OperationalNode

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11451: Section 8.4.38.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OV6 talks about 3 variations (a, b, and c) in the description, but this is information does not appear in the model

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11452: Section 8.4.31.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

DoDAF spec says about command, control, coordination, etc organizational relationships. UPDM says about solid and dotted. It is incorrent to have graphical difference as data type.

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11453: Figure 8 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

DeliveredCapability is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11454: Figure 8.59 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalNodeCapabilityRequirement is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11455: Figure 8.94 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

EffectAffectsNode is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11456: Figure 8.94 OperationalCapabilityEffect (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalCapabilityEffect is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11457: Extremely long stereotype names for associations will distort diagrams (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Extremely long stereotype names for associations will distort diagrams. For example OperationalNodeCapabilityRequirement

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11458: Section 8.6.2 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CommPathFromTo stereotype for association will look weird on the diagram

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11459: Figure 8.113 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CommPathFromTo is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11460: Figure 8.113: Realization between stereotypes has no semantic meaning (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Realization between stereotypes has no semantic meaning

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11461: Section 8.6.10 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

What is the preffered way for visualizing some of the stereotyped associations, for example, DataElementSystemFunction, where connected elements are from different products

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11462: Fig. 8.120 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Why DataExchange cannot access DataElements in carries?

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11463: Fig. 8.121 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

GroupForecast is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11464: Figure 8.124 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

NetworkPaths is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11465: Section 8.6.16 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Why it is NetworkPaths, not NetworkPath

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11466: Figure 8.126 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Relation between OperationalActivityRealization and System should be generalization, not extension

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11467: Section 8.6.30.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SV10 talks about 3 variations (a, b, and c) in the description, but this is information does not appear in the model

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11468: Figure 8.142 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Realization between stereotypes has no semantic meaning

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11469: Figure 8.142 SystemSystemSoftware (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemSystemSoftware is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11470: Figure 8.142 SystemGroupMember (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemGroupMember is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11471: Fig. 8.142: System cannot be decomposed from other systems (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

System cannot be decomposed from other systems

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11472: Figure 8.151 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Dependency between stereotypes has no semantic meaning

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11473: Figure 8.156 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemNodeElements is duplicated by association between stereotypes

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11474: Section 8.6.54 Trigger stereotype conflicts with UML metaclass (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Trigger stereotype conflicts with UML metaclass

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11475: Sections 8.6.53 and 8.1 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemView or Systems View

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11476: Section 8.7.4.4 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Having service and serviceArea as String properties for Standard prohibits of usage DISR ar model library

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11477: Section 8.3.22.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

There can be a confusion between ExternalReferences and ExternalReference

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11478: Table 9.2: Table of enumeration literals contains duplicates (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Table of enumeration literals contains duplicates

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11479: Sections 9.2.2 and 8.2.7 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

DLOD elements appears as stereotype and as Class in the Class Library

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11480: Figure 8.163 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Why SystemTask - Trigger association is navigable to one way only, and OperationalTask - trigger is navigable both ways?

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11481: Figures 8.23 and 8.161 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Doctrine-SystemTask association contains different multiplicities on different diagrams

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11482: Section 8.6.43 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

It will be hard to visualize SystemInterfaceImplementsNeedline because it is a dependency between relationships

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11483: Section 8.4.28.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalStateTrace description - "This is the state machine for OV-5."

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11484: Section 8..4.22.4 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Decomposition level for OperationalNode should be a derived property

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11485: time/date related attributes (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Some time/date related attributes are Strings, some TimeInterval. It could be unified

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11486: CompetenceRelationship (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Is it OK to have "Relationship" in the stereotype name? This is not common UML practice. Chapter 8.4.6

Resolution:
Revised Text:
Actions taken:
September 19, 2007: received issue

Issue 11487: OrganizationalRelationship (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Is it OK to have "Relationship" in the stereotype name? This is not common UML practice. Chapter 8.4.31

Resolution:
Revised Text:
Actions taken:
September 19, 2007: received issue

Issue 11531: InterfaceRealization (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

InterfaceRealization should be the metaclass for RealizedSystemSpecification., 8.6.18

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11532: SystemActivityFunction is used in examples., p. 398 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemActivityFunction is used in examples., p. 398

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11533: SystemTask should have SystemFunction as method property? (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemTask should have SystemFunction as method property? Not clear from a description, 8.6.52

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11534: System description should talk about linking to the SystemFunctions (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

System description should talk about linking to the SystemFunctions - via System Tasks, 8.6.33

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11535: Section 8.6.33.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"A System can be expressed in UML using a variety of
constructs, for example, a component or a class.". Stereotype <<System>> can be assigned only to the Class., 8.6.33.3

Resolution:
Revised Text:
Actions taken:
September 23, 2007: rceived issue

Issue 11536: Section 8.6.11 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is not described how DataExchange is related to SystemInterface and DataElement, 8.6.11

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11537: Why do you need a SystemPort if it does not add any new information, 8.6.44 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Why do you need a SystemPort if it does not add any new information, 8.6.44

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11538: Section 8.6.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no way to provide type (tcp/ip, wireless, etc) for CommunicationLink, 8.6.3

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11539: How can you show the CommunicationPathRealizesSystemInterface?, (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

How can you show the CommunicationPathRealizesSystemInterface?,

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11540: Section 8.6.4 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Network is a collection of Systems and CommunicationLinks, why explicitly define the collection of CommunicationPaths, 8.6.4

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11541: Section 8.6.5 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"CommunicationPath is realized by a CommunicationsSystem". In order to get a sequence of Systems that compose a CommunicationPath we need to use supplierDependency collection. But it is not navigable and not ordered., 8.6.5

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11542: Section 8.6.4.5 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CommunicationPath must have a Network assigned. There might be no Networks, 8.6.4.5

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11543: Section 8.6.15.3 (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

"A Network is a collection of one or more CommunicationPaths. It may contain multiple CommunicationPaths between
the same pair of Systems. This is typically realized by the Network owning a set of CommunicationPaths." This is not completely true. A network is a System, so it can be composed from other Systems, 8.6.15.3

Resolution:
Revised Text:
Actions taken:
September 23, 2007: received issue

Issue 11556: Section 8.6.15 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

According to DoDAF specification, a Network is "A collection of communications links (and systems nodes and
systems where applicable)". Current implementation imply that  Systems and SystemsNodes are not a part of Network, 8.6.15

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11557: Section 8.6.48 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemNodeElements is duplicated by regular UML composite structures, 8.6.48

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11558: Section 8.6.4 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

According to DoDAF spec, CommunicationLink is "A communications link connects systems nodes or systems
(including communications systems)". A CommunicationsPath is "A series of communications links that support an interface (from
SV-1)". That means that Systems and SystemsNodes may be included in CommunicationsPath. Right now, only CommunicationsSystems are allowed., 8.6.4

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11559: Section 8.6.10 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

DataElementSystemFunction is not needed, since you can tie SystemFunction and DataElements via activity (SystemFunction) parameters, 8.6.10

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11560: Section 8.6.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

According to DoDAF spec CommunicationLink is "A communications link connects systems nodes or systems
(including communications systems)". Now only Systems are allowed., 8.6.3

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11561: Section 8.6.18.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Description for RealizedSystemSpecification states: "Specifies that a System or one of its sub stereotypes realizes an interface stereotyped SystemFunctionSpecification or one
of its sub stereotypes." However, there are no sub stereotypes, 8.6.18.3

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11562: Fig. 8.142 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalActivityRealization, SystemServiceConsumer, SystemServiceProvider should be displayed as System sub stereotype.,

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11563: Section 8.4.2 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityRealization should be moved to AllViews package from OperationalView, since it talks about both SystemFunctions and OperationalActivities,

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11564: inconsistencies (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Some "realizations" are relationships - ActivityRealization, some - objects - OperationalActivityRealization. Seems to be inconsistent and misleading.,

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11565: Section 8.4.2 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ActivityRealization is Association, while CommunicationPathRealization is a Realization. Seems to be inconsistent., 8.4.2.

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11566: MaterielBehavior is not needed - Section 8.4.10 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

MaterielBehavior is not needed. OwnedBehavior property for BehavioredClassifier could be reused for linking Materiel and behaviors., 8.4.10

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11567: Section 8.4.46 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

DoDAF spec specifies these Rule types: "One of: Structural Assertion, Action Assertion, Derivation". It is lost in the UPDM., 8.4.46

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11568: Section 8.4.47 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

TaskInvocation is listed in OperationalView packages, however belongs to both Operational and Systems Views., 8.4.47

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11569: Section 8.3.14.6 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

There should be a constraint defining that a Classifier for a PerformanceMeasurementSet should be PerformanceParameterSet, 8.3.14.6

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11570: Section 8.3.16.6 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

There should be a constraint defining that an Owner of PerformanceParameterType should be stereotyped PerformanceParameterSet, 8.3.16.6

Resolution:
Revised Text:
Actions taken:
October 9, 2007: received issue

Issue 11571: Fig. 8.27 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Diagram for PerformanceParameterSet does not show the association to the ConformingElement.,

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Discussion:

Issue 11572: Section 8.3.10.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Conforming element description: "ConformingElement provides a link from profile elements to specific standards in the context of a forecast." It is not just forecast, but performance measurement as well, 8.3.10.3

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11573: Section 8.3.10 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemFunction, SystemInterface, CommunicationLink, DataExchange cannot be measured as stated in DoDAF spec: 
"SV-7 builds on SV-1, SV-2, SV-4, and SV-6 by
specifying performance parameters for systems and system hardware/software items and their
interfaces (defined in SV-1), communications details (defined in SV-2), their functions (defined
in SV-4), and their system data exchanges (defined in SV-6).", 8.3.10

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue

Issue 11574: CommunicationsLink/Path/System vs CommunicationLink/Path/System (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CommunicationsLink/Path/System vs CommunicationLink/Path/System. What is the correct name?,

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11575: Section 8.4.8.6 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OCL constraint is missing for the InformationExchange, constraining that realization should be "Needline" (Association), 8.4.8.6

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11576: Section 8.6.11.6 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OCL constraint is missing for the DataExchange, constraining that realization should be "Needline" (Association), 8.6.11.6

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11577: Section 8.3.23 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Name conflict with SysML::Viewpoint,

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11578: Possible conflict between Viewpoint/Stakeholder/Concern in UPDM and SysML (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Possible conflict between Viewpoint/Stakeholder/Concern in UPDM and SysML. Stakeholder and Concern are String types properties in SysML and they are first class constructs in UPDM

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11579: Section 8.5.6 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CapabilityOperationalCapability could be replaced by UML metaproperty useCase., 8.5.6

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11580: Section 8.4.41 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Policy is too restrictive about linked element. Any element should be able to satisfy Policy, 8.4.41

Resolution:
Revised Text:
Actions taken:
October 10, 2007: received issue

Issue 11581: Section 8.3.11 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Doctrine is too restrictive about linked element. Any element should be able to satisfy Doctrine, 8.3.11

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11582: Section 8.7.3 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Standard is too restrictive about linked element. Any element should be able to satisfy Standard, 8.7.3

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11583: Section 8.7.3 Association between Standard and ConformingElement (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Association between Standard and ConformingElement should be navigable in one direction only. Standard should not be changed if Elements is applied to it., 8.7.3

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11584: Goal, Policy, Standard and Doctrine (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Goal, Policy, Standard and Doctrine should be connected to elements using a stereotyped dependency. This gains SysML compliance, makes integration with Requirements tools easier. It would create atleast one new steretyped dependency similar to <<Satisfy>>.,

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11585: Fig. 8.31 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Diagram contains element that are not in the model - PerformanceMeasure and PerformanceMeasurementSet,

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11586: Section 8.4.23 - Why OperationalNodePort is needed (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Why OperationalNodePort is needed?, 8.4.23

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11587: Section 8.4.32.9 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OrganizationalRole has bad chapter number, 8.4.32.9

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11588: Section 8.5.10 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Effect could be a regular Activity instead of OpaqueBehavior, which is "A behavior with implementation-specific semantics.",

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11589: UML composite structure should be reused (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

NetworkPaths, SystemSystemSoftware, SystemNodeElements should be removed and UML composite structure should be reused

Resolution:
Revised Text:
Actions taken:
September 28, 2007: received issue

Discussion:

Issue 11590: Section 8.4.44 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Description for ResourceCompetence does not explain the difference from CompetenceRelationship. It should be reworked

Resolution:
Revised Text:
Actions taken:
September 28, 2007: received issue

Issue 11594: Technologies should be first class objects (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SV-9 talks about forecasted technologies, their impact to the systems, forecast covering services and service areas. In order to facilitate reusability Technologies should be first class objects.

Resolution:
Revised Text:
Actions taken:
October 4, 2007: received issue

Issue 11595: Section 8.5.4 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CapabilityConfigurationCapabilities is plural, while other stereotyped associations are not

Resolution:
Revised Text:
Actions taken:
October 4, 2007: received issue

Issue 11596: Section 8.5.5 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Why do you need CapabilityDependency. Regular Dependency could be used

Resolution:
Revised Text:
Actions taken:
October 4, 2007: received issue

Issue 11597: Section 8.4.13 (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no level identifier property for OperationalActivity

Resolution:
Revised Text:
Actions taken:
October 4, 2047: received issue

Issue 11598: Qualified name in the OCL constraints should be full (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Qualified name in the OCL constraints should be full, not just "UPDM::StereotypeName"

Resolution:
Revised Text:
Actions taken:
October 4, 2007: received issue

Issue 11606: Figure 3-3: AcV-2 View Example (updm-ftf)

Click here for this issue's archive.
Source: Software Centre of Excellence, Rolls-Royce Div. (Mr. Francis Thom, Fran.Thom(at)BTInternet.com)
Nature: Revision
Severity: Minor
Summary:

This is not an example of an AcV-2 View See www.modaf.com for an
example

Resolution:
Revised Text:
Actions taken:
October 11, 2007: received issue

Issue 11607: Section 5.2.1 (updm-ftf)

DLODIssues Type should be an enumerated list of 'issues' (as opposed to
colours) and should list 'None Outstanding', 'Manageable', 'Critical',
'Unknown' and 'Not Required'.

Resolution:
Revised Text:
Actions taken:
October 11, 2007: received issue

Issue 11608: Section 4.3.3.3 (updm-ftf)

This description needs to be brought in-line with the description in
section 4.3.4.3

Resolution:
Revised Text:
Actions taken:
October 11, 2007: received issue

Issue 11609: Section 4.3.4.3 (updm-ftf)

If a Concern is modelled as a stereotyped dependency (client being
Stakeholder and supplier being ArchitectureView) then the notion of
Stakeholders having concerns which are addressed by the ArchitectureView
has been resolved.

Resolution:
Revised Text:
Actions taken:
October 11, 2007: received issue

Discussion:

Issue 11610: Section 4.3.4.5 (updm-ftf)

Reword (part of the description for a Viewpoint appears under the
description of the association for a Stakeholder).

Resolution:
Revised Text:
Actions taken:
October 11, 2007: received issue

Issue 11611: Section 4.3.4.6 (updm-ftf)

Click here for this issue's archive.
Source: Software Centre of Excellence, Rolls-Royce Div. (Mr. Francis Thom, Fran.Thom(at)BTInternet.com)
Nature: Clarification
Severity: Minor
Summary:

An ArchitectureView may not conform to a Standard e.g. if the purpose of
the ArchitectureDescription is to elaborate a new standard (e.g.
concepts of operation). 'Conform' may need expanding and Constraint [6]
may be too strict?

Resolution:
Revised Text:
Actions taken:
October 11, 2007: received issue

Issue 11635: getAppliedStereotype OCL construct does not exist (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

getAppliedStereotype OCL construct does not exist

Resolution:
Revised Text:
Actions taken:
October 30, 2007: received issue

Issue 11636: View/Viewpoint should be imported from SysML, not redefined (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

View/Viewpoint should be imported from SysML, not redefined

Resolution:
Revised Text:
Actions taken:
October 30, 2007: received issue

Issue 11637: System stereotype is lost if the instance of System class is created (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

System stereotype is lost if the instance of System class is created

Resolution:
Revised Text:
Actions taken:
October 30, 2007: received issue

Issue 11639: Why TechnicalStandardsProfile is a ConformingElement. (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ConformingElement is used for applying standards or performing measurements. TechnicalStandardsProfile should be just grouping Standards, so it does not need to extend ConformingElement

Resolution:
Revised Text:
Actions taken:
November 4, 2007: received issue

Issue 11640: TechnicalStandardsProfile should extend a Package (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

TechnicalStandardsProfile should extend a Package, so UML ownership could be reused for grouping Standards

Resolution:
Revised Text:
Actions taken:
November 4, 2007: received issue

Issue 11641: PerformanceMeasurePeriod or PerformanceMeasurementPeriod (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

PerformanceMeasurePeriod or PerformanceMeasurementPeriod. Both are used. Name PerformanceMeasurementPeriod should be used. 8.4.51

Resolution:
Revised Text:
Actions taken:
November 4, 2007: received issue

Issue 11642: PerformanceMeasurePeriod is in OperationalView package (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

PerformanceMeasurePeriod is in OperationalView package. It should be moved to AllViews. 8.4.51

Resolution:
Revised Text:
Actions taken:
November 4, 2007: received issue

Issue 11643: Rule is in the OperationalView package (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Rule is in the OperationalView package. Since there is no specific Rule for SystemView, Rule should be moved to AllViews. 8.4.46

Resolution:
Revised Text:
Actions taken:
November 4, 2007: received issue

Issue 11684: Page: Page 3 (PDF page 17) (updm-ftf)

Click here for this issue's archive.
Source: Object Management Group (Mr. Andrew Watson, andrew(at)omg.org)
Nature: Revision
Severity: Minor
Summary:

Chapter 1, paragraph 1, line 3 "Ministry of Defense" should be "Ministry of Defence" (note UK spelling of "Defence" in the name of the UK ministry concerned). I checked, and as far as I can tell all other instances of "Ministry of Defense" are correctly spelled.

Resolution:
Revised Text:
Actions taken:
October 26, 2007: received issue

Issue 11740: 8.6.48:SystemsNodeElements (01) (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

SystemsNodeElements should use Resource instead of OrganizationalResource.  SO that SystemsNodes can be nested.

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11741: 8.6.48:SystemsNodeElements (02) (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

SystemsNodeElements should include SystemGroup so that we can include whole configurations.

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11742: 8.6.48:SystemsNodeElements (03) (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

We need an Objective stereotype associated with Goal. The Objective will include timeboxed and quantitative attributes.

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11743: 8.4.13.3:OperationalActivity (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

In the description of an Operational Activity, the subsection called ProxyActivity is confusing. Proposed wording:
Resolution:Proposed wording- A context-free OperationalActivity is defined with no specific context. The OperationalNode that wants to perform that context-free activity defines its own OperationalActivity that will act as a proxy for the context-free one. This proxy OperationalActivity (ProxyActivity) contains at least a callBehaviorAction referring to the context-free OperationalActivity. Optionally, an OperationalTask can be defined on the OperationlNode and the Specification attribute of that ProxyActivity can be set to that OperationalTask. Typically, the OperationalNode that defined the proxy has another OperationalActivity which uses the context-free OperationalActivity by specifying that the ProxyActivity is performed at that OperationalNode. The proxy is referenced using either a callBehaviorAction or a callOperationAction if the OperationalTask was defined for the proxy.
Using this proxy pattern, multiple Operational Nodes can effectively perform the same context-free OperationalActivity. Instead of defining an OperationalTask on every OperationalNode that defines a proxy for the context-free OperationalActivity, create an OperationalNodeSpecification with an OperationalTask that corresponds to the context-free OperationalActivity. When an OperationalNode defines a ProxyActivity, it sets the Specification attribute on the proxy to the OperationalTask owned by the OperationalNodeSpecification and then the OperationalNode implements (realizes) the OperationalNodeSpecification. Using this pattern, it is easy to determine every OperationalNode that performs that context-free (common) OperationalActivity simply by examining the Method attribute of the corresponding OperationalTask, defined on the OperationalNodeSpecification, which will be a collection of the ProxyActivities.

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11744: 8.4.22:OperationalNode (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

CapabilityRequirement_rule 
The constraint documentation is: 
[4] Asserts that this Node is required for delivery of an Operational Capability.
The OCL for the constraint is:

self.getAllAttributes()->asOrderedSet()->select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::OperationalNodeCapability')-> notEmpty())->notEmpty()

There is no stereotype in UPDM called OperationalNodeCapability. I think it should be OperationalNodeCapabilityRequirement.
And if so, does the textual description make sense?
Resolution: 
Revised Text:[4] Asserts that this Node is required for delivery of a CapabilityRequirement.

self.getAllAttributes()->asOrderedSet()->select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::OperationalNodeCapabilityRequirement)-> notEmpty())->notEmpty()

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11745: 8.4.29:OperationalTask (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalTask::Method_rule
This constraint ensures that if the "method" attribute of an Operational Task (operation) is defined, it must be either an OperationalActivity, OperationalStateTrace or OperationalEventTrace. The OCL that checks for an OperationalEventTrace casts the behavior to a "uml::StateMachine" but it should be a "uml::Interaction".

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11746: 8.6.52:SystemTask (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

SystemTask-Method_rule 
This constraint is supposed to ensure that if the "method" attribute of a System Task (operation) is defined, it must be either a SystemFunction, SystemStateTrace or SystemEventTrace. Two problems: (1) the stereotype references correspond to the operational equivalents and (2) the OCL that should check for an SystemEventTrace casts the behavior to a "uml::StateMachine" but it should be a "uml::Interaction".

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11747: 8.4.13.6:OperationalActivity Constratins (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

:[2] Asserts that for every callOperationAction in an OperationalActivity that refers to an Operation that is stereotyped OperationalTask, then: 
if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNode or a Property that is typed by an OperationalNode or one of its specializations, then o
 the OperationalTask must be owned by that OperationalNode and the OperationalTask must have at least one method that specifies a corresponding OperationalActivity owned by the OperationalNode, (an OperationalTask could also specify Interactions or StateTraces) 
OR o
 if the OperationalTask that is the operation of a callOperationAction that resides in a partition that represents an OperationalNodeSpecification or a Property that is typed by an OperationalNodeSpecification, then o
 the OperationalNodeSpecification must own the OperationalTask. 

This constraint forces the called operation to be owned by the OperationalActivity that represents the partition in which the callOperationResides and that is not generally the case. 
Resolution:Fix the OCL.

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11748: 8.4.13.5:OperationalActivity Associations (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

materiel is listed as an Association, but the diagram does not indicate the association.
There isn't an association between OperationalActivity and Materiel, but there is a stereotypedAssociation, MaterielBehavior that is bidirectional, so there should be a dependency in the diagram as proposed for the solution for showing stereotyped associations

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11749: 8.2.8:Milestone (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

8.2.8.3 Description
Change MilestonePoint to <<StereotypedAssociation>> notation in the diagram
8.2.8.5
Remove all associations

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11750: 8.2.10:Project (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

Change Milestone and Capability associations to the stereotyped dependency notation

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11751: 8.2.10:Project -- 8.2.10.6 Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

[1] Asserts that there is one OrganizationalResource required for this Project

[1] Asserts that there is one or more OrganizationalResources that own this Project
Fix diagram to show 1 or more

[2] Asserts that zero or more Milestones govern this Project through an DOLDElement self.getAllAttributes()->asOrderedSet()-> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')-> notEmpty())->notEmpty() 


[2] Asserts that one or more Milestones govern this Project
 self.getAllAttributes()->asOrderedSet()-> select(association->notEmpty()).association->any (getAppliedStereotype('UPDM::MilestonePoint')-> notEmpty())->notEmpty()

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11752: 8.2.11:Project Type (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

This stereotype doesn't have much use as is. Either delete it, or make it more meaningful

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11753: 8.3.19:Stakeholder (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

8.3.19.3 Stakeholder Description
Fix diagram - remove association between concern and Stakeholder. This is handled by the subject/usecase association.
Change StakeholderConcern to dependency notation
8.3.19.3 Stakeholder Associations
delete concern[]
8.3.19.6 Stakeholder Constraints

[1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty()) 

[1] Asserts that there is at least one ArchitectureView associated with this Stakeholder self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
or self.architectureView->forAll(getAppliedStereotypes()-> collect(allParents())->any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11754: 8.3.8:Concern (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

[1] Asserts that this Concern links an ArchitecureView to a set of Stakeholders self.architectureView.getAppliedSubstereotypes(self.getApplicableStereotypes()- >any(qualifiedName='UPDM::ArchitectureView'))->notEmpty() 

[1] Asserts that this Concern links an ArchitecureView or one of its specializations to a set of Stakeholders self.architectureView-> forAll(getAppliedStereotype('UPDM::ArchitectureView')- >notEmpty())
or self.architectureView->forAll(getAppliedStereotypes()-> collect(allParents())->any(qualifiedName = 'UPDM::ArchitectureView') -> notEmpty() )  

[2] Asserts that there are zero or more Stakeholders who have this Concern 
self.stakeholders-> forAll(getAppliedStereotype('UPDM::Stakeholder')->notEmpty()) 

[2] Asserts that there are zero or more Stakeholders who have this Concern 
self.subject->

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11755: 8.4.32:OrganizationalResource (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

8.4.32.6 OrganizationalResource Constraints
Project has zero or more - not 1 or more.
[1] Asserts that there is at least one Project owned by this OrganizationalResource. self.projects.getAppliedStereotype('UPDM::Project')->notEmpty()  

[1] Asserts that there is zero or more Projects owned by this OrganizationalResource. 
Self.projects -> notEmpty() implies
self.projects.getAppliedStereotype('UPDM::Project')->notEmpty() 

[3] Asserts that there is an association between the OperationalNode and a SystemsNode that houses the OperationalNodes. self.getAllAttributes()->asOrderedSet()->select(association- >notEmpty()).association->any (getAppliedStereotype('UPDM::SystemsNodeElements')-> notEmpty())->notEmpty() 

[3] Asserts that there is an association between the OrganizationalResource and a SystemsNode that requires this resource. 
self.getAllAttributes()->asOrderedSet()->select(association- >notEmpty()).association->any (getAppliedStereotype('UPDM::SystemsNodeElements')-> notEmpty())->notEmpty() 

[3] should be deleted, this association is not a required resource.

8.4.32.7 OrganizationalResource Semantics
Use the DeployedToSystemsNode SystemsNodeElements association to indicate deployment of OrganizationalResource to a SystemsNode. 
Use the OperationalCapabilityRoleResource association to indicate an OrganizationalRole played by the OrganizationalResource. 
Use the OrganizationalResourceCapabilityConfiguration association to indicate inclusion in a CapabilityConfiguration 
Use the DeployedToSystemsNode association to indicate deployment of OrganizationalResource to a SystemsNode. 
Use the DeployedToSystemsNode association to indicate deployment of OrganizationalResource to a SystemsNode.

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11756: 8.3.11:Doctrine (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

Diagram should show an association to Operation instead of OpertionalTask and SystemTask. It should be named "tasks". The association has to be unidirectional with a multiplicity of zero or more.
 
8.3.11.6 Constraints
[1] Asserts that there are SystemTasks or OperationalTasks governed by this Doctrine self.tasks-> forAll(getAppliedStereotype('UPDM::OperationalTask')->notEmpty() or getAppliedStereotype('UPDM::SystemTask')->notEmpty()) 
[1] Asserts that there are zero or more SystemTasks or OperationalTasks governed by this Doctrine 
self.tasks->notEmpty() implies
 self.tasks->  forAll(getAppliedStereotype('UPDM::OperationalTask')
->notEmpty() or 
 getAppliedStereotype('UPDM::SystemTask')->notEmpty())

[3] Asserts that this Doctrine governs zero or more CapabilityConfigurations self.capabilityConfigurations-> forAll(getAppliedStereotype ('UPDM::CapabilityConfiguration')->notEmpty()) 

[3] Asserts that this Doctrine governs zero or more CapabilityConfigurations 
self.capabilityConfigurations->notEmpty() implies
self.capabilityConfigurations-> forAll(getAppliedStereotype ('UPDM::CapabilityConfiguration')->notEmpty())

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11757: 8.3.13:Goal (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

:8.3.13.3 Goal Description
Fix diagram to show 1 or more OperationalCapabilities and 1 or more Visions associated with the Goal.
8.3.13.3 Goal Associations
fix multiplicity in both associatione to be [1..*]

Resolution:
Revised Text:
Actions taken:
December 5, 2007: received issue

Issue 11758: ProjectType has a generalization link to Project. (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ProjectType has a generalization link to Project. This does not make any sense.

Resolution:
Revised Text:
Actions taken:
December 6, 2007: received issue

Issue 11759: TimedTechnologyForecast (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

DoDAF spec says that a TimedTechnologyForecast should be linked to exact system and exact standard. Current profile allows linking a Forecast to a SystemGroup and TechnicalStandardsProfile only. A Forecast could be a relationship, linking Systems (or other entities) with Technologies and Standards

Resolution:
Revised Text:
Actions taken:
December 6, 2007: received issue

Issue 11760: Reusable libraries cannot be created on order to model a SV-9. (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Technology does not exist in UPDM, so reusable libraries cannot be created on order to model a SV-9.

Resolution:
Revised Text:
Actions taken:
December 6, 2007: received issue

Issue 11761: MOD Agreement Issue (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity:
Summary:

This is the agreement we reached with MOD to converge UPDM and MODAF. 

MOD will migrate M3 to a formal Mx (name TBD) data model. This is part of MOD’s intent eventually to migrate to IDEAS 
MOD will define a standard XML format for exchanging data conforming to the Mx data model. 
MOD and UPDM will define a bi-directional algorithmic mapping between UPDM and Mx data model 
An additional UPDM compliance point will be defined by a tool’s ability to export and import data that is compliant to the standard Mx data model according to 3, 4 & 5. 
UPDM will add an optional, normative section that specifies 6. 
A UPDM tool that implements 7 enables a vendor to claim the ability to produce MODAF architectures

Resolution:
Revised Text:
Actions taken:
December 6, 2007: received issue

Issue 11782: Navigability for association (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Navigability for association between PerformanceMeasurementSet and ConformingElement.
Current navigability is wrong, same PerformanceMeasurementSet can be applied for only one ConformingElement. It should be 1..*.

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11784: Sterotype for Association name CapabilityConfigurationCapabilities (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name CapabilityConfigurationCapabilities is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11785: Sterotype for Association name EffectAffectsNode is not nice (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name EffectAffectsNode is not nice. Should be simplified to "affects"

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11786: Sterotype for Association name ForecastStandardsProfile (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name ForecastStandardsProfile is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11787: Sterotype for Association name MaterielNode is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name MaterielNode is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11788: Sterotype for Association name MaterielBehavior is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name MaterielBehavior is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11789: Sterotype for Association name MilestonePoint is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name MilestonePoint is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11790: Sterotype for Association name NodeCausesEffect is not nice (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name NodeCausesEffect is not nice. Should be simplified to "affects

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11791: Sterotype for Association name OperationalCapabilityEffect (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name OperationalCapabilityEffect is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11792: Sterotype for Association name OperationalCapabilityRoleCompetence (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name OperationalCapabilityRoleCompetence is not intuitive. Semantic meaning of the relation should be implied.

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11793: Sterotype for Association name OperationalCapabilityRoleResource (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name OperationalCapabilityRoleResource is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11794: Sterotype for Association name OperationalNodeCapabilityRequirement (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name OperationalNodeCapabilityRequirement is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11795: Sterotype for Association name OrganizationalResourceCapabilityConfiguratio (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name OrganizationalResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11796: Sterotype for Association name ResourceCapability is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name ResourceCapability is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11797: Sterotype for Association name ResourceCapabilityConfiguration (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name ResourceCapabilityConfiguration is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11798: Sterotype for Association name ResourceCompetence is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name ResourceCompetence is not intuitive. It is not clear if it is provided Competence or required

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11799: Sterotype for Association name SystemGroupMember is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name SystemGroupMember is not intuitive. Should be something like "groupedBy"

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11800: Sterotype for Association name SystemsNodeElements (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Sterotype for Association name SystemsNodeElements is plural and not intuitive. Should be something like "hostedOn"

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11801: Stereotype for dependency CompetenceRelationship is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Stereotype for dependency CompetenceRelationship is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11802: Stereotype for dependency AssetMapping is not intuitive (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Stereotype for dependency AssetMapping is not intuitive. Semantic meaning of the relation should be implied

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11803: Stereotype for realization RealizedOperationalCapability is too long (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Stereotype for realization RealizedOperationalCapability is too long

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11804: Stereotype for realization CommunicationsPathRealizesSystemInterface (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Stereotype for realization CommunicationsPathRealizesSystemInterface is too long

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11805: Stereotype for interface realization RealizedOperationalSpecification (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Stereotype for interface realization RealizedOperationalSpecification is too long

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11806: Stereotype for interface realization RealizedSystemSpecification (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Stereotype for interface realization RealizedSystemSpecification is too long

Resolution:
Revised Text:
Actions taken:
December 7, 2007: received issue

Issue 11808: Section: 8.5.3 Add stereotyped association between Milestone and Capability (updm-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Add stereotyped association between Milestone and Capability Configuration.

Resolution:
Revised Text:
Actions taken:
December 11, 2007: received issue

Issue 11809: What UPDM elements/constructs relate to the DLOD elements (updm-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

What UPDM elements/constructs relate to the DLOD elements. I think the first cut is: Training - competence (amplified by organization delivering competence) Equipment - material Logistics - ? Infrastructure - System Node Organization - Organizational Resource Doctrine/concepts - Doctrine Information - ? Personnel - roles/competence

Resolution:
Revised Text:
Actions taken:
December 11, 2007: received issue

Issue 11813: Text needs to be updated, since DeployedToSystemsNode does not exist (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

"8.4.32.7 Semantics
Use the DeployedToSystemsNode association to indicate deployment of
OrganizationalResource to a SystemsNode.
Use the OperationalCapabilityRoleResource association to indicate an
OrganizationalRole played by the OrganizationalResource.
Use the OrganizationalResourceCapabilityConfiguration association to indicate
inclusion in a CapabilityConfiguration
Use the DeployedToSystemsNode association to indicate deployment of
OrganizationalResource to a SystemsNode.
Use the DeployedToSystemsNode association to indicate deployment of
OrganizationalResource to a SystemsNode."

Resolution:
Revised Text:
Actions taken:
December 12, 2007: received issue

Issue 11824: Description is not sufficient. (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Description is not sufficient.
8.7.2.3 Description
Asserts that there is an association between a Forecast and a TechnicalStandardsProfile.

Resolution:
Revised Text:
Actions taken:
December 14, 2007: received issue

Issue 11893: UPDM compliance level 1 (updm-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Enhancement
Severity: Critical
Summary:

resolve how vision, requirements, and view/viewpoint are extended in the UPDM compliance level 1 (SysML)

Resolution:
Revised Text:
Actions taken:
December 26, 2007: received issue

Issue 11894: Refine the L1 compliance example in Section 10 (updm-ftf)

Click here for this issue's archive.
Source: INCOSE (Mr. Sanford A. Friedenthal, safriedenthal(at)gmail.com)
Nature: Enhancement
Severity: Minor
Summary:

Refine the L1 compliance example in Section 10 that was included in the approved December ballot of the resolution to Issue-11237. The page numbers 8-17 refer to the page numbers in the proposed resolution that was on the ballot.

Resolution:
Revised Text:
Actions taken:
December 26, 2007: received issue

Issue 11896: 8.3.10.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

ConformingElement provides a link from profile elements to specific standards in the context of a forecast."

Conforming element has no connection with Forecast.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11897: 8.3.14.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A PerformanceMeasurementrSet includes a set of PerformanceMeasures for each PerformanceMeasurePeriod. The set is
applied to ConformingElements. (See UPDM Class Library). This stereotype is applied to instances of classes stereotyped
PerformanceParameterSet."

Typo "PerformanceMeasurementrSet" 
PerformanceMeasurementSet does not include any PerformanceMeasures, since there is not such element. It includes actual values for each PerformanceParameterType that are owned by linked PerformanceParameterSet.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11898: 8.3.15.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

This Stereotype is applied to the PerformanceMeasurementSet in the UPDM ClassLibrary."

Does not make any sense

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11899: 8.3.16.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

PerformanceParameterType provides details for the type of attribute for PerformanceParameterSet."

The description is not sufficient. It should explain what is the meaning of this element and how it is used.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11900: 8.3.18.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specification is the ancestor of all the stereotypes that extend Instance Specification. It implements the common attribute,
description.
In general, any of the classes supplied in the class library as the type for instance specifications can be extended to
include additional attributes to be used in custom instance specifications.
Instances are created from classes that are defined in the UPDM ModelLibrary. The values of the attributes of the parent
class are set in the slots of the instance. Associations among instances of classes that reside in the Model Library are
specified by creating a link that is an instance of an association that is defined on the classes in the Model Library. In
addition, the stereotyped instance may have stereotype properties that define relationships to other stereotyped classes."


There is no description attribute. 
It is not clear why this stereotype exists and how it should be used.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11901: 8.3.22.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A general stereotype that can be applied to any element in a model that applies the profile."

The description is not sufficient

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11902: 8.4.6.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A Resource or OrganizationalRole can have a set of related Competencies that are required or provided to meet their
declared responsibilities and perform their OperationalTasks."

It is not clear clear if it is required or provided competency.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11903: 8.4.14.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

An OperationalCapability is a Use Case that specifies the requirements for a Capability."

UML terms should not be used in descriptions.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11904: 8.4.17.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies that an OperationalCapabilityRole requires zero or more Competencies and a Competence is required by zero or
more OperationalCapabilityRole and that these are the elements associated with this association."

If a OperationalCapabilityRole required Competency, it does not mean that Competency requires OperationalCapabilityRole, but the description says so.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11905: 8.4.19.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A flow of control of energy from one activity node to another."

It is not clear why this elements is needed and how it is used

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11906: 8.4.23.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

An OperationalNodePort is used to model details of Node connections when a Needline is modeled as a connector."

If this element is needed only to facilitate UML usage, it is not needed as separate stereotype. If there is some other meaning, it should be defined in the description.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11907: 8.4.28.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is the state machine for OV-5."

Wrong and not informative

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11908: 8.4.31.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OrganizationalRelationship describes the relationship between two OrganizationalResources."

The description should be more informative"

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11909: 8.4.43.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies that a OperationalNode or one of its sub stereotypes realizes an interface stereotyed
OperationalNodeSpecification or one of its sub stereotypes."

UML terms are used. Meaning and usage of this element should be described

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11910: 8.4.45.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

In effects based planning, the focus is on the outcome of an Effect. This is that end state, the ResultsOfEffect."

The description is not clear.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11911: 8.4.47.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

The event that invokes either an OperationalTask or a SystemTask in the EventTrace.
The ends of the connector associated with the message are the source and target of the information flow and the argument
is the information element. If there is no argument, then the invocation, itself, is the information element - i.e., a
command."

UML terms are used. Meaning and usage of this element should be described.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11912: 8.5.8.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Asserts that a CapabilityRequirement is related to an OperationalCapability."

The description is not clear. It is hard to understand what this relationship means.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11913: 8.5.9.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A transition from one state to another Causes an Effect. The Effect is the call event that invokes an OperationalActivity
on the receiving OperationalNode. The affected OperationalNode is the receiver of the InformationExchange while the
causing OperationalNode is the originator of the InformationExchange. The change in state is the Effect of the
InformationExchange. (See Effect)."

UML terms are used. Meaning and usage of this element should be described.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11914: 8.5.10.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

An Effect is an action that brings about a change in the state of something. The event that initiates the action is a Trigger.
The action is the result of an OperationalTask. An Effect is caused by collaborating OperationalNodes that bring about the
Effect as a result of their OperationalTasks. The collaboration, an OperationalCapabilityRealization, can be described in
terms of the Effect that it has. This Effect can be observed in an EventTrace from the perspective of the sequence of OperationalTasks. It can be seen in a StateTrace as a transition that CausesEffect showing the Trigger, the Effect, and the
desired ResultOfEffect, the end state. The OperationalActivity can show the Events that are Triggered and the receiving
Action that includes the OperationalTask in callOperationActions.
An Effect is the central player in all of these scenarios unifying the OperationalCapabilityRealization with the Effect,
viewed from the perspective of the collaborating OperationalNodes, the Triggers, States, and Activities."

UML terms are used. Meaning and usage of this element should be described.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11915: 8.5.13.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies that an OperationalCapabilityRealization delivers the Effect, or that an OperationalActivityRealization realizes
an Effect."

The description is not sufficient

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11916: 8.5.16.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies an association exists between a Resource and the Capabilities that it provides, that is, the Resources required for
a Capability."

There is a big difference between Resource providing Capability and Capability requiring Resources. Which one is it?

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11917: 8.5.17.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Defines the association between a CapabilityConfiguration and the all of Resources that are included in it."

The description could provide more information.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11918: 8.6.3.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A communications link is a single physical connection from one system (or node) to another. A communications path is a
(connected) sequence of communications systems and communications links originating from one system (or node) and
terminating at another systems (or node)."

The OCL does not allow SystemsNodes to be linked, but description says so.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11919: 8.6.5.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Asserts that the CommunicationPath is realized by a CommunicationsSystem described in terms of
CommunicationsSystems and Systems connected by CommunicationLinks."

Description is wrong

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11920: 8.6.6.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Asserts that a CommunicationPath realizes a SystemInterface."

A description should be more informative.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11921: 8.6.7.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A CommunicationPort occurs at the end of CommunicationLinks when it is necessary to provide details on the actual
connection. CommunicationPort may implement a PortType, though there is no requirement to be typed."

It is not clear what details spec is talking about. The description should be more informative.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11922: 8.6.9.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A data element exchanged in between systems."

The description should be more informative.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11923: 8.6.12.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A Forecast describes the actual or predicted status of a System at a Project Milestone - i.e., a point in the lifecycle of the
system. It can be a statement about the future state of one or more types of System or TechnicalStandardsForecast.
The Forecast is effective for a given timePeriod."

Forecast is linked to a SystemsGroup, not a System,

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11924: 8.6.14.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A Location is anywhere that can be specified. The means of describing the location is a string (locationDescription). The
information contained in that string is governed by the locationType."

Description should be more informative - why and where this element should be used.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11925: 8.6.15.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A Network is a collection of one or more CommunicationPaths. It may contain multiple CommunicationPaths between
the same pair of Systems. This is typically realized by the Network owning a set of CommunicationPaths.

Description is wrong.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11926: 8.6.17.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OperationalActivityRealization is a collaboration among Systems or SystemFunctionSpecifications that realize an
OperationalCapabilityRealization or other System capability."

Description should be more informative - why and where this element should be used.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11927: 8.6.18.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies that a System or one of its sub stereotypes realizes an interface stereotyped SystemFunctionSpecification or one
of its sub stereotypes."

UML terms are used. Description should be more about semantics, etc.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11928: 8.6.34.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

A flow of control, energy from one activity node to another."

Description should be more informative - why and where this element should be used.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11929: 8.6.35.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies the behavior of a System or OperationalActivityRealization as an Interaction - by depicting the sequence of
events between Systems and the invocation (TaskInvocation) of SystemTasks. The behavior of an interaction is depicted
in a sequence diagram that shows the ordered exchange of information between Systems through the activation of their
SystemTasks that participate in the interaction."

UML terms are used.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11930: 8.6.36.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Defines the behavior of a System or OperationalActivityRealization as an activity in terms of invocations of
SystemFunctions connected by SystemControlFlows and the flow of objects through the System with
SystemInformationFlows."

Description should be more informative and clear.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11931: 8.6.37.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

SystemFunctionSpecifications are abstract Systems modeled as Interfaces. They are not limited to internal system
functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions
that consume or produce DataElements from/to SystemFunctionSpecifications that belong to external systems. The
external system data sources and/or sinks can be used to represent the humans that interact with the system or external
systems. The SystemInformationFlows between the external system data source/sink (representing the human or system)
and the HCI, GUI, or SystemFunctionSpecification can be used to represent human-system interactions, or system-system
interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified in this product
through the ConformingElement relationship.
The relationship between OperationalActivities and SystemFunctions can also be expected to be many-to- many."

UML terms are used. Description should be more about semantics, etc.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11932: 8.6.38.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

The SystemGroup is a collection that includes instances of System, SystemHardware and SystemSoftware that forms a
unit for tracking and assessment purposes."

Description is wrong.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11933: 8.6.39.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies the System elements configured with a System."

It should be "Specifies the System elements configured with a SystemGroup". However I'm not sure if such description is enough.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11934: 8.6.48.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Specifies these are the elements associated with a SystemsNode."

Description should be more informative. What "associated" means in this context?

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11935: 8.7.2.3 Description (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Asserts that there is an association between a Forecast and a TechnicalStandardsProfile."

Description should be more informative. What "association" means in this context?

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11936: ActivityRealization metaclass should be Realization (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem

Unnecessary properties (association ends) are created. 
Direction is not clear 
Solution 
Change metaclass to Realization. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability (if needed).

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11937: CapabilityConfigurationCapabilities metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative 

Solution 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �configuredBy�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11938: CapabilityOperationalCapability metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative 

Solution 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �supportedBy�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11939: CapabilityRequirementCapability metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative 

Solution 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �relatedTo�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11940: DeliveredCapability metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative 

Solution 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �delivers�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11941: EffectAffectsNode metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative and too long 

Solution 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �affects�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11942: ForecastStandardsProfile metaclass should be Usage or Dependency. (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative and too long 
 Solution #1 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �groups� or �owns� 

Solution #2 

Remove ForecastStandardsProfile 
Change metaclass for TechnicalStandardsProfile to Package 
Use ElementImport or Ownership to link Forecast and TechnicalStandardsProfile

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11943: GroupForecast metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative

Solution 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �forecasts�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11944: MilestonePoint metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 

Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative 

Solution 

Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �governs�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11945: NodeCausesEffect metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative and too long 
Node cannot cause Effect, it should be Node�s behavior that does it. This relation is somewhat duplicated by 

OperationalCapabilityEffect.  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �causes�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11946: OperationalCapabilityEffect should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative and too long 
Different semantics in case of different ends.  

Solution 
  
Create one relationship for realization and one for delivery. 
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11947: OperationalCapabilityRoleCompetence metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative and too long  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �requiredCompetency� or �requires�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11948: OperationalCapabilityRoleResource metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative and too long  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �playsRole� or �plays�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11949: OperationalNodeCapabilityRequirement metaclass should be Usage or Dependenc (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear 
Unnecessary properties (association ends) are created. 
Name is not informative and too long  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �requiredBy�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11950: OrganizationalRelationship metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear. Very important in this case. 
Name is too long  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Multiple stereotypes could be introduced � �direct�, �indirect�, �back-up�, etc.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11951: OrganizationalResourceCapabilityConfiguration metaclass (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

OrganizationalResourceCapabilityConfiguration metaclass should be Usage or Dependency.
  
Problem 
  
Direction is not clear 
Name is not informative and too long 
  
Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �configuredBy�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11952: ResourceCapability metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Semantics is not clear. Is it Capabilities provided by Resource or Resources needed by Capability. 
Direction is not clear 
Name is not informative  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �requiredBy� or �providedBy (depending on sematics)

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11953: ResourceCapabilityConfiguration metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear 
Name is not informative  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �includedIn�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11954: ResourceCompetence metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Direction is not clear 
Name is not informative 
There might be a read-only library of Competencies, so modification is not wanted.  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �providedBy�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11955: SystemGroupMember metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  

Direction is not clear. 
Name is not too long.  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �groups�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11956: SystemsNodeElements metaclass should be Usage or Dependency (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Problem 
  
Description could be more informative. 
Name is not too long.  

Solution 
  
Change metaclass to Usage or Dependency. 
Add derived tags to both ends (at least to the target) to maintain bi-directional navigability. 
Change name to �hosts�

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11957: Ambiguos relation between Forecast and Milestone (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

From 8.6.12
"8.6.12.3 Description
A Forecast describes the actual or predicted status of a System at a Project Milestone - i.e., a point in the lifecycle of the
system. It can be a statement about the future state of one or more types of System or TechnicalStandardsForecast.
The Forecast is effective for a given timePeriod."


SystemGroup is also related to the Milestone (from 8.6.38).


There should be a constraint ensuring that there is at least one Milestone related to the SystemGroup directly and to the Forecast that is related to this SystemGroup. It would not make any sense to have a Forecast at the specific Milestone when a SystemGroup does not even exist.

Resolution:
Revised Text:
Actions taken:
December 27, 2007: received issue

Issue 11958: Section: 8.4.25.3 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Lou Varveris, lou.varveris(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary:

Text describes three instances of OperationalRole, yet the picture only has two � it is missing �Unanticipated User�. Note: In the DoDAF 1.5 spec, "Unanticipated User" is specified as one of the three types of OperationalRoles that should exist, so the text seems correct

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Discussion:

Issue 11959: Section: 10.4.5.3 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Lou Varveris, lou.varveris(at)us.ibm.com)
Nature: Revision
Severity: Critical
Summary:

The text says that "The concept of an actor or resource that realizes an OperationalNode has been made explicit by using OrganizationalResource that plays an OperationalCapabilityRole in the context of an OperationalNode." There seems to be two interpretations in the DoDAF field of 'who' does 'what' on an OperationalNode (the 'where'). Some interpretations seem to be that the OperationalNode is conceptual, and can be a 'who' and a 'where'. However, in MITRE�s Activity Based Method, the metamodel specifically states that a Role performs an Operational Activity on an Operational Node. Therefore an Operational Node is a �where�, and a Role is a �who�. DoDAF 1.5 has introduced the concept of OperationalRole but it seems to be a different concept than specifying a 'who' -- in other words, DoDAF 1.5 says an OperationalNode plays the OperationalRole of 'service provider', 'service consumer', or 'unanticipated user'. This is different than saying the OperationalRole is the 'who' that can be many different types of roles (besides those three). In this referenced paragraph in the UPDM spec, it would seem that the interpretation is that an OperationalNode can be a 'who', and that 'who' is specified by OperationalCapabilityRole, which can take on values "Service Provider", "Service Consumer", and "Unanticipated User". What of other roles then? Should OrganizationalRole (also in the UPDM domain metamodel) be used to specify 'who' does 'what' on an OperationalNode (the 'where')? All of this should be clearly sorted out in the UPDM domain metamodel and described clearly in the UPDM text.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Discussion:

Issue 11960: Section: 10.4.6 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Lou Varveris, lou.varveris(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary:

Is an OrganizationalRole different than an OperationalCapabilityRole? If so, this should be stated. UPDM spec should provide examples of the differences.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 11962: Section: B.4.19 OperationalServiceConsumer (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Lou Varveris, lou.varveris(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary:

OperationalServiceConsumer has been introduced because of DoDAF 1.5. If one is to assign an Operational Node the OperationalCapabilityRole of OperationalServiceConsumer, shouldn�t they also specify the Service that the Operational Node is consuming? If so, or if not, the text should specify how one uses this property value. Right now it seems open to interpretation.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 11963: Section: B.4.19 OperationalServiceProvider (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Lou Varveris, lou.varveris(at)us.ibm.com)
Nature: Revision
Severity: Significant
Summary:

OperationalServiceProvider has been introduced because of DoDAF 1.5. If one is to assign an Operational Node the OperationalCapabilityRole of OperationalServiceProvider, shouldn�t they also specify the Service that the Operational Node is providing? If so, or if not, the text in the Description (paragraph B.4.19.3) should specify how one uses this property value. Right now it seems open to interpretation.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 11965: Swedish Armed Forces General Comments (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

� UPDM uses extensions of associations to a very large degree, in most cases first showing entities as having named associations to other entities and then defining stereotypes for these associations. It is the view of the author that this should have been dealt with by making use of the association extensions within the meta-model itself rather than having them as separate entities. The latter is the approach adopted by MODAF.
� A set of different entities have been hard-coded into UPDM in the form of classes as well as enumeration entities. This is considered fairly dangerous since this can very well change over time making UPDM difficult to maintain. Its use could also well pose national problems since the values may not be applicable everywhere. MODAF/ NAF have avoided the use of any such entities and left them to be part of the model or referred to as externally defined entities, something that seems to be a better approach.
� It is difficult to understand why the different views should be stereotyped at all. The whole point of a modern architecture framework would seem to be to get away from strict adherence to a set of views. The main utility is the meta-model itself and how different entities tie together. How a user elects to visualise this is much less important. The addition of the Custom view is not felt to adequately deal with this.
� It is noted that as UPDM contains different compliance levels, exchanges between tools operating at different UPDM compliance levels will require recognition of these differences as well as translations if the exchange is to be successful.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11966: ArchitectureDescription (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The attribute instances of architecture summary indicate [1] and the constraints talk about zero or more.
�	The constraints seem to indicate a relationship between the architecture enterprise and an Enterprise which is not shown.
�	An architecture summary is shown as a specific class rather than a stereotype. The necessity of this can be questioned.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11967: Doctrine (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This entity seems better placed as part of the Strategic or the Operational views. It is furthermore shown as having an association with a SystemTask. This, while potentially the reason for placing in this view group, seems somewhat superfluous.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11968: Enterprise (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	By considering Enterprise as an extension of Package, the ability to use this effectively in a model seems to be severely limited. MODAF/ NAF.
�	MODAF/ NAF provides the ability to consider the enterprise as a set of temporal parts as well as whole-parts, something that will yield an ability to be much more specific as regards the enterprise.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11969: Goal (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This is shown as part of AllViews but would seem much better placed as part of the StrategicViews.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11970: PerformanceMeasureSet/ PerformanceParameterSet/ PerformanceParameterTyp (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	PerformanceMeasureSet also turns up as PerformanceMeasurementSet in a number of places and the correct term therefore needs to be established.
�	The attributes make use of the entity PerformanceMeasurementPeriod which does not appear anywhere else in the document.
�	The descriptions of all of these seem somewhat circular and could do with some modification: PerformanceMeasureSet ="This stereotype (PerformanceMeasureSet) is applied to instances of classes stereotyped PerformanceParameterSet". PerformanceParameterSet = "This stereotype is applied to PerformanceMeasurementSet in the UPDM class library".

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Discussion:

Issue 11971: Resource (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	Resource, given the explanation given also seems far better placed elsewhere than as part of AllViews. Given the extension used (Class) it is obviously a Type, but there seems to be some further classification going on since a resourceType parameter in the form of a string has been included. A ResourceType entity seems of interest. The value parameter also seems strange and the use to which this can actually be put seems questionable.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11972: Concern/ Stakeholder/ StakeholderConcern (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The relationship between these entities seems far from clear. A concern is an extension of UseCase and is associated with a Stakeholder as well as an ArchitectureView. A stakeholder is also associated with an architecture view and the relationship between Stakeholder and concern is stereotypes as StakeholderConcern. It would therefore seem that connections to ArchitectureView exist both through the concern and from the stakeholder directly. Is this really required?

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11973: StrategicMission (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This entity also requires further considerations. It seems better placed as either part of the StrategicViews or the OperationalViews. Given the attributes contained it would seem to be very focused on actual operations something that does not actually fit with its name. The fact that the parameters are only strings furthermore makes one question whether it can actually be used to describe something of architectural value.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11975: ExternalReferenceType/ InformationAssurance/ Security (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	Why do the ExternalReferenceType literals in the table repeat themselves as table entries?
�	While InformationAssurance and Security are of concern to an architect, it is considered highly doubtful whether the parameters shown here will cover the issue. Since these are examples of issues that require management across an entire enterprise it may be more profitable to look into aspect-oriented modelling concepts as a means of covering such issues.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11976: Capability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	Capability is shown as directly tied to resources, something that from a MODAF/ NAF perspective would be OK provided the entity was a CapabilityConfiguration. A Capability is an abstract high-level view of that which an enterprise wants to be able to accomplish during a specific time frame. Some of the attributes shown here are also strange such as type and isFielded which would seem to merit entities all by themselves in order to be usable.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11977: CapabilityConfiguration (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This entity would seem to be better positioned within the SystemView elements.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11978: CapabilityConfigurationCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This entity would work better as an extension of Dependency rather than association. It furthermore needs to be noted that capability configurations are defined by the capability they implement not the other way around. This implies that the supplier of the relationship is the capability and that the client is the CapabilityConfiguration of which there may be more than one since different combinations of resources could be used to supply a capability.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11979: CapabilityOperationalCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This entity seems highly questionable and is commented on later as part of comments concerning OperationalCapability.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11980: CapabilityRequirement/ CapabilityRequirementCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This entity has been removed in MODAF/ NAF as unnecessary. The relationships shown also seem strange. As commented upon later the crucial entity is Capability, and the fact that there is no relationship here between capability and a requirement for it therefore seems strange. Essentially all relationships shown for this entity are considered as highly questionable.
�	The need for CapabilityRequirementCapability as an extension of Association is also considered questionable.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11981: Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapab (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Effect/ CausesEffect/ EffectAffectsNode/ NodeCausesEffect/ OperationalCapabilityEffect
�	Previous versions of MODAF/ NAF contained an effect entity. This has now been removed since it is felt that effect based operations handling require additional consideration before an attempt is made to include it within the architecture framework. The inclusion of effect and associated entities within UPDM seems premature.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11982: OperationalNodeCapabilityRequirement (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	As commented upon both previously and later, the need for this association seems questionable.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Discussion:

Issue 11983: OperationalNodeCapabilityRequirement (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

OperationalNodeCapabilityRequirement/ OrganisationalResourceCapabilityConfiguration/ ResourceCapability/ ResourceCapabilityConfiguration
�	The description of OperationalNodeCapabilityRequirement discusses the need for a relationship between capability and operational node whereas the constraints as well as the name talks about a relationship between a CapabilityRequirement and an OperationalNode. The text should, if it is actually to remain be amended.
�	All of the above extensions of association are considered questionable as to need. Using MODAF/ NAF the fact that capability configurations are built by resources are apparent in the model and no additional associations are required.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11984: Operational views - ActivityRealization (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This extension of association is used to tie an OperationalActivity (an operational view element) to an OperationalActivityRealization (a system view element) or a SystemFunction (a system view element) to an OperationalCapabilityRealization (an operational view element). Based on the semantics description this seems to be intended to create one-to-many mappings between OperationalActivity (s) and SystemFunction(s) in both directions. The above seems a very cumbersome approach and is handled in a far simpler but equally functional way in MODAF/ NAF.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11985: Asset/ AssetMapping (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This seems to be a way of creating entities solely for the use within OV-1. The mapping entity then establishes a relationship between the asset and entities elsewhere. MODAF/ NAF manages this by viewing all the above as ConceptItems and therefore no additional entry is required. However since OV-1 users tend to want to draw lines between entities MODAF/ NAF has added an arbitrary connection element that can be used to indicate this. This has no semantic meaning however other than as an illustration. It is noted that no such feature seems to exist in UPDM.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11986: Materiel/ MaterielBehavior/ MaterielNode (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	Materiel is a very broadly defined entity that seems to relate to almost everything. At first glance the MODAF/ NAF equivalent would seem to be PhysicalAsset but given the concept of MaterielBehaviour this does not seem to be the case. First of all Materiel does not seem to need to be related to anything inside the OperationalViews and provided it is to be retained it should be confined to the SystemViews. The reason for this is twofold:
o	The operational views deal with logical operations not with solutions and by introducing materiel solutions are being discussed something that should be done in the system views.
o	In cases where entities in the operational views need to be made physical, something that happens when they do not belong to the trade-space as such, there is no need to go to a level of detail that needs materiel. MODAF/ NAF deals with a distinction between the two types of entities by stating by the use of a problem domain entity, a very useful concept.
The association entities therefore also seem questionable.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11987: OperationalActivity (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

t is noted that OperationalActivity handling does not seem to consider the entities that are considered as required when creating activity diagrams such as swimlanes, callbehavioraction, pins etc. Such entities exist in MOFAF/ NAF.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11988: OperationalCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This seems to define an entity in the form of UseCase "above" ordinary capabilities. It is however felt that the name leaves something to be desired (suggestion: CapabilityUseCase) and that it should be part of the StrategicViews rather than the OperationalViews.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11989: OperationalCapabilityRealization (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The fact that this is a specialisation of OperationalNode is considered strange as is the relationship it establishes. The crucial relationship would seem to be between capability and CapabilityConfiguration, this is the one that has to be maintained.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11990: OperationalCapabilityRole/ OperationalCapabilityRoleCompetence (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The fact that the first entity is supposed to be a specialisation of operational node is strange. It would also seem to belong squarely within the System View entities. Since the relationship is already there based on MODAF/ NAF entities it is considered questionable whether this is actually required.
�	The association extension seems questionable at least from a MODAF/ NAF perspective.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11991: OperationalNode (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	As stated before, MODAF/ NAF considers nodes as logical entities that could almost be viewed as instances of a capability. The connection to resources are therefore less than clear and as stated previously associations to effect are not considered appropriate at this point.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11992: OperationalNodePort (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	In spite of the fact that no such entity exists in MODAF and NAF, its inclusion is considered a good idea as a means of bridging the gaps between different levels of abstraction in an operational node model.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11993: OperationalNodeSpecification (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This is also considered a good idea, however, in order to be complete there would seem to be a need to tie required and provided interfaces to a port as well as InformationElements by means of the interfaces to make the handling complete.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11994: OperationalRole/ OperationalCapabilityRole/ OrganisationalRole (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The number of roles used here seems to restate much the same thing in different contexts. MODAF/NAF makes use of a single Role concept and that would seem to be enough.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11995: OperationalServiceConsumer/ OperationalServiceProvider (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The use of service related concepts here would seem to require a complete service handling throughout and this does not seem to be the case in UPDM, possibly due to the fact that OMG is considering other profiles for services. Based on this it would seem better to await developments here.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11996: OperationalTask (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This could be used to tie rather nicely into the handling of interfaces and ports in which case an operation could be a part of an interface associated with a realized interface that forms a part of a port. In all fairness however, if operations are made use of it is felt that signals should also be allowed, especially since a good way of visualising operations would be to allow InformationElements to be conveyed by signals (they could of course also be dealt with as part of the attributes associated with a given operation).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11997: OrganisationalRelationship (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The attributes here would seem to be reconsidered. It may well be appropriate to avoid these altogether since the few entries contained seem unable to capture all aspects of organisational relationships. A brief check within CADM for instance reveals a great deal of different relationships and it would therefore seem better to let the architecture model itself deal with this either internally or through external references.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11998: OrganisationalResource (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	While it is important to be able to show these entities in the form of an organisation chart it needs to be noted that MODAF/ NAF distinguishes between actual  organisational resources or types of resources, something that may well be required depending on the scope of the model.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 11999: Policy/ Rule (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	It seems slightly difficult to distinguish between these two entities and the questions should be asked whether they are both really needed.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12000: ResultsOfEffect (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12001: ResultsOfEffect (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	As stated above, the use of Effect seems premature and it is therefore felt that this should be removed.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12002: RealizedOperaionalSpecification (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	Since the connections between OperationalNode, OperationalNodePort and OperationalNodeSpecification is already established it seems unclear why this relationship would need to be established explicitly.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12003: System views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

CommPathFromTo/ CommunicationLink/ CommunicationPath/ CommunicationSystem/ CommunicationPathRealization
�	The main items here would seem to be connectors between systems and their aggregation into paths that could also include intervening communications systems. This makes sense, however the CommPathFromTo association seems fairly superfluous. The same can be stated for CommunicationPathRealization.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12004: DataElementSystemFunction (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This association also seems questionable since the relationship will anyway be present as a result of the definition of the system function itself.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12005: Network/ NetworkPaths (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The only difference that can be seen between CommunicationSystem and Network would seem to be dealing with geographical extension. Is there really a need to maintain two different entities to cover this area?

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12006: OperationalActivityRealization (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The description given for this entity would seem to make it difficult to distinguish this and a CapabilityConfiguration (at least from a MODAF/ NAF perspective). Is there a need for this given the existence of the CapabilityConfiguration entity?

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12007: Service (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	It is difficult to see the difference between a service as it is being implemented as well as a service as it is being described. Using an extension of Port also seems strange if is to be possible to actually describe a service functionality in an implementation independent manner. The proposed MODAF/ accepted NAF views for services make distinguishes between the description of a service and how it could be implemented. The description of a service is however much more than a single port. The exposed service port containing the service interface is important. A service taxonomy as well as classification is equally important. Composition as well as description of the service achievement is equally important. It is therefore felt that the parts dealing with services in UPDM might well await further definition of a meta-model for services once this is adopted by OMG.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12008: ServiceSpecification (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	See previous comment. In addition to this the attribute serviceDescription seems to be a link to a formal service description or a description of the service itself. Linking to an external specification is not considered enough for an architecture model intended to describe SOA, neither is a single text description.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12009: SystemServiceConsumer/ SystemServiceProvider (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	It is considered questionable whether the above entities are really of interest. A service is realized by a CapabilityConfiguration in MODAF/ NAF not just a system and anything other than web services will require more than this to indicate usage as well as provision of services. Being a consumer or provider will depend very highly on the point of view taken.
�	It is noted that in both of these, the text states that they are specialisations from System but the diagram shows them as extensions of class.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12010: SystemsNode/ SystemsNodeElements (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	MODAF/ NAF does not contain a system node concept and the question is whether a more applicable concept here would not be CapabilityConfiguration. The statement that a system node would be equivalent to PhysicalAsset in MODAF is not correct. If however there is a hidden assumption that a systems node has to be in a single location, then Capability configuration is broader since this would not be a requirement.
�	It is considered questionable whether the association extension is really required. A CapabilityConfiguration (to use a MODAF/ NAF term) would be visualised as a composite class diagram and the entities would thus turn up as connected to the surrounding entity without the need of a specific association.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12011: SystemSystemSoftware (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

By the same argument as that indicated in issue 12010 this association is not seen as required.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12012: Acquisition views DLODelements (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	This element may well be too specific and subject to change.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12013: Milestone (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The attributes contained here seem fairly simplistic and it seems doubtful whether they will be enough to manage the information required. By contrast, the meta-model for MODAF/ NAF gives a great deal more.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12014: Project/ ProjectType (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	The fact that a project type should be viewed as a specialisation of project seems very strange. The reverse would be more understandable.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12015: DLODIssueType (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

�	As stated previously, the inclusion of hard-coded enumerations is not considered as a good approach.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12016: General comparison (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

MODAF/ NAF are felt to be a more connected model than UPDM where no attempt is made to show all entities as a connected meta-model for different purposes. This makes UPDM much harder to assess.
MODAF/ NAF have a much clearer model of temporal components making it a lot easier to discuss how different parts of the model applies at different points in time.
The MODAF/ NAF use of UML: property ensures that several types of connections that UPDM defines based on associations are unnecessary in MODAF/ NAF.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12017: All views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
�	MODAF/ NAF contain environmental entities that can be used to qualify different parts of a MODAF/ NAF model. This has been found to be a necessity during the modelling field trials that have been performed in Sweden. UPDM has no such entities.
�	The handling of the Enterprise entities in MODAF/ NAF gives a much clearer picture of the temporal aspects and can be used to subdivide the enterprise into constituent parts that can be handled separately. No such handling is contained within UPDM.
�	MeasurableProperty handling as well as ontology references in MODAF/ NAF ensure that hard-coded enumerations and classes are not required. Hard-coded enumerations and classes are made use of within UPDM.
�	The handling within MODAF/ NAF of external references and Ontology is also much clearer that external reference handling within UPDM.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12018: Strategic views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
�	MODAF/ NAF ensure the ability to indicate capabilities composed of other capabilities. Whether this ability exists in UPDM is much less clear. In the same fashion MODAF/ NAF supports inheritance hierarchies between capabilities. This does not seem to be discussed within UPDM making it difficult to establish proper capability categorisation. The use of a type: String[1] within UPDM: Capability is not considered to be a valid substitute.
�	As stated previously, the inclusion of Effect based entities within UPDM seems pre-mature and the fact that this has been avoided within MODAF/ NAF is perceived as strength.
�	The field-trials and modelling that has been carried out based on MODAF/ NAF indicates that the MODAF/ NAF treatment of capability is valid.
�	The MODAF/ NAF entity dealing named StandardOperationalActivity has proven to be very useful during modelling. No equivalent entity exists as part of UPDM.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12019: Operational views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
�	MODAF/ NAF attempts to ensure that the modelling taking place as part of the operational views is logical and it uses the concept of ProblemDomain to distinguish between entities that are inside or outside of the trade space of the architecture. This is seen as a great advantage. UPDM has no equivalent concepts and the inclusion of the Materiel entity within the Operational view diminishes the logical handling within the operational views.
�	MODAF/ NAF contains a lot more stereotypes devoted to activity handling within the model than UPDM and while certain simplifications may be possible in this area, the area is still felt to be better covered in MODAF/ NAF than in UPDM
�	UPDM does contain port handling within the operational views, something that can be used to ensure a proper semantic bridging between different levels of abstraction and this is seen as a UPDM advantage. There seems to be some need to complement this model also in UPDM however.
�	The extremely large use of extensions of associations that are used by UPDM seems unnecessary and is seen as a problem.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12020: System views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
�	MODAF/ NAF places all of its solution based entities within the system view something that is not the case for UPDM which presents a much more convoluted picture. This is seen as a major advantage for MODAF/ NAF in comparison.
�	MODAF/ NAF enables discussions about bandwidth and spectrum utilisation, something that is not a part of UPDM. UPDM differentiates between different types of communication systems and networks however but here the distinction between different entities is far less clear. NAF makes use of Network as an add-on to MODAF but this has primarily been included as a means of stating something in the architecture relating to spectrum and bandwidth.
�	Both in the operational views as well as system views there are a couple of entities that deal with services in UPDM. This handling is seen as very inadequate. MODAF/ NAF contain a lot more in this area than UPDM and this is considered a major issue. In UPDM it also seems unclear whether a service description/ specification is being considered or if an implementation of a service is being described.
�	The extremely large use of extensions of associations that are used by UPDM seems unnecessary and is seen as a problem.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12021: Technical views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
�	There is a major difference between MODAF/ NAF and UPDM as regards the handling of InformationElement and DataElement. In MODAF/ NAF these are atomic and tied  in the data model to a standard where an entity within the standard can go into detail as regards their internal contents. UPDM does not seem to have a data model entity at all making it difficult to assess what should actually be shown as an OV-7 or SV-11 view should this view be desirable. The lack in this area is seen as a UPDM disadvantage.
�	MODAF/ NAF contain various specialisations of standard the support the handling of bandwidth and spectrum handling and this is considered an advantage for MODAF/ NAF in comparison with UPDM.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12022: Acquisition views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

A direct comparison between entities within MODAF/ NAF and UPDM shows a number of distinct differences. The ones of major concern are:
�	There is a very great deal of difference between the MODAF/ NAF Acquisition view entities and the UPDM Acquisition view entities. It is not considered possible to deliver the types of views that MODAF/ NAF requires based on the entities that UPDM contains and this is seen as a major disadvantage.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12023: Acquisition Views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The UPDM specification for the AcVs would appear to be incomplete. It specifies the key
stereotypes (Project, Milestone, etc.), but not the logic needed to put all these together into a
sensible programme management view (AcV-2).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12024: AcV-1: System of Systems Acquisition Clusters (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this view is now called �Acquisition
Clusters� in MODAF

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12025: DLOD Elements (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the MODAF Meta-Model specifically does not mention the Defence Lines
of Development (which are a UK only concept) so as to allow a more generic mechanism for
dealing with other project thread approaches � e.g. the US DoD DOTMLPF approach.
Furthermore, each line of development is specified in the UPDM profile. MOD has recently
changed the number of lines of development, and there is no reason to assume this will not
happen again.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12026: DLOD Issue Types (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

as with the DLOD Elements, UPDM hard-wires the possible status
indicators. MODAF does not specify this, and neither does the M3

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12027: Milestone (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

capability increment is represented by a string in UPDM. The M3 equivalent
links to the capability that is met so that there is contiguity through the architecture. Only by
doing this can StV-3 and SV-8 be derived from the project milestones (essential for
architectural coherence and contiguity across views).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12028: MilestonePoint (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the semantics of this relationship are unclear. In addition, there are four
relationships using this name in the Milestone section, which is very confusing

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12029: Project (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the UPDM description of Project confines it to the procurement of systems. The
MODAF approach says nothing about the type of project. This has been deliberately done in
MODAF to allow for capability increment projects that achieve the increments through
other means than equipment � e.g. revised doctrine, re-configuration of battlegroups, etc.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12030: ProjectType specialises from Project (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this is possibly a misunderstanding of the two
MODAF concepts � a type of project cannot be a special case of a project

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12031: All Views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The AV in UPDM is derived from IEEE1471 (the same goes for MODAF). The interpretation used in
UPDM is different to that used in M3. The biggest cause for concern is the Resource stereotype. It
is not clearly defined and attributed. It is not clear whether a resource is an individual resource or a
type of resource (a key distinction in Enterprise Architecture).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12032: ArchitectureSummary (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

a class library approach is used in UPDM, but not in MODAF

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12033: ArchitectureView (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this is the equivalent of ArchitecturalProduct in M3. However, M3
takes a different approach; instead of hard-wiring the views into the profile, it allows the
profile itself to specify the views and the framework used (allowing for NAF, DoDAF, etc. to
be covered by M3). M3 also specifies the type of product in terms of its nature � i.e.
structural, behavioural, matrix, etc. UPDM does not.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12034: PerformanceMeasureSet (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the purpose of this (and its related stereotypes) is not entirely
clear. It is defined as being applied to any ConformingElement, but the �semantics� section
talks about system performance

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12035: Resource (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this has two attributes that are probably not specified clearly enough to be
useful. It has a �value�, which is a string representing its �value to the enterprise�. There is
no way a simple string like this could be used for any kind of analysis or decision support in a
repository. In addition, Resource extends class, implying it is a type of resource, yet it has an
attribute �type�.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12036: UPDMAttributes (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this is a simple way to reference external information. To
accommodate the MODAF Ontology and IDEAS, a more sophisticated mechanism of
external specialisation, instantiation and equivalence will be required. This could be achieved
with some additions to the ExternalReferenceType enumeration, however

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12037: Enterprise & Vision (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

MODAF now defines the temporal and physical structure of the
enterprise � i.e. an enterprise can be decomposed into its parts and into its temporal
phases. UPDM applies the temporal information to the Vision (and also to other elements),
which does not allow for quite such a flexible way to �slice and dice� the architecture

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12038: Operational Views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The Operational Views form the linchpin of a MODAF architecture � they either serve to abstract
an as-is architecture into a logical structure, or present a logical requirement for a to-be
architecture. It is not at all clear that UPDM handles this. Of particular concern is the use of the
Materiel stereotype (see details below) which is not well defined and seems to connect logical and
physical elements with no clear semantics. The need for Material is also questionable � it seems an
unnecessary element to create in order to associate other elements

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12039: ActivityRealization (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

it is difficult to interpret the purpose of this from the definition (which
is somewhat Byzantine), but this seems in essence to be a relationship between an Op
Activity and a System Function to show that the System Function realises the Op Activity. If
this is the case, it seems strange that UPDM has not used the usual UML approach of a
dependency. Alternatively, it could be argued that as these are classes (i.e. types of activity),
then the system function is a special way of conducting an operational activity, so a
Generalisation relationship might be acceptable. The use of an Association seems very
unusual.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12040: Asset (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

no equivalent in MODAF for this concept (note this is a very particular use of the
word �Asset� for OV-1 purposes in UPDM)

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12041: AssetMapping (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this seems to be based on a poor understanding of DoDAF and MODAF.
Operational Nodes are logical �actors� whose functionality may be realised (by systems in
DoDAF, and by resources in MODAF). To have yet another level of abstraction (if that is
what this is meant to be) seems to just add confusion. In addition, OV-1 tends to be the last
view produced in an architecture, so it is unlikely that it will specify anything that is �later
realised�.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12042: InformationElement (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

in UPDM, this is a Stereotype of Class, whereas M3 uses
InformationItem.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12043: Materiel (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the definition in UPDM does not appear to make sense (possibly as the result of
cut-and-paste problems ?). Later references to Materiel would seem to suggest that is the
supertype of all UPDM elements that can have behaviour. This is not apparent from its
name or from its definition, so cannot be confirmed

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12044: MaterielBehavior (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this association links Material to UML behavioural elements. It seems
to allow Materiel to be linked to either operational behaviour elements or system behaviour
elements, which does not make sense. Without a clear definition for Materiel, it is not clear
whether the system behaviour or operational behaviour is correct. It is usual in DoDAF that
an operational node conducts operational activities, and a system conducts system
functions. Quite what UPDM�s Materiel is or does is something of a mystery.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12045: MaterielNode (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the semantics of this relationship are not explained. The same relationship
is used to relate Materiel to Operational Nodes, Systems, etc. without explaining the
semantics for each case.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12046: Needline (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

in UPDM, a needline is specified as a requirement to exchange information. In
an as-is architecture, it would not be a requirement, but a logical representation of an
existing information exchange. It should be noted that the UPDM definition is probably in line
with DoDAF in this respect, but not with MODAF

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12047: OperationalCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this is a UML Use Case that specifies the requirements for a
capability. There is no equivalent of this in MODAF or M3, but it does appear to be useful. A
future MODAF release should consider something similar for the StVs.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12048: OperationalCapabilityRealization (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

it is not clear why this relates an OperationalCapability
to the realizing systems, instead of just relating the Capability itself to the capability
configurations or systems � see also RealizedOperationalCapability

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12049: OperationalCapabilityRealization Definition (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This would appear to be the definition for
OperationalCapability rather than OperationalCapabilityRealization. In addition, it states that
the OperationalCapability is equivalent to an EnduringTask in MODAF, which is not correct

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12050: OperationalCapabilityRole (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

as this is a solution specification, it would belong in the SVs in
MODAF.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12051: OperationalCapabilityRoleResource (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this would appear to duplicate the functionality of
the OperationalCapabilityRealization

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12052: OperationalControlFlow (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this is defined as the �control of flow of energy from one activity
node to another�. Further clarification of semantics is required

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12053: OperationalEventTrace (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

event trace models apply to Materiel which is itself not clearly
defined, hence it is not clear what the event trace model would represent. In most MODAF
or DoDAF architectures, an OV-6c shows sequences of messages between operational
nodes � here it would seem to allow other representations

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12054: OperationalInformationFlow (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this represents the flow of information, materiel, or energy
between activity nodes (typically, these are Actions). MODAF and DoDAF only cover the flow
of information between activities. If this is an attempt to replicate the MODAF node
connector concept, it is a misinterpretation � node connectors are only intended to be
information flows on OV-2 diagrams � they have no behavioural semantics.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12055: OperationalNode (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the description suggests that an operational node �realises� capability,
which tends to give a rather physical slant to nodes. In MODAF (and DoDAF) operational
nodes are logical representations of the usage (or requirement for) capability in an
architecture. The realising systems are shown in the SVs (in MODAF, people and
organizations may also be part of the realisation). The physical aspect of UPDM�s
OperationalNode is reinforced by the enumeration NodeType, which allows an
OperationalNode to be an organization or type of organization. This is strictly against the
rules in MODAF, and probably against the original intent of DoDAF (though CADM does
allow it, and it is commonly found in DoDAF architectures).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12056: OperationalNodePort (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

MODAF does not use UML::Port for nodes

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12058: OperationalRole (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this concept does not exist in MODAF. In addition, it subclasses into
OperationalServiceConsumer and OperationalServiceProvider which would appear to
prevent a node from being both a consumer and a provider of different services (this is very
common in SOA models).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12059: OperationalServiceConsumer, Operational ServiceProvider (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

it seems inappropriate to
model service consumption in this way. It does not allow the architect to show that a
particular node is both a consumer and a provider of different services. This approach
forces the architect to produce two nodes � one for production and one for consumption �
even when it is clearly the same node producing and consuming. The work done in
developing SOA views by UK and Sweden would seem to indicate that OV-2 is not
appropriate in a true SOA approach � most SOA orchestration approaches map the
services to the activities that use them rather than to nodes. The nodes that produce and
consume services can then be derived by examining the activities they perform

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12060: OperationalStateTrace (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the definition describes it as the �state machine for OV-5�, yet
state models belong in OV-6b and typically describe the state transitions of operational
nodes (OV-2).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12061: OperationalTask (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this approach used UML Operations to link nodes to activities (though
the materiel object also seems to serve this purpose ?) and is not used in MODAF, where
instead a dependency is used to link nodes to operational activities

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12062: OrganizationalRelationship (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

an enumeration �LineKind� is used to describe dotted, solid,
etc. lines. This kind of graphical specification seems inappropriate in a meta-model
(especially as this only seems to be specified for OrganizationalRelationship).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12063: OrganizationalResource (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

it is not clear if this is an actual resource (e.g. Ian Bailey) or a
type of resource (e.g. EW Officer).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12064: OrganizationalRole (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

refers to roles being played by OperationalNodes, which breaks the
MODAF rule about nodes being logical

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12065: Policy (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this is not explicitly defined as an element in MODAF. Instead, MODAF architects
use operational activities, and standards to define policy. It may be worth considering the
addition of this in a future MODAF release � e.g. as a subtype of standard

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12066: RealizedOperationalCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

see issue with OperationalCapabilityRealization (issue 12048)

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12067: Strategic Views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There are a number of concerns about this package in the UPDM specification. There does not
seem to be a clear understanding of what a capability is and how it relates to other parts of the
architecture; the logical (OV) and physical (SV). Capabilities in UPDM have a strong equipment and
systems focus. In MODAF and M3, capability an ability to do something, which may or may not be
achieved by procuring / using equipment � e.g. it may be possible to provide a capability increment
simply by re-training soldiers

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12068: Capability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the UPDM spec states �The Capability is expressed in terms of the Resources
required to implement the Capability�, which is in clear contradiction to the way capability is
used in the MOD and the MODAF Stratgic Views. The whole idea of the capability concept is
for architects to specify their requirements INDEPENDENTLY of how it is to be
implemented (i.e. the resources to be used are deliberately not stated).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12069: Capability.isFielded (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this Boolean attribute is meant to describe the fielded status of a
capability. However, the reality is far more complex � the capability may be implemented
(and therefore fielded) in many possible ways. In addition, there are levels of fielding (IOC,
FOC). This problem may be related to the UPDM misunderstanding of the concept of
Capability.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12070: CapabilityConfiguration (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

despite the word �capability� being in the name, a capability
configuration is firmly in the solution space, and therefore does not belong in the StV
package of the UPDM profile (this also applies to the related stereotypes).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12071: CapabilityConfigurationCapabilities (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

again, this may indicate a misunderstanding of the
capability approach in UK and US defence acquisition. The statement �Defines the
association between a CapabilityConfiguration and the Capabilities that are configured by it�
implies the capability is defined by the resources that realise it. This is not the case (see the
comment on Capability).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12072: CapabilityOperationalCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this concept does not exist in MODAF (see comment on
OperationalCapability).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12073: CapabilityRequirement (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the relationship to Milestone does not appear to follow the
current MODAF approach. In MODAF 1.0, CapabilityRequirement was a specialisation of
Capability that had performance metrics. In MODAF 1.1, CapabilityRequirement has been
removed altogether (Capability itself is sufficient).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received isuse

Issue 12074: CapabilityRequirementCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

again, this would seem to be a misunderstanding of the
MODAF approach. OperationalCapability seems to link Capabilities to
CapabilityRequirements, but a capability manager would want to be able to specify capability
requirements in a broad sense without recourse to operational models.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12075: ResourceCapability (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the UPDM model has CapabilityConfiguration in it, yet it relates
capabilities to resources which deliver them � why then have CapabilityConfiguration ?

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12076: ResouceCapabilityConfiguration (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

see previous comment (issue 12075)

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12077: Systems Views (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The SV area of UPDM covers MODAF and DoDAF reasonably well. The concern mentioned before
about lack of a clear logical-physical split from OV-SV is again apparent in the SV section though.
SystemsNodes can �house� Operational Nodes in UPDM, which is against the original intent of
DoDAF, and clearly against the rules in MODAF. The remaining concerns about the SV area are
mostly due to the change in MODAF 1.1 that extends SV-1,SV-4, etc. to cover human factors

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12078: CommunicationLink (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

in MODAF, this is covered in SV-2 as a system port connection and
requires that ports be defined � this is not required in UPDM

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12079: CommunicationPath (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this concept does not exist in MODAF

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12080: CommunicationSystem (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this is not explicitly defined in MODAF � there was much
resistance from the MODAF TWG to introducing special types of systems (the argument
was �where do you stop ?�). Instead, the MODAF Ontology is used to add semantics to the
basic M3 elements. This also applies to hardware, networks, software, etc.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12081: DataExchange (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

MODAF no longer uses this � it simply has resource interactions that
carry data elements.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12082: Location (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

it is often important to distinguish between an actual location, and a type of
location (e.g. �in theatre�, �behind enemy lines�, �maritime littoral�, etc.)

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12083: OperationalActivityRealization (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this seems to indicate that an OperationalActivity can be
realised by an event trace or state model, which does not appear to make sense. Is it useful
to specify anything other than an op activity to system function mapping ? Also, this again
seems to relate to materiel, which further obscures the semantics of Materiel (if that is
possible).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12084: RealizedSystemSpecification, SystemFunctionSpecification (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this would appear to use an
interface to define a type of system and classes to deploy those systems. This seems rather
an unusual and complex approach given that UML now has composite structure models for
this purpose.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12085: Service (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this seems to indicate an implementation of a service by a system. In the NATO
SOA views, the Service stereotype indicates a type of service which may be implemented by
many different means (the UPDM equivalent would seem to be ServiceSpecification)

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12086: System (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

unclear whether this is a class of system or an individual system

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12087: SystemFunction (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

note that in MODAF 1.1, there are simply functions which are
performed by functional resources (systems, human roles, or capability configurations).

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12088: SystemGroup (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

it is not clear whether this is a group of individual systems (i.e. serial
numbered) or a grouping by type. Without this distinction, there may be semantic
interoperability issues between different tools and different architectures

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12089: SystemInterface (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

now represented as resource interactions in MODAF v1.1

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12090: SystemPort (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the definition talks about SystemInterfaces. However, SystemInterface is
more of an abstract concept. Surely it is CommunicationLink that should connect
SystemPorts ?

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12091: SystemServiceProvider, SystemServiceConsumer (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

as these are classes, it is unclear
how they are to be used. Do they represent generic actors in a service orchestration ?

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12092: SystemsNode (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

the relationship to OperationalNode appears to indicate that the op nodes
are part of the SystemsNode. This is inappropriate, as in both DoDAF and MODAF
operational nodes are logical entities that perform operational activities. They may be
realised as SystemsNodes, but to show structure in this way is a misunderstanding of the
intent behind MODAF and DoDAF. This is a common misunderstanding amongst DoDAF
users which has been cleared up in the MODAF 1.1 documentation

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12093: SystemTask (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

as in the operational views, these are UML operations linking Systems to
their behaviour. This is not done in MODAF M3, though it is a perfectly reasonable
approach.

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12094: Standard (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There are no major issues with the TV area of UPDM. The definition of Standard would have to be
broadened for MODAF use. Also, it is not clear how TechnicalStandardsProfile could be used in
MODAF.
� Standard � in MODAF, this includes non-technical standards whereas the UPDM definition
seems to restrict it to systems standards

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12095: TechnicalStandardsProfile (updm-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

this concept does not exist in MODAF

Resolution:
Revised Text:
Actions taken:
December 28, 2007: received issue

Issue 12096: Missing instance stereotype for compatibility with MODAF (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary:
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12097: 8.3.17.68:Resource Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

OCL doesn't check for zero or more. Constraint[5] is unnecessary. [1] Asserts that zero or more effects affect this resource. 
self.effect-> forAll(getAppliedStereotype('UPDM::Effect')->notEmpty()) 
Resolution:Add check for zero, delete [5]
Revised Text: 
 [1] Asserts that zero or more effects affect this resource.
self.effect->notEmpty() implies
 self.effect-> forAll(getAppliedStereotype('UPDM::Effect')->notEmpty()) 
[5] Asserts that there is an association between a Competence and the OperationalCapabilityRole that requires it. 
self.getAllAttributes()->asOrderedSet()->select(association->notEmpty() ).association->any (getAppliedStereotype('UPDM::OperationalCapabilityRoleResource')-> notEmpty())->notEmpty()

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12098: 8.3.21.6 :Strategic Mission Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

OCL doesn't check for zero or more. [1] Asserts that zero or more OperationalCapabilities have been designated as instrumental in achieving the StrategicMission. 

self.operationalCapabilities-> forAll(getAppliedStereotype ('UPDM::OperationalCapability')->notEmpty()) 
Resolution:Add check for zero
Revised Text: self.operationalCapabilities->notEmpty() implies
self.operationalCapabilities-> forAll(getAppliedStereotype ('UPDM::OperationalCapability')->notEmpty())

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12099: 8.3.24.3:Vision Description (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Multiplicity wrong for goals - should be [1..*] fix diagram to show 1..* Goals required by vision and 1..* visions by goal. In 8.3.24.5 fix multiplicity and add a descriptionj for goals
Revised Text: o goals : Goal [1..*] The Goals that contribute to realizing the Vision

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12100: 8.4.3:Asset (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

This stereotype is useless - delete. Delete Asset and AssetMapping stereotypes

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12101: 8.4.7.6: InformationElement Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Constraints [1], [2] OCL doesn�t check for zero or more. Resolution:Add check for zero
Revised Text: [1] Asserts that this InformationElement is associated with an OperationalActivityFlow. self.operationalCapabilities->notEmpty() implies
self.operationalInformationFlow.getAppliedStereotype ('UPDM::OperationalInformationFlow')->notEmpty() 
 
[2] Asserts that there are zero or more InformationExchanges that utilize this InformationElement self.operationalCapabilities->notEmpty() implies
self.informationExchange-> forAll(getAppliedStereotype ('UPDM::InformationExchange')->notEmpty())

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12102: 8.4.12.6: Needline Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

constraint [5] OCL doesn't check for zero or more. Resolution:Add check for zero
Revised Text: [5] Asserts that the elements in the operationalInformationFlow are stereotyped OperationalInformationFlow 
self.operationalInformationFlow->notEmpty() implies
self.operationalInformationFlow-> forAll(getAppliedStereotype('UPDM::OperationalInformationFlow')->notEmpty())

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12103: 8.4.13.5:OperationalActivity Associations (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

:materiel is listed as an association, but doesn't show up on the diagram. Resolution:It is actually a MaterielNode association, and should be removed.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12104: 8.4.13.6 :OperationalActivity Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

OCL doesn't check for zero or more. Resolution:Add check for zero
Revised Text: [3] Asserts that the entries in policy are typed Policy 
self.policy->notEmpty() implies
self.policy->forAll(getAppliedStereotype('UPDM::Policy')->notEmpty())

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12105: 8.4.14.5:OperationalCapability Associations (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Multiplicity and description for goals and StrategicMission are wrong. Summary:o goals : Goal [*] The Goals that are to be realized by the Strategic Mission and this capability 
o strategicMission : StrategicMission [*] The Strategic Missions supported by this OperationalCapability o 
Resolution:Add check for zero
Revised Text: o goals : Goal [1..*] The Goals that are to be realized by the Strategic Mission and this OperationalCapability 
strategicMission : StrategicMission [1..*] The Strategic Missions supported by this OperationalCapability 

remove Materiel,CapabilityRequirement and Capability

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12106: 8.4.19:OperationalControlFlow (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Typo -of should be or. Fix text
Revised Text: 8.4.19.3 Description A flow of control of or energy from one activity node to another.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12107: 8.4.21.6 :Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Typo input pin and output pin. Resolution:Fix text
Revised Text: [1] Asserts that if the source of the object flow is an outputpin, OutputPin then if the owner of the output pin is a CallBehaviorAction then its behavior is an OperationalActivity, or a CallOperationAction then its operation is an OperationalTask. 
[2] Asserts that if the target of the object flow is an Input Pin, InputPin then the owner of the Input pin must be an OperationalAction - a CallBehaviorAction whose behavior is an OperationalActivity, or a CallOperationAction whose operation is an OperationalTask. 

[3] The type of the input or output pin InputPin or OutputPin must be an InformationElement.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12108: 8.4.29:OperationalTask (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

8.4.29.3 Description - Missing association to Rule - fix diagram. :8.4.29.3 Associations
<<add>>
adheresToRules : Rule [*] Rules to which this OperationalTask adheres 
Resolution:Add check for zero
Revised Text: adheresToRules : Rule [*] Rules to which this OperationalTask adheres

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12109: 8.4.29.6:OperationalTask Constraints (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Constraints [1],[2],[3],[4],[5] OCL doesn't check for zero or more. Resolution:Add check for zero
Revised Text: [1] Asserts that this OperationalTask adheres to zero or more Rules 
self.adheresToRules ->notEmpty() implies
self.adheresToRules -> forAll(getAppliedStereotype('UPDM::Rule')->notEmpty()) 

[2] Asserts that this OperationalTask adheres to zero or more Policies 
self.adheresToPolicy->notEmpty() implies
self.adheresToPolicy-> forAll(getAppliedStereotype('UPDM::Policy')->notEmpty()) 

3] Asserts that there are zero or more Doctrines that govern this OperationalTask self.governedByDoctrine->notEmpty() implies
self.governedByDoctrine->forAll(getAppliedStereotype('UPDM::Doctrine')- >notEmpty()) 

[4] Asserts that Materiel is utilized by this OperationalTask 
self.utilizesMateriel->notEmpty() implies
self.utilizesMateriel-> forAll(getAppliedStereotype('UPDM::Materiel')->notEmpty()) 

[5] Asserts that the Triggers of this OperationalTask can be stereotyped Trigger, a callEventAction
self.triggeredByEvents->notEmpty() implies
self.triggeredByEvents->forAll(getAppliedStereotype('UPDM::Trigger') -> notEmpty())

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12110: 8.4.41.5 :Associations oPolicy (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Minor
Summary:

typos in association names.   Resolution:fix text
Revised Text: activity : OperationalActivity [*] This policy governs these Activities o 
operationaltask operationalTask: OperationalTask [*] OperationalTasks governed by this Policy o 
SystemFunction systemFunction: SystemFunction [*] SystemFunctions governed by this Policy o 
systemtasksystemTask : SystemTask [*] SystemTasks governed by this Policy

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12111: AllViews (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Minor
Summary:

Missing stereotype for ArchitectureSummary.  Summary:The classifier for ArchitectureDescription::architectureSummary is constrained to be ArchitectureSummary which means we have to have an instance of the Class ArchitectureSummary, but there is no stereotype for that.
Resolution: There should be a stereotype "ArchitectureSummary" that specializes InstanceSpecification.

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12112: Conforming Element (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

These Elements should also specialize ConformingElement
Summary:Goal - p
�	Competence-p,s
�	Capability-p,s
�	OerationalNode-p,s
�	Service-p,s
�	OperationalNodePort-p,s
�	SystemPort-p,s
�	CapabilityConfiguration-p,s
�	Effect-p
�	OperationalActivity-p
�	CommunicationPort-p,s
�	SystemTask-p
�	OperationalTask-p
�	SystemsNode-p

�	CapabilityRequirement-p
�	CommunicationsPath-p
�	CommunicationsLink-p,s
�	DataElement-p
�	DataExchange-p
�	Information Element-p
�	InformationExchange-p
�	System-p,s
�	SystemFunction-p,s
�	SystemInterface-p,s
�	Technical Standards Profile

Resolution:Add check for zero

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12113: 8.6.20:ServiceSpecification (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Service Specification can be either an interface or a class. It only extends interface. Resolution:Add Class extension
Revised Text: 
8.6.20.1 Extension
     o Interface (from UML2) 
�	Class (from UML2)

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12114: 7.2 UPDM Architecture Figure (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Figure is obsolete

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12115: UPDM Package Structure (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

The package structure does not lend itself to reuse. Resolution:Add the following packages and move appropriate stereotypes to these packages
�	Standards
�	Viewpoint
�	Requirement
�	BMM
�	Services
�	Communications
�	Parametrics
�	ResourceCompetence
Existing Packages remain
�	Acquisition
�	Strategic
�	Operational
�	System
�	TechnicalStandards

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12116: 8.5.4:Capability (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

isFielded is unnecessary, since "FieldedCapability" is defined as an instance of CapabilityConfigureatoin from MODAF

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Discussion:

Summary:MODAF clarified the meaning of fielded capability. We need to have a stereotype: FieldedCapability that specializes InstanceSpecification
Resolution:Create FieldedCapability stereotype - constrain it to be an instance of a class stereotyped CapabilityConfiguration

Issue 12117: ActualLocation (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Missing stereotype for compatibility with MODAF. Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of  Location

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12118: PostType, Actual Post (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Missing instance stereotype for compatibility with MODAF. Summary:PostType is very similar to OperationalCapabilityRole in UPDM, but we don't have a corresponding instance stereotype.
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of OperationalCapabilityRole

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12119: OrganizationType, ActualOrganization (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Missing instance stereotype for compatibility with MODAF. Summary:OrganizationType closely corresponds to OrganizationalResource in UPDM, but we need an instance stereotype corresponding to OrganizationalResource 
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of  OrganizationalResource

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12120: Competence, Actual Competence (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Missing instance stereotype for compatibility with MODAF. Summary:We need a correspoinding instance stereotype,
Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of  Competence

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12121: CapabilityComposition (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Missing stereotype for compatibility with MODAF. Resolution:Add stereotype extending Association to model composition of Capabilities both ends constrained to be Capability

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12122: 8.4.5 (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Attribute for compatibility with MODAF. Resolution:Add stereotype extending InstanceSpecification constrained to be an instance of

Resolution:
Revised Text:
Actions taken:
December 31, 2007: received issue

Issue 12208: Stereotyped Associations Notation (updm-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Fred Mervine, fred(at)mervine.us)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Stereotyped associations do not speicfy their end types. Stereotypes that are related to other stereotypes through stereotyepd relationships are specified in their diagrams with association to the other stereotypes and redundantly in their  Associations section. Apply the agreed upon diagram notation using steretyped dependencies - non normatinve notation used i the profile specificaton and remove all redundant associations.

Resolution:
Revised Text:
Actions taken:
February 4, 2008: received issue

Issue 12226: Connection between OperationalActivity and SystemFunction is not traceable (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

Connection between OperationalActivity and SystemFunction is not clearly traceable. This has effect on SV-5 generation.

Resolution:
Revised Text:
Actions taken:
February 15, 2008: received issue

Issue 12227: CapabilityOperationalCapability is duplicated (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CapabilityOperationalCapability is duplicated by stereotyped association and relation via subject/usecase metaproperties (as implied by OCL constraints)

Resolution:
Revised Text:
Actions taken:
February 15, 2008: received issue

Issue 12228: CapabilityRequirementCapability is duplicated (updm-ftf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Andrius Strazdauskas, andriuss(at)nomagic.com)
Nature: Uncategorized Issue
Severity:
Summary:

CapabilityRequirementCapability is duplicated by stereotyped association and relation via subject/usecase metaproperties (as implied by OCL constraints)

Resolution:
Revised Text:
Actions taken:
February 15, 2008: received issue