Issue 17206: Figure 7.8: <<metaproperty>> should be changed to <<metaconstraint>> Jira Issue UPDMRTF-2
Issue 17259: Need for ServiceInterfaces to be represented as an instance to capture specific ServiceAttributes Jira Issue UPDMRTF-3
Issue 17278: Mapping to DM2 higher level elements: Jira Issue UPDMRTF-4
Issue 17290: Use of superSubType, wholePart and WholePartType in DoDAF 2 Jira Issue UPDMRTF-5
Issue 17310: Desired Effect needs to be a strategic-level model able element Jira Issue UPDMRTF-6
Issue 17401: The Model library in the UPDM profile should be external to the UPDM profile Jira Issue UPDMRTF-7
Issue 17430: Views should be Normative Jira Issue UPDMRTF-8
Issue 18509: PV1 (DoDAF) Attributes Needed Jira Issue UPDMRTF-9
Issue 18571: Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and Jira Issue UPDMRTF-10
Issue 18573: Simplify measurements in UPDM Jira Issue UPDMRTF-11
Issue 18577: PIM Logical Service Specification Jira Issue UPDMRTF-12
Issue 18579: Need of Logical and Physical Services Jira Issue UPDMRTF-13
Issue 18580: Implements Relationship between Exchange Elements Jira Issue UPDMRTF-14
Issue 18686: Future Increments of UPDM should not preclude using SBVR for Modeling Vocabularies and Rules Jira Issue UPDMRTF-15
Issue 18688: UPDM DoDAF lacks a concept for Service Orchestration Jira Issue UPDMRTF-16
Issue 18691: Integrate SysML Requirements and Constraints Jira Issue UPDMRTF-17
Issue 18708: System and PhysicalArchitecture are siblings not descendants Jira Issue UPDMRTF-18
Issue 18718: ProjectSequence is too Restrictive Jira Issue UPDMRTF-19
Issue 18725: The <<Property>> stereotype and its properties Jira Issue UPDMRTF-20
Issue 18738: MapsToCapability relationship is too Restrictive, and ActivityPartOfCapability is redundant Jira Issue UPDMRTF-21
Issue 18739: use of Generalization to implement Aliasing Jira Issue UPDMRTF-22
Issue 18740: Use of Actual vs. Type in PV-1 Jira Issue UPDMRTF-23
Issue 18741: CV6, CV-7 and NSOV-3 Jira Issue UPDMRTF-24
Issue 18742: Subject of a State Machine Jira Issue UPDMRTF-25
Issue 18785: Need of Composition between Enterprise Goals Jira Issue UPDMRTF-26
Issue 18839: Why is EnterprisePhase to EnterpriseVision a one to one relationship Jira Issue UPDMRTF-27
Issue 18840: Introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them Jira Issue UPDMRTF-28
Issue 18841: Information flow instantiation Jira Issue UPDMRTF-29
Issue 18842: There needs to be a distinction between Operational View IEs and Systems View Exchange elements Jira Issue UPDMRTF-30
Issue 18843: For UAFP. Include a Data and Information view (DIV) Jira Issue UPDMRTF-31
Issue 18844: Why are rules in OV-6a and SV-10a not parsed? Jira Issue UPDMRTF-32
Issue 18845: Why does a user need to build an SOV-3? Jira Issue UPDMRTF-33
Issue 18956: Need to change target of desiredEffect from a state to a new element called effect Jira Issue UPDMRTF-34
Issue 18957: modify the term NodeRole so that is more applicable to a Peformer Jira Issue UPDMRTF-35
Issue 18958: DoDAF elements need to be identified and added to the various diagrams that represent the views Jira Issue UPDMRTF-36
Issue 17206: Figure 7.8: <<metaproperty>> should be changed to <<metaconstraint>> (updm-2-0-rtf)
Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Clarification
Severity: Minor
Summary:
Figure 7.8 uses <<metaproperty>> where it means <<metaconstraint>>
ActualServiceInterface: This would be an element that is the equivalent of the MODAF element ServiceLevel and would contain slots and instance values for the properties that have been defined for ServiceInterface. There would be a need to provide a tagged value to any usage of the ServiceInterface as a port either on a NodeRole or ResourceRole where the actual service interface would be indicated that is to be viewed as a requirement for this particular context. For the port used on the ResourceRole there would also be a need to indicate how many instances of the actualServiceInterface that the ResourceRole would need to accomodate, at least if a complete mapping to between MODAF and UPDM is to be achieved. (All of this actually exists already as part of the MODAF model that UPDM is supposed to implement).
Users are currently creating instances of ServiceInterfaces to define actual ServiceAttibutes. Another workaround is to use IDEAS concepts of types and individuals for ServiceInterfaces Another workaround is to use MeasurementSets and ActualMeasurementSet Proposed Disposition: Defer
Currently UPDM does not map a numer of elements that exist in DM2, namely those above the Type level, for example CapabilityType since UML does not support elements at higher type levels. There is however a possibility of doing this by recognising that a set of capabilities (as an example) contains a given capability instance but capability categoreis are really a larger subset of available capabilities. This would make it possible by allowing the elements to contain a tagged value that indicates whether they are to be considered at a higher type level. This would make it possible to provide a mapping between more DM2 elements and UPDM elements than currently possible. It is assumed that a tagged value would be easier to handle than the introduction of additional stereotypes since categories would imply elements with different stereotypes inheriting from one another.
Potential need for a capability category tag to capture the powertypes. It was felt that this should be rejected for this version of UPDM due to the developments going in with respect to the unification of the various frameworks Therefore it was decided to defer this issue. Proposed Disposition: Deferred
Use of superSubType, wholePart and WholePartType in DoDAF 2 DoDAF 2 contains rules that indicate that superSubtype relationships can be formed between any type elements of the same kind. The same rule applies for wholePart (betwen individuals of the same type) and WholePartType (between types of the same kind). In UPDM terms this would correspond to Generalization as well as property handling. There are not enough stereotypes defined within UPDM 2 to allow these rules to be followed. This either needs to be rectified or a general statement made within UPDM that allows the use of the appropriate UML relationships to accomplish this.
We have subset of these rules already in embedded in UPDM. It was decided to defer this issue based upon developments with the unification of the various frameworks Proposed Disposition: Deferred
I really need "Desired Effect" reinstated. This will act as the "Objective" in my strategy models. This was available in UPDM 1.0 now it's gone. This is actually very important to modeling a strategy. However, when or if you can bring it back, it previously provided the output link of "Realizes Vision". That is wrong. It needs to "Realizes Enterprise Goal". It's the Enterprise Goals that realize the Mission. And it's the Mission(s) that realizes the Vision. The sequence is as follows: CAPABILITY--->DESIRED EFFECT--->ENTERPRISE GOAL--->MISSION--->VISION
The Model library in the UPDM profile should be external to the UPDM profile
While the proper implementation of a UPDM 2.0 Profile assures successful exchange of data models, the exact content of the VIEWS remain non-normative. There needs to be a definition of the minimum data elements to support each view as well as optional data elements. The UPDM RTF Group needs to discuss whether all (52?) Views need to be made NORMATIVE, how to support Optional data, and how to support the required USER-DEFINED VIEWS.
In the current DoDAF Project Viewpoints (PV1) the project element has a start date and an end date. Those attributes are not sufficient for the US JCIDS process. In the incremental development process described by JCIDS, we have increments, blocks and spirals. In the main we don't measure our programs in absolute start and stop dates but rather where they fall in the relative JCIDS process, priority and lifecycle. Start dates are usefull but with a 20-30 year lifecylce, the stop date is not as useful. Having these attributes (increment:string, block: int and spiral:int) in the Project Element would allow us to trace requirements and capability sets to the proper increment, block or spiral.
Expand general activity modeling for all UPDM constructs to include representation by action, callBehaviorAction and callOperationAction. Please enter issue against UPDM RTF 2.2. Allow ( OperationalActivityAction, ServiceFunctionAction, ProjectActivityAction and FunctionAction ) to be represented as either CallBehaviorAction, CallOperationAction or Actions. Currently only CallBehaviorAction is allowed.
Please enter this issue against UPDM RTF 2.2. Simplify measurements in UPDM and make measurement compatible with SysML unit, value, and parametric constraint. See diagrams below. No need for measurement set.
An import use of architecture is to provide sufficient information to guide the design and implementation that realizes the architecture in the actual solution space. By definition, architecture dictates neither the design nor the implementation that realizes it, though this boundary is often blurred to a certain degree by a particular organizations methodology or pragmatic need of a projects. As SOA is an a widely employed architectural pattern where by systems interact with each other, it would seem important that the expression of SOA in UPDM be fit for purpose, sufficiently accurate and information complete to reduce the conceptual gap between architecture and design+implementation. Further, the rendering or specification of SOA interfaces and used datatypes should be sufficiently fine grained to allow such possibilities as: Transformation into constructs used in design and implementation workflows, e.g. Code Skeletons, XML Schema, etc. Supporting the expression of test cases and declarative expressions of architectural instrumentation for such purposes as monitoring and analytics. In this particular issue we focus on the SvcV-1 and SvcV-2, which would be the natural place to specify the actual SOA related elements. The following diagram provides a context from an external, classifier derived perspective. Focusing on the services themselves, the diagram below shows an intended The SvcV-1 that illustrate the specification down to the actual operations is shown in the following diagram The issue submitter acknowledges that there are arguably some other ways to represent services, given such constructs as ServiceFunction, etc., but the method depicted above �feels� more accurate and aligned with downstream design and implementation, especially in the context of UML that might be used by teams independent of UPDM. In conclusion, the issue submitter, along with project colleagues, wish to have a useful set of mechanisms/metamodel constructs that allow the expression on services, their interactions and the flow of data between them at the PIM/Logical level using, logical data captured as EntityItem that details conceptual data captured as ExchangeElement. This would allow direct traceablity from conceptual interchange expressed at the OV level with how it is addressed at the SV level. In simpler terms, when two activities exchange information at the business process level, we can easily find how this conceptual interaction is realized as SOA services. Once establishing this in the model we can then hand it off to design and implementation workflows in a more accurate, traceable and useful architectural specification form. Significantly, such and architecture might prove much more fit-for-purpose for model related practices, transformations and automations involving the instrumentation, simulation and observation of the architecture in its solution realized forms. Also tests might be expressed more tightly. Resolution: Part of the resolution would be related to the fact that and ExchangeElement is subtyped from ResourceInteractionItem whereas EntityItem is subtyped from Class. The result is that a logical data structure captured as an EntityItem cannot be the conveyed item in a ResourceInteraction. We would either need to revise the metamodel related to ResoureInteractionItem or add some new construct, say something like DataInteractionItem and DataInteraction that could be used to express the flow of logical data, which the issue submitter models using EntityItem in DIV-2 package structures. On the profile diagram below, one can observe the absence of EntityItem There are related traceablity issues that will the subject of further submissions, however, this submission focuses on the essential part of expressing the set of SOA ports, interfaces and data flows in an architecture.
In UPDM we are missing capability to differentiate between Logical and Physical Services. Note that this capability is already supported in DoDAF. It is also supported in other frameworks such as TOGAF etc. In UPDM it is mixed up and not clear enough what kind of services we are allowing to define. If we use services in SVs, we suppose to have physical services. If we are using services in OVs, we suppose to have Logical (Business) services. Having a normal logical/physical pattern we are already using in UPDM, we should be able to have traces between the two. Unfortunately we cannot differentiate between logical and physical services. It implies we cannot have two different levels of details when we are dealing with services. And we are forced to do services in either Operational or System viewpoint, but not in both. UPDM should: � Enable user to model logical services � Enable user to model physical services � Allow traces between logical and physical services � Provide means to integrate logical services to OVs � Provide means to integrate physical services to SVs
In UPDM 2.0 Exchange Elements emerged from Information and Data Elements used in UPDM 1.x. They can still be classified into information and data indicating different levels of abstraction. However, one cannot be connected to another as it used to be in UPDM 1.x. In other words there is no way to relate data to information.
SBVR, the Semantics of Business Vocabularies and Business Rules, provides a formal logical foundation for the expression of enterprise ontologies and rule constraints applicable to enterprise elements. SBVR also offers informative, non-normative notations for these vocabularies and rules. Future increments of UPDM (i.e. UAFP v1) should not preclude an enterprise architect from using SBVR and its metaclass elements for the expression of ontologies and rules within their UPDM (to be known as UAFP) models. These enterprise ontologies and enterprise rules appear throughout a traditional UPDM architecture description in the structural elements of the respective views (e.g. Performers, Operational Activities, Systems, Services, etc) and in the constraints on those elements.
Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture. The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"--which is poorly named and which suggests the means of accessing a single entity--and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc. ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration". Recommendation: either add <<SOAML::ServiceArchitecture [Collaboration]>> directly into UPDM or add <<UPDM::ServicesCollaboration [Class]>> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations.
Constraints and Parametric Blocks in the SysML notation have proven their value in enabling the use of models as parameters for discipline-specific analysis and simulation. Likewise, SysML Requirements have proven their usability for annotating models with Requirements and with Requirements Traceabilities (such as Satisfaction, Derivation, etc.) The user community (including MITRE, Raytheon, Intercax, and professional services architects such as No Magic staff) requests that UPDM integrate the Requirements, Constraints, and Parametric Blocks into UPDM. Then, Enterprise Architects using UPDM can perform their systems and econometric analyses and their requirements engineering with their UPDM models that they can perform today in SysML modeling. (How and Where such integration is accomplished is a topic worthy of deliberation but is beyond the scope of a customer-centric requirement request.)
As shown in Figure 8.127 for CapabilityConfiguration to PhysicalArchitecture and Figure 8.130 for PhysicalArchitecture to SystemResource and in Figure 8.178 for System to ResourceArtifact, Figure 8.132 for ResourceArtifact to PhysicalResource, Figure 8.131 for PhysicalResource to SystemResource, one can see that System and PhysicalArchitecture are sibling concepts. Now, FieldedCapability has this constraint: "Value for the classifier property must be stereotyped �CapabilityConfiguration� or its specializations." (see Page 172) The consequence of this is that a self-contained System cannot be the Classifier of a FieldedCapability. That is, a FieldedCapability cannot be an instance of a System. I claim that it is convenient to be able to specify that a FieldedCapability is an instance of a self-contained System. Having to model a separate CapabilityConfiguration to wrap just the System so that one can instantiate a FieldedCapability that is an instance of the System seems onerous. The recommended remedy is to allow a System to be a proper CapabilityConfiguration in addition to being a property of a CapabilityConfiguration.
According to the definition of ProjectSequence, "MODAF: Asserts that one ActualProject (MODAF::Project) follows from another - i.e. the target ActualProject cannot start until the source ActualProject has ended. DoDAF: NA". The restriction "...cannot start until the source ActualProject has ended..." precludes practical project management. In practice, projects can have a partial ordering yet not be strictly sequential. Projects can overlap each other in time, occurring partially contemporaneously. One sees, in a common tool such as Microsoft Project, the ability to specify Start to Start, Finish to Finish, Start to Finish, and Finish to Start offsets. Recommended Remedy: Enhance Project Sequencing to support SS, FF, SF, and FS offsets between prior and next ActualProjects. The kind of offset and the duration of the offset would each be Tag Values of ProjectSequence.
UPDM includes a <<Property>> stereotype with properties maxValue, minValue and defaultValue. <<CapabilityProperty>> specializes the Property stereotype and extends the Property metatype. 1. could you rename the Property stereotype to avoid confusion with the UML metatype of the same name? 2. since the UML metatype Property already has a defaultValue, could the UPDM one be removed? 3. the min/max/defaultValue properties have no multiplicity specified in the spec or XMI, so it defaults to 1. If these were intended to be optional they should be specified as [0..1] These impact XMI (see MIWG TC22).
There is a constraint stated in Figure A.30 of the dtc/12-12-17 specification such that in MODAF (and therefore NAF), the MapsToCapability relationship is precluded from using OperationalActivities and is prescribed to only use StandardOperationalActivities. This has resulted in defining another relationship in the spec called ActivityPartOfCapability for DODAF, that creeps into MODAF and NAF in vendor implementations, to allow one to associate an activity with a capability for the purposes of generating traceability diagrams and for generating NPV-2: Program to Capability Mapping (through Activity is part of project, and Activity is part of Capability). There is no need for both and it is redundant and a possible source of model inconsistencies to request the architect to define both MapsToCapability and another called ActivityPartOfCapability. Further, the MODAF constraint to use only StandardOperationalActivities when mapping to capabilities for the purposes of (MODAF policy?) can be accommodated in another manner.
Issue 18739: Name: Fatma Dandashi Employer: Mitre Corp. mailFrom: [email protected] Terms_Agreement: I agree Specification: UPDM Profile Section: FormalNumber: dtc/12-12-17 Version: 2.1 Doc_Year: 2012 Doc_Month: December Doc_Day: 17 Page: 218 Title: use of Generalization to implement Aliasing Nature: Enhancement Severity: Significant CODE: B1: Report Issue Remote Name: Remote User: Time: Description: DMM defines system as a DoDAF-only alias for ResourceArtifact: Profile then defines the following: (this is probably true for all elements that are aliases). Using generalization in this manner means that vendor implementations allow one to use both System as well as ResourceArtifact in the same model, regardless if one is using DoDAF or MODAF. System is an alias for MODAF�s ResourceArtifact in DODAF only. That is, System should not be available as a choice in MODAF/NAF. More importantly: generalization is really not the best UML construct to implement aliasing. If you choose System in NAF, you will not be able to use composition and aggregation relationships on SV-1. One should be able to use System in exactly the same manner as a ResourceArtifact, especially the aCurrently, one has to use ActualProject and ActualOrganization to get an organizational to project mapping. Why not organization and project types? Understand this theoretically, (only a �real� organization can undertake a �real� project), however what if the architecture description itself was all a pattern? I should be able to associate classes of organizations (a type) with classes of projects. Profile:
In UPDM it seems that the Service to OperationalActivity matrix is non-editable. The relations are established after one creates capability to OpAct relations and capability to service relations (in CV-6 and CV-7/NSOV-3 respectively). This may be how it is explained in DODAF/ MODAF? (no direct relation between ServiceInterface and OperationalActivity: But it is not how it should be. Here is why: CV-7 is useful when considering how services that may already be available (internally to subject architecture scope, or provided by third party entities) can be leveraged to enable the required capabilities. However, a true model-based approach to capability development and analysis will include an operational view model that further delineates the capability (stated as a term and a definition) and describes the ways and means needed or provided to enable the capability. Such an analysis usually uncovers issues with the defined capability taxonomy such as overlapping or non-mutually exclusive capabilities, and will lead to a better formulation of the capability taxonomy. The operational model is also used as a guide to develop or identify needed services in a service model. Thus, it is good SE discipline not to try and develop CV-7 starting with two sets of taxonomies, one for capabilities and another for services, without conducting the necessary modelling of operational and service artifacts needed, conducting the analysis, and �discovering� the relationships between capabilities and the services needed to enable them. So I propose that the order is like this: 1. develop a Capability taxonomy (CV-2); 2. develop Operational views (especially the behavior diagrams) 3. iterate on capability taxonomy and op behavior until one is somewhat satisfied that the capability taxonomy and operational elements (as modeled) are consistent and capabilities are well delineated. At this time a CV-6, (Capabilities x Operational Activities) matrix may be generated; 4. develop a service view model that supports the operational model and evaluate the ability of the enterprise to offer each Capability and make a Build versus Buy/Outsource decision. Some more iterations on elements in CV, OV, and SOV may take place again, especially as the services taxonomy and service orchestration diagrams are developed. That is, the service model may cause Operational Activities as well as capability taxonomy to change again. Once things stabilize, an SvcV-5/NSOV-3 (Services x Operational Activities) matrix may be generated; a. For those Capabilities that will continue to use existing systems within the Enterprise, model their As-Is Systems Views; b. For those that are to be Built, or are to be Bought, model the the Services Views to identify (conduct an analysis on what is available within and outside enterprise), and identify the contractual Service-Level Agreements and indicate the Service orchestration with the Enterprise's Performers. i. For services to be built, proceed to detail in systems view ii. For services to be outsourced stop detail here (services view) but show they are used in systems view (via service request interfaces for system components. 5. when one feels that the operational and services models satisfy the updated capability taxonomy, one can generate (from the relationships already established), the Capabilities x Services (CV-7) matrix 6. Develop Systems Views and then map (system) Functions to Services and Functions to Operational Activities.
Issue State machine issue: UML states the subject of a state machine can be behavior or structural: �The StateMachines package defines a set of concepts that can be used for modeling discrete event-driven Behaviors using a finite state-machine formalism. In addition to expressing the Behavior of parts of a system �, state machines can also be used to express the valid interaction sequences, called protocols, for parts of a system. These two kinds of StateMachines are referred to as behavior state machines and protocol state machines respectively.� MODAF specifies both node and activity, DODAF says activity only: Short Name DODAF DODAF MODAF/NAF MODAF/NAF OV-6b OV-6b State Transition Description DoDAF: The Operational State Transition Description (OV-6b) DoDAF-described View is a graphical method of describing how an Operational Activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. OV-6b Operational State Transition Description MODAF: OV-6b: The Operational State Transition Description is a graphical method of describing how an Operational Node or activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. UPDM states node only?
Please enter this issue against UPDM RTF 2.2. In UPDM 2.1 we are missing capability to decompose Enterprise Goals, e.g. goal, objective pattern supported by BMM. This capability is already available in MODAF 1.3 witch UPDM claims to support.
Why is EnterprisePhase to EnterpriseVision a one to one relationship? Composition relationship is also not needed. Discussed resolution: � change relationship to: one to many on EnterprisePhase end and 0..1 on EnterpriseVision end. � delete composition relationship
Typical and actual posts, etc. should be introduced and defined in SV-1 as they are the human equivalent of systems, capability configurations, etc. It is in SV that we provide a PSM/white box/logical design model where we introduce elements (human as well as materiel) that are to be allocated to the problem domain described in OV. Resolution discussed: introduce roles in SV-1 and allow them to relate back to OV-4 organizations that will provide them. Checked this in MODEM. Below is how it is currently defined.
Information flow instantiation. There is no UML construct to define flow and then to instantiate flows to use flow types and then flow instances that flow between two instances of two things. Discussed Resolution: See simple exchange example in MODEM
Information Exchange (IEs) item or element: Currently all IEs are defined as elements of package AllView. This should not be the case. There needs to be a distinction between Operational View IEs and Systems View Exchange elements. Discussed Resolution: Currently in MODEM, only InformationElement flows are allowed in OVs (see below). MODEM will use FlowedElement instead. Will consider changing its current type from abstract to make it a typed generic flow defined in OVs. An abstract ResourceType is defined for SVs. It will have as subtypes: human, non-human etc. as shown below. In addition, subtype InformationElement will be moved from current location to be a NonHumanResourceType defined in SVs. Allow any of the SV ResourceType leaf level elements (e.g. NaturalResourceType) to trace back to OV flows.
For UAFP. Include a Data and Information view (DIV). This view is to be used for domains where a DB is needed. Remove DIV-3/ SV-11 physical schema as a supported model/Diagram type. Make it an external reference only, either a physical schema in another tool, or an XML flat file etc. Change DIV-1 and DIV-2 to be defined/associated with Systems View elements only, since you only specify data conceptual and logical models at the solution level. In SV, the InformationElement will be a NonHumanResourceType that is associated with entities defined in DIV-1 and DIV-2, since only information can be stored in a database
Why are rules in OV-6a and SV-10a not parsed? They need to be specified as OCL constraints. Similarly for SOVs, use OCL to define performance level supported by each provider to each type of consumer as in a Service Level Agreement (SLA).
Why does a user need to build an SOV-3? The relationship from services to capabilities should be transitive. Once a user establishes traceability from operational activity to capability and from ServiceFunction to Operational Activity, then there is already a trace from owning service (service that owns that ServiceFunction) to a capability and SOV should b au-populated. Further, a service(Interface) should map to a node and not to an OperationalActivity or to SystemFunction. This change is to be discussed with respective requirements representatives.
Desired affect targets "state" in UPDM 2.1, states must have a context and this causes the architects to think too low down in the model (at the OV and SV level) where implementation exists. Desired affect needs to be tied to something in the CV/Stv that is not a "state", called Effect in the CV/StV.
The term NodeRole is more applicable to MODAF than DoDAF and does not derive from Performer, Ron Williamson sugested PerformerRole. There are other terms that could be affected in the this way like NodeOperation. Even though I understand the need, I am against creating more Stereotypes that are Aliases for DODAF. It becomes harder to maintain and more problematic for implement. I would suggest that we rationalise the name of the stereotype for instances of Nodes/Performers to be aligned with both MODAF and DoDAF, i.e. OperationalNode.
This issue relates to the readability of the specification on the various "view diagrams", DoDAF elements are left of off these diagrams it becomes hard to recognise which diagrams use specific DODAF elements, it is only through understanding what things have DoDAF aliases that you can see what needs to be added to the correct diagram. These elements need to be added to the diagrams that they can participate in by showing the MODAF elements that they alias/inherit properties from.