16 Apr 2010 DoDAF - DM2 WG Agenda

1. News:– M3 Incorporation of IDEAS Meetings this week– Others this week: JAIWG, DoD MDRWG, DoD COI Forum– Reminder: DoD Services Conference w/o 19 April, DoD EA

Conference coming up soone

2. New References: • none

3. Parse of M3/IDEAS Group comments into DM2 AI list

4. Review new Action Items (“unassigned”)

5. Prioritization of 2.02 AI’s – in reverse order!

6. Others:– In queue but probably won’t have time to get to tomorrow:

• 20 SoAML terms to compare to DM2 data dictionary• TBS from WG tomorrow

M3The concept of state seems to be missing. While each element from a temporal perspective can be viewed as a state i.e. an IndividualResource for a limited temporal duration can be considered as being in a state. As types of resources are being considered however there would seem to be a need to discuss the types of states that these resources can be in. The temporal dimension is less easy to deal with under these circumstances. This therefore needs further discussion.

Every spatio-temporal Thing can have state. OV-6b and SV-10b can be done using before-after and TWP. Action – study Partridge/Levine/Bailey/Antoine email. DM2 WG Ken White’s Soda machine state machine. If something missing, could be an IDEAS issue. Question TWPT is valuable in state machines. Need IDEAS documentation.

While the model has been modified such that no real powertypes exist that do not have associated individuals that they are a powertype of (previously the case to a very large extent in DM2 2.00) the actual use of powertypes still needs to be considered from a modeling perspective. A Powertype has a very strict definition, it is the set of all subsets that can be created from a set of either individuals or sets. An example of this is ProjectType and Project. Project is descended from IndividualType i.e. it is a set of Individuals. If a modeler creates three instances of the Project set (the equivalent of creating three elements that is given the stereotype <<Project>> namely PrjA, PrjB and PrjC, this implies that the following ProjectTypes automatically exist (see report). The <<ProjectType>> set is therefore equal to: { PrjTpInst1, PrjTpInst2, PrjTpInst3, PrjTpInst4, PrjTpInst5, PrjTpInst6, PrjTpInst7, PrjTpInst8} as soon as new individual projects are created, the powertype is made larger. How does DM2 intend that these should be dealt with by a modeler creating a real model? Obviously only a few of the above subsets have any real use, the powertype however contains all possible subsets. From a meta-model perspective would it not be more clear to identify an element called ProjectCategory as a subset of ProjectType where the modeler is allowed to actually create categories as needed. Such an approach would give the individual modelers more control and since this argument can be put forward for all Powertypes in DM2 something similar could be done there as well. The Powertypes, when they are used can be viewed as abstract entities, never to be instantiated.

May be an difference between DM2 interpretation / implementation of PT and IDEAS. DM2 interprets pti as defining the possible values of PT, not filling or populating them.

Current DM2 def based on IDEAS: A Type that is the is the set (i.e., Type) of all subsets (i.e., subTypes)

that can be taken over the some Type.DM2 AI proposed change:A Type whose members are restricted to be from the set (i.e., Type)

of all subsets (i.e., subTypes) that can be taken over the some Type.

Verify: Type = IT TT PT

Will overlap/ OverlapType ever be harmonized with the IDEAS foundation since at present they are not the same?

Yes, when IDEAS Group reconvenes. # 466, Overlap is a tuple but does not indicate what it relates, it is not

aligned with IDEAS, Ian Bailey, 30-Oct-09, Adjudicatoin -- Consult IDEAS Group. Related to 158. Need to discuss with IDEAS Group

M3The use of namedBy, describedBy and representedBy needs to be discussed (see 2.4 as well as 2.7).

OK

Information is indicated as a Type, i.e. it is a set of sets. InformationType is its Powertype, i.e. it is the set of all subsets of a set of sets. Why is associationOfInformation attached to it, would it not be better to make use of Information instead if the intent of the element is to describe the structure of a particular kind of information type (an instance of the Information set). InformationType is not connected anywhere with the exception of the tuple and the powertype association. The same could be stated for DataType.

Record DM2 AI for what are currently are called Info Type and Data Type to be the resource types that flow in the resource flow model. This is because it is not the actual Individual Type Information that is modeled in the flow, but the TypeType. This requires a person to understand that the Individual information or data is at the utterance or copy level.

In the latest version of the model desiredEffectWholeResourcePartType has been moved to the side, i.e. it is no longer situated within an inheritance hierarchy. What purpose does this element have? It seems consistently to be in the wrong color in the model.

Looks like leftover from DesiredEffect structuring. Subtyped wrong, place positions wrong, unnecessary. Record DM2 AI.

Why have MeasureRange and MeasurePoint (integrated from IDEAS foundation up until the latest version), been deleted? (see also 2.6 in the report)

DM2 WG did not want to emphasize just two value ranges and went with more general setup. Need to record AI to discuss with IDEAS Group.

Why have measureOfIndividual been treated differently from MeasureOfType (see 2.6 in the report).

Put all subtypes of moI and moT on Measure diagram and do all associations to Measure via supertype, excepting those that go to a subtype of Measure. DM2 AI.

There is a need to get final confirmation regarding the rules described in paragraph 2.7 of the big report.

DM2 AI to add to PES/IDEAS description document and enforce in LDM or PES as possible.

Will the DM2 Naming and description pattern be brought in line with the IDEAS foundation?

DM2 AI to verify that it’s subclasses and add the omitted subclasses to the PES/IDEAS description document.

It has been stated previously that IndividualPerson is to be considered as meta-data. It is however still shown as part of the Performer data group. Does this mean that the use of IndividualPerson has changed?

No, IndividualPerson is not a DoDAF requirement except for AV-1. DM2 AI to remove from diagram; consider a metadata or AV-1-ish diagram in the metadata package. (Also note, Info Pedigree is actually part of design reification, not just metadata. Consider a design reification diagram. Also, note that infoPedigree may need to be resourcePedigree. An example of how this works would be good.)

M3The element rulePartOfMeasureType is defined as: "A couple that

represents the whole part relationship between types of measures and rules." This is strange since it descends from WholePartType which in turn descends from CoupleType. Furthermore MeasureType is a Powertype (of Measure). Measure is a set of sets, i.e. MeasureType is the set of all subsets of a set of sets. Rule is also a set of sets. Is an instance of the Rule set, i.e. for example set ruleA, really a part of the a set that is a subset of the set of sets that is Measure?

Rule should be constraining the Activity of MeasureType. Something that connects the MeasureType with the Activity of measuring, e.g., “measure mass”. DM2 AI and the recommend to consult with IDEAS Group.

The element measureOfTypeWholePartType appears in a number of places. Is the intent here to apply a measure onto a rules based approach of the WholePartType concept? Ians comment regarding the inability in general to apply measures to relationships needs to be noted here. Is anything intended to be done as regards this in the future?

DM2 AI system with Consult IDEAS Group status. Issue of counting and cardinality which seems to apply to the WP relationship, not to individual place positions.

In earlier versions of DM2, notably from October 2009 a significant amount of additional elements were included under the foundation folder in DM2. All of this has since been removed. What was the reason for this? It is the understanding of the author that the items contained acted as grounding for significant portions of the model, needed in order to handle things at Type level.

Yes, IDEAS specializes associations whereas DM2 uses inheritance. Related to association superclass rules. Might be some issues, none known at this time other than perhaps PersonType WPT [OT] PersonType. Related to DM2 AI’s # 373 and 470.

Capability is related to Performer via capabilityOfPerformer. This in turn is descended from propertyOfType which is defined as " A superSubtype that asserts an IndividualType is a subtype of a Property - i.e. it asserts all members of the Individual type "have" a property. Examples: All London Buses are red, All Porsche 911 2.2S have a mass between 900 and 960 kg.". In PropertyOfType <<place1Type>> is Property and <<place2Type>> is IndividualType. In capabilityOfPerformer <<place2Type>> is Performer which is a subset of Resource which in turn is a subset of IndividualType. <<place1Type>> is Capability which is a subset of IndividualType i.e. less restricted than the <<place1Type>> that propertyOfType links to since Property is a subset of IndividualType. The following therefore seems to be a valid question: Why is Capability not a subset of Property?

DM AI to either: make Capability a sub of Propertyrework the capabilityOfPerformer (1) remove and accomplish

via other Performer associations to desired effect Resource States, Activities, …(2) make the supertype an OT)

make Capability dual supertyped like MeasurableSkill

M3Capability connects to Resource via desiredEffectOfCapability which is

descended from WholePartType. Capability is descended from IndividualType, i.e. it is the set of sets where the instances of each of the sets it contains are entities that have a capability, i.e. some of these can easily contain individuals that are kinds of performers. There is no argument however concerning the need to have something that connects a capability to a desired outcome in the form of a state of a given resource. As an example taken from the SAR it would seem likely that the end desired effect of a Maritime search and rescue would be that the state of the resources that are in need of rescue is changed from "in need of rescue" to "rescued and safe" and that the state of the resource "a place of safety" is changed from having "no rescued" to "all in need rescued". This would however seem to imply a certain multiplicity as regards the resource. Is this assumption relating to multiplicity correct? The naming of the element gives the impression that it has something to do with desiredEffect which however is not the case. This would seem to require some handling to avoid misunderstandings. An associated element is effectMeasure and MeasureOfEffect. The definition of effectMeasure talks about desiredEffect in spite of the fact that there is no relationship to this element. A change of definition would seem to be in order here.

DM2 AI rec change desiredEffectOfCapability name to desiredFutureResourceStateOfCapability. Also, fix def of MeausreOfEffect to remove “desired.” Link to desiredEffectWholeResourcePartType.

DM2 AI Capability must have at least one of these. May also for Performer to say it must perform at least one Activity. Etc.

M3The use of the powertype CapabilityType requires some further discussion

since its utility is less than clear. Based on the definition it is automatically populated by the subsets of a set of sets (capability). The OverlapType descendent activityMapsToCapabilityType is also less obvious especially given its definition: "Represents that an activity was / is / can-be/ must-be conducted under certain conditions with a spatiotemporal overlap of the activity with the condition." which seems to be talking about something different. The fact that the element maps instances of a set of subsets (Activity) to instances of a set of subsets of a set of sets (CapabilityType) also needs to be considered.

CapabiltyType done for JCA’s, which aren’t really defined as Capabilities. What about making a JCA = union of the desiredEffects, Tasks/Activities, Conditions, etc. of the subs. Add to DM2 AI TypeType issue for ActivityType. axiom of reducibility was introduced by Bertrand Russell as part of his ramified theory of types

Either Type Types are removed along with activityMapsToCapabilityType or activityMapsToCapabilityType needs a new def.

But Lion Species

activitySuperSubtypeOfMeasureType is defined as: " activityType is a member of MeasureType". There is no element named activityType and this implies that the definition needs to be changed. Since Activity is the set of all subsets of IndividualActivity and MeasureType is the set of all subsets of a set of sets of Individual Measures, the connection is less than obvious and the author of this report would like to discuss this.

Def is incorrect or remove Type Type.

M3activityResourceOverlap is used to indicate flow of resources from one

activity to another. Since Resources are transferred this gives rise to some rather strange interactions given that Performer is a subset of Resource. As a result of this all elements that are subsets of Performer can flow between activities in addition to Materiel and Information (and all of its subsets), GeoPoliticalExtentType (and all of its subsets), i.e. System, Service, PersonType, OrganisationType, Port, ServicePort, GeoPoliticalExtentType (the subsets that are categorized properly). Is this really the intention?

How to split out the relevant pieces or indicate impossible couplings? How does this work in the XML with DF? AI to DM2WG

It is generally felt that the number of distinct elements that define how resources can be combined are few and far between and that unless foundational elements are made use of no really complex resource combinations can really be defined properly. The roles that the various entities play in different combinations are also not covered to any extent.

DM2WG to flush out missing relationships if guidance that higher term relationships (beforeAfter, wholePart) are for like classes only.

9 Apr 2010 DoDAF - DM2 WG Agenda1. Service Discussion with MOD

2. News:– FAC meeting this week

– JAIWG Federated Data Exchange Pilots Progress

– “M3 Incorporation of IDEAS” Meetings next week

– DoD Services Conference w/o 19 April

3. New References: • Baseline: DM2 VDD v2.01.doc

• DM2 WG Organizational and Meetings Information: FAC_meeeting__04_06_2010__Announcement_Agenda__V__2.2.doc and FAC_meeting__04_06_2010_BL_V_1.1 wDoDAF.ppt

4. Review new Action Items (“unassigned”)• Start with AIs 507-509 needed for JFCOM Federated Data Exchange

Pilots

5. Prioritization of 2.02 AI’s – in reverse order!

6. Others:– In queue but probably won’t have time to get to tomorrow:

• 20 SoAML terms to compare to DM2 data dictionary• TBS from WG tomorrow

Partridge Services

Analysis for MODAF

Service: A mechanism to enable access to a set of one or more capabilities , where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer.

There is no mandatory link between a service and much else. Why is there not a link to ServicePort? It seems to me that ServicePort is dependent upon Service. Is this just an oversight? I understand that ServicePort is introduced to allow for a ServiceDescription.

There seem to be (at least) three useful senses of Service:1) The set of potential and actual uses of the service by a ServiceConsumer.2) The set of potential and actual uses of service that conform to a specification.3) An implementation of the specification - of which there can be many. The set of potential and actual uses of service that conform to a specification provided by a ServiceProvider's implementation.

The OASIS description here would seem to intend sense 3).However, this can exclude multi-implemented Services - hence MoDAF uses sense 2).However, both sense 2) and 3) are parasitic on sense 1).

Note: Having Performer as a super-type of Service seems to exclude sense 2), as the fusion of multiple implementations would not fit the performer profile.

ServiceContract [New]: Not in DM2 - candidate. What motivates leaving this out?ServiceDescription: Information necessary to interact with the service in such terms as the service inputs, outputs, and associated semantics. The service description also conveys what is accomplished when the service is invoked and the conditions for using the service.

Potential representation issue: Do you provide a description of these or a description of a description of these?The link to ServicePort suggests that this is where the process of interacting with the ServicePort is described. Is it there somewhere the desired effect is described?There appears to be a possibility of misunderstanding, as this describes the ServicePort rather than the Service.

serviceEnablesAccessToResource: An overlap between the Service mechanism and the Performer capabilities it provides access to

Given the goal is a desired effect, rather than than the resources, is this describing the service or its implementation?

ServiceLevel: A measurement of the performance of a system or service.

Not on service diagram. This appears to have no links to Service. The links are at the higher Measure level. Is there intended to be a link?

ServicePort: A part of a Performer that specifics a distinct interaction point through which the Performer interacts with other Performers. This isolates dependencies between performers to particular interaction points rather than to the performer as a whole.

There does not seem to be any link to a Service here. One would expect that a Service Port was a Port that linked to a Service.

servicePortDescribedBy: A tuple that asserts that Information describes a Thing.

Typo [Text is a bit irrelevant - duplicates its parent]. Only a ServicePort has a description, not a service. What motivates this?

Must have Service End Point

Equipment part of human performer – Guard system or CapabilityConfig in MOD

MODAF Services Analysis

OASIS-RM[1] TOG-SO SoaML

a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.

A logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a “black box” to its consumers. (TOG-SSB also includes a second (different) definition: “A service is a repeatable activity that has a specified outcome”[2]. This effectively moves the definition down a level of representation.OASIS-RAF has no direct definition of a Service.)

Service is defined as a resource that enables access to one or more capabilities. Here, the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. This access is provided using a prescribed interface and is exercised consistent with all constraints and policies as specified by the service description. A service is provided by an entity - called the provider - for use by others. The eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. Identifies or specifies a cohesive set of functions or capabilities that a service provides.

[1] The OASIS-RM definition is used in DM2 and noted in M3.

What is odd in SoaML’s case, is that it appears to have two layers of access. There is a ServicePoint (see below) that provides access to the service and then the service that provides access to the resource – see the figure below.. It is not clear what the motivation for this is (apart from conforming to the UML MetaModel). Until a good motivation is provided. SoaML 7.3.11

ServicePoint A ServicePoint is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A ServicePoint defines the connection point through which a Participant offers its capabilities and provides a service to clients. Description A ServicePoint is a mechanism by which a provider Participant makes available services that meet the needs of consumer requests as defined by ServiceInterfaces, Interfaces, and ServiceContracts. A ServicePoint is represented by a UML Port on a Participant stereotyped as a “ServicePoint.”

MODAF Services Analysis

Guard Person Type

Radio

Fire & blanket

Radio

Binoculars

Call-in Service

Individual Guard System

Guard Person Type

Mouth and Ears

Mouth and Ears

Individual Guard System

Guard HQ System

Guard HQ System

AgreementPre-conditionsSteps

Biz nature of service – more workNCOIC --

NCOIC Anti-Piracy• Human parts – DoDAF not Human Factors and MoDAF

does• Competency and roles. Willingness and trust. • IDEAS – disposition and manifestation

• After SOA-RM was deep into the final approval process, it became obvious that one really needed to differentiate between the idea of “business service” and the “SOA service” that is all the rage as an IT artifact.  It was too late to add it to the RM but there was a discussion thread on the OASIS email list on this distinction.  I tend to emphasize it because I find it avoids conflating different definitions and keeps any discussion on track.

• I think the ServicePoint entered because a big part of WSDL is where is the endpoint.  In reality, the ServicePoint/endpoint is one piece of description about a (SOA) service.

• I agree that some, and probably most, of the Service Provider should be outside the Service box.• The TOG-SO definition of service seems to be more on the business side, being a “logical

representation” rather than an access mechanism.  However, the idea of a “specified outcome” aligns with the SOA-RM concept of real world effect.  Chris captures this point in the text following the SoaML ServicePoint definition box.

• Chris notes the “unorthodox” sense in which SOA-RM defines service.  This was done on purpose per the caveat in the section 1.4:

•Note that while the concepts and relationships described in this reference model may apply to other "service" environments, the definitions and descriptions contained herein focus on the field of software architecture and make no attempt to completely account for use outside of the software domain.  Examples included in this document that are taken from other domains are used strictly for illustrative purposes.

•  • In Chris’ final point about the taxi service, an imperfect analogy (refer again to the caveat about

examples) is the taxi service is an example of a capability that provides the business function of hired transportation, i.e. its business service.  The business service/capability can likely be accessed through several mechanisms: phone, maybe fax, possibly a Web form, or the traditional waving at a taxi driving by.  These access mechanisms are akin to the SOA service.  Note the power of this.  I have a capability but I may get greater value from it by changing the mechanism through which it can be accessed.  Maybe it will provide access through a Web service so a travel agent can automatically make a taxi reservation.  However, while the access mechanisms can change, there still needs to be a well-defined business function that needs to be satisfied and a well-defined implementation that can provide that function and realize its real world effects.  Without that, SOA or any other kind of access has nothing to access.  This leads to the common problem of trying to identify SOA services before your identify your business and how you expect to do it.

Ken’s Input to CP

Preparing to contract – execution contextTrust model – trust, risk, real-world effects

Legacy Combat System Analog

• What happens as a result, including “real-time” mini-negotiations

• Systems exchange data on AEGIS ships using real-time communications

– “real-time” negotiations (e.g., RTT’s, ACK’s, …)

DoD Policies -> Navy&DON Policies -> PEO-IWS Policies -> IWS-6 – PMS-400 MOA -> IDS IPT Rules of Conduct -> Software Engineering & Tesing Rules -> Communications Handshakes -> Information Exchange

• Program Manager A’s policy is such and such

• Program Manager B’s policy is such and such

Trust at a distance – social, organizational – ownership boundariesAbility to establish trust, e.g., as in a contract

DM2 Adjustments (DODAF WG)

Many minor model updates Desired Effect structure Design reification and requirements

traceability International Defence Enterprise

Architecture Specification (IDEAS) alignment

XML Schema Description (XSD) Format Beginning absorption of latest OASIS &

Object Management Group (OMG) SoA concepts

UNCLASSIFIED17

Action Item / Change Request

StatusQuantity

In Ver 2.00 231In Ver 2.01 68Consult IDEAS Group

12

Defer 102Unassigned 24In Progress for Ver 2.02

16

TOTAL 453

DODAF CM Plan (DODAF WG)

UNCLASSIFIED18

• Annex A: DoDAF Meta Model (DM2) Working Group (WG)

• Annex B: DoDAF Working Group (WG)

19

DoDAF / DM2 CM Plan• Adopts terminology and process from EIA Standard 649, “National Consensus

Standard for Configuration Management” • Contents:

– Configuration Identification– Organizational Roles, Responsibilities, and Interactions, e.g.,

• DoDAF / DM2 Work Group– The DoDAF 2 Data TWG became the DoDAF / DM2 WG– This group has been meeting every Friday since 2007 and has over 190 members and a very extensive

collaboration and research site

– DoDAF / DM2 CM Processes and Procedures, e.g., • Tracking of Change Requests• Monthly submission to FAC of Configuration Status Accounting Report (CSAR)

– DoDAF / DM2 CM Business Rules– DoD EA COI, e.g.,

• conduct of the DoD EA COI Data Management Working Group– DoDAF / DM2 Review of Federated Architectural Descriptions

Unassigned (New) AI’s• # Title• 476 Dispositional vs Categorical Properties• 477 SoAML Concepts• 478 OASIS SOA RAF Concepts• 479 Necessary and optional foundation elements in XML docs• 480 System vs Service • 481 Mandatory Service Descriptions and Ports• 482 Geostatoinary Point Type• 483 Region of World Type• 484 Project and Project Type have a TI and a PTI• 485 DesiredEffectWholeResourcePartType• 486 ARO as two couples• 487 Agreement constrains activityPerformedByPerformer• 488 Information Traceability to Data• 489 APBP redundancy with APUC• 500 Singleton Types• 501 Capability Phase <> Enterprise Phase• 503 Org/OrgType WP(T) Performer• 505 TV and StdV• 506 LocationType Measures• 507 TypeType…• 508 Forking under Conditions• 509 How to indicate methodology-dependent subclasses• 510 Coordinate AV-1 Defs with DARS• 511 How to categorize Arch Desc• 512 make the full inheritance taxonomy machine-accessible somehow, like in the XSD• 513 Partridge Services Questions & Comments• 514 M3 / LOK Questions and Comments• 515 Performer Flows and Tools• 516 Service Access to Resource or Performer• 517 Powertype Definition