Argumentation Metamodel Avatar
  1. OMG Specification

Argumentation Metamodel — All Issues

  • Acronym: ARM
  • Issues Count: 31
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SACM2-23 Properties as Assertions ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-17 Assurance Cases under development or Incomplete ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-18 Justification of Methods of Reasoning ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-19 Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-21 Making Role Binding and SBVR more generally available ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-16 Property Inherence Hierarchy ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-20 Properties of Model Elements must be Distinguished from Properties of what they Represent ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-22 Events should be able to be Associated with all Kinds of ModelElements ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM11-11 Events should be able to be Associated with all Kinds of ModelElements ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-10 Making Role Binding and SBVR more generally available ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-9 Property Inherence Hierarchy ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-8 Properties of Model Elements must be Distinguished from Properties of what they Represent ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-7 Properties as Assertions ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-4 Assurance Cases under development or Incomplete ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-12 Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-17 InformationAssertion Dependencies on other Elements ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-16 Multiple Fact types/Rolebindings in a Claim Statement ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-15 Need for Groups of Asserted Links ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-14 Usage of Specializations of Claim ARM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-13 Justification of Methods of Reasoning ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-36 Assurance case composed of assurance cases ARM 1.0b1 SACM 1.1 Resolved closed
SACM-164 Needed assurance case compliance point ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-163 Name AssertedEvidence ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-3 A more generally available "citation" capability ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-18 InformationAssertion’s and Informational Contents ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-17 Linking to Portions of an Artifact if this is what is Represented by a Model Element ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-16 Link to Actual Artifact Represented by Model Element ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-15 Hierarchical Collections of Artifacts or Other Items ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-14 Meaning of HasDependencyOn ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-13 Confidence as an Assertion ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-10 ArgumentReasoning available for more relations ARM 1.0b1 SACM 1.0b2 Resolved closed

Issues Descriptions

Properties as Assertions

  • Key: SACM2-23
  • Legacy Issue Number: 16505
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    The property elements of various kinds contain assertions concerning proper values for various properties (or attributes). Should they not therefore inherit from Assertion? This includes tagged values unless these are used to tag kinds of “annotations” instead of using general Annotation elements.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    While we have maintained a simple property model for Artefacts in SACM 2.0, and given more generally the opportunity to document TaggedValues on any model element, SACM 2 agrees with this comment and recognised that substantive assertions about artefacts / evidence should be documented as Claims. Communities of interest have the option of standardising particular structured expressions and vocabulary for claims using the Terminology package.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Assurance Cases under development or Incomplete

  • Key: SACM2-17
  • Legacy Issue Number: 16289
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    SACM standard must accommodate assurance cases under development as this is expected to be a common usage ­ transferring assurance cases among their developers or maintainers. This includes those incomplete.

    In addition to incompleteness, decisions may yet to be concerning option options including the type of certain relations ­ e.g. does an inference relation challenge or not. As the relative distinctions are not always known, particularly early in assurance cases construction, which currently abstract classes should be concrete classes should be reviewed and changed as required to accommodate this.

    Recording explicit options yet to be decided among (and optionally their effects) could be useful (and also relevant to patterns).

    More elements similar in name to the UnknownSubject might be included if required to meet this need.

  • Reported: ARM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    Incomplete models, as always, can be exchanged. In addition, SACM 2 has added a new attribute to the base ModelElement class called isAbstract. This allows any part of an SACM model to marked as a placeholder for later instantiation according to optionally provided ImplementationConstraints. Status / lifecycle information about whether a modelElement is, for example, ‘Agreed / Confirmed / Rejected’, could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package).

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Justification of Methods of Reasoning

  • Key: SACM2-18
  • Legacy Issue Number: 16514
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    How might and/or should the justification for an ArgumentReasoning element’s method(s) of argumentation be represented in SACM? Several options or possibilities exist. This justification might be a supplied by a Claim, a DescriptiveAssertion, or Assumption connected by an AssertedInference link or an AssertedConext link in turn potentionally supported by InformationElement, EvidenceElement, or Artifact. More generally justification for its method(s) of argumentation can be in the form of an assurance case. On the other hand might it be supplied by an AssertedContextLink to an Artifact or even simply a citation?

    What is the designers approach? Should these options be restricted or others used ­ particularly for the link between the ArgumentReasoning element and justification of its methods? Should some approaches be preferred?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    ArgumentReasoning is used in SACM 2.0 to describe AssertedRelations (e.g. AssertedInferences). These AssertedRelations can be justified with further supporting Assertions. ArgumentReasoning can optionally be fully documented as a structured argument with an associated ArgumentPackage. If this is done then, of course, it could be more fully justified.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims

  • Key: SACM2-19
  • Legacy Issue Number: 16511
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Claims and other items can have versions that simultaneously exist but have different meanings. For example, what a Claim might represent includes:
    • Required values
    • Planned values to be achieved
    • Supported (established, justified) values
    Two or more of these can be relevant at the same time.
    A suggestion has been made that SBVR be used (within associated properties?) to make this distinction. This would require that SBVR be available for these contents. Use of a TaggedValue is another possibility. Regardless of what mechanism is used, some standardization should be included for the key meanings.

    Placing this distinction within the contents of claim true-false statement might be more awkward and not make it as readily handled by tools as having it reside in a property.

    In any case, what is standardized needs to have precise definitions or distinguishable among multiple definitions (or explicitly made usage/implementation dependent?) as subtle variations in meaning are possible. Note that for some assertions differences might be entirely in the value for confidence.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    SACM 2 has added a new attribute to the base ModelElement class called isAbstract. This allows any part of an SACM model to marked as a placeholder for later instantiation according to optionally provided ImplementationConstraints. Status / lifecycle information about whether a modelElement is, for example, ‘Agreed / Confirmed / Rejected’, could also be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package).

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Making Role Binding and SBVR more generally available

  • Key: SACM2-21
  • Legacy Issue Number: 16509
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    SBVR should be available for use within element contents everywhere unless strong, explicitly recorded reason exists for excluding it.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    The underlying intent of this issue has been fundamental in shaping the redefinition of SACM 2.0. The authors agreed with the need to provide a means of establishing structured expressions and vocabulary for both the Artefact and Argumentation parts of SACM 2.0. These structured expressions can be standardized for communities of practice through common terminology packages. We decided to not use SBVR and the fact model approach of SBVR as the means of doing this because it was considered too heavyweight for our purposes.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Property Inherence Hierarchy

  • Key: SACM2-16
  • Legacy Issue Number: 16507
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    A simple, natural and appropriate set of properties would have Property (abstract?) inheriting from Assertion (or less preferably ModelElement) and having ModelElementProperty, RepesentedObjectProperty, Event, and Timing inheriting from it (Property) and appropriately associated. Artifacts and DomainObjects would use RepesentedObjectProperty’s. The two classes of properties are needed to allow properties associated with a model element and those associated with what it represents to be distinguished. Likewise ModelElementEvent and RepesentedObjectEvent inherit from Event. What type of event timing an instance is relevant to will be clear from what it is associated with. CM events and properties for both model elements and what they represent could be treated within this approach.

    Alternately, a usable set of properties could have Property inheriting from ModelElement and having ModelElementProperty, ArtifactProperty, DomainObjectProperty, Event, and Timing inheriting from it and appropriately associated. The three classes of properties are needed to allow properties associated with a model element and what it represents to be distinguished. Likewise ModelElementEvent, ArtifactEvent, and DomainObjectEvent inherit from Event. What type of event timing is relevant to will be clear from what it is associated with. CM events and properties could be treated likewise.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    In SACM 2.0 we have a clear ArtefactProperty class to capture properties of an Artefact. This, for example, is separate from the ability to attach UtilityElements to an Model Element (that can be used to capture Model Element Properties, e.g. using TaggedValue). Standardised vocabularies and expressions for domain properties can be captured using a Terminology package (which supports inheritance).

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Properties of Model Elements must be Distinguished from Properties of what they Represent

  • Key: SACM2-20
  • Legacy Issue Number: 16506
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Obviously, properties that apply to Model Elements must be distinguishable from Properties of what they represent. Both these kinds of properties appear in SACM models. The issues titled “Property Inherence Hierarchy” states a way of doing this.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    In SACM 2.0 we have a clear ArtefactProperty class to capture properties of an Artefact. This, for example, is separate from the ability to attach UtilityElements to an Model Element (that can be used to capture Model Element Properties, e.g. using TaggedValue). Standardised vocabularies and expressions for domain properties can be captured using a Terminology package (which supports inheritance).

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Events should be able to be Associated with all Kinds of ModelElements

  • Key: SACM2-22
  • Legacy Issue Number: 16510
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Not just exhibits have events that affect them or otherwise relate to them. This is also relavent to what the elements represent.

    An event might be associated with more than one element
    For example, one bug fix that simultaneously change several code exhibits/artifacts.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    In SACM 2.0 ArtefactEvents are optionally recorded as part of an Artefact’s description. They are intended to describe events relating to the artefact rather than events relating to the Artefact model element.

    Versioning of all of the other model elements lies outside the scope of the exchange model. Versioning information could be added to every model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). However, because there are many ways to maintain version information, we decided to not standardize this.

    The relationship of an Activity (e.g. fixing a bug) to multiple Artefacts can be recorded in SACM 2.0 as a many-to-one ArtefactActivityRelationship.

  • Updated: Tue, 19 Dec 2017 20:05 GMT

Events should be able to be Associated with all Kinds of ModelElements

  • Key: SACM11-11
  • Legacy Issue Number: 16510
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Not just exhibits have events that affect them or otherwise relate to them. This is also relavent to what the elements represent.

    An event might be associated with more than one element
    For example, one bug fix that simultaneously change several code exhibits/artifacts.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    There needs to be a clear distinction between properties of model elements and properties (assertions) concerning domain objects being represented. It also may be worth thinking in terms of contestable vs. uncontestable assertions. (There may be some fluidity between these two concepts depending on context.) Are properties merely uncontestable assertions? This issue should be taken forward with the resolution of the change management and version control issue (16281) and the resolution of the property vs. assertion issue (16506), which were both deferred in Ballot 4 (the 2nd Ballot of the SACM 1.1 RTF).

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Making Role Binding and SBVR more generally available

  • Key: SACM11-10
  • Legacy Issue Number: 16509
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    SBVR should be available for use within element contents everywhere unless strong, explicitly recorded reason exists for excluding it.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    The RTF still recognize the important of supporting structured expressions (as could be done with SBVR). However, it has not been possible to harmonise the evidence part’s use of SBVR with an approach to use in the argument part.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Property Inherence Hierarchy

  • Key: SACM11-9
  • Legacy Issue Number: 16507
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    A simple, natural and appropriate set of properties would have Property (abstract?) inheriting from Assertion (or less preferably ModelElement) and having ModelElementProperty, RepesentedObjectProperty, Event, and Timing inheriting from it (Property) and appropriately associated. Artifacts and DomainObjects would use RepesentedObjectProperty’s. The two classes of properties are needed to allow properties associated with a model element and those associated with what it represents to be distinguished. Likewise ModelElementEvent and RepesentedObjectEvent inherit from Event. What type of event timing an instance is relevant to will be clear from what it is associated with. CM events and properties for both model elements and what they represent could be treated within this approach.

    Alternately, a usable set of properties could have Property inheriting from ModelElement and having ModelElementProperty, ArtifactProperty, DomainObjectProperty, Event, and Timing inheriting from it and appropriately associated. The three classes of properties are needed to allow properties associated with a model element and what it represents to be distinguished. Likewise ModelElementEvent, ArtifactEvent, and DomainObjectEvent inherit from Event. What type of event timing is relevant to will be clear from what it is associated with. CM events and properties could be treated likewise.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    RTF agree that the standard needs to make a sharper distinction between ‘uncontestable’ properties and assertions made (e.g. about evidence). In addition, there needs to be a clear distinction between properties of model elements and properties (assertions) concerning domain objects being represented. All assertions should inherit off a based Assertion class. To achieve this in SACM 1.1 would require a major reorganization of the standard that would significantly break backwards compatibility.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Properties of Model Elements must be Distinguished from Properties of what they Represent

  • Key: SACM11-8
  • Legacy Issue Number: 16506
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Obviously, properties that apply to Model Elements must be distinguishable from Properties of what they represent. Both these kinds of properties appear in SACM models. The issues titled “Property Inherence Hierarchy” states a way of doing this.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    RTF agree that the standard needs to make a sharper distinction between ‘uncontestable’ properties and assertions made (e.g. about evidence). In addition, there needs to be a clear distinction between properties of model elements and properties (assertions) concerning domain objects being represented. All assertions should inherit off a based Assertion class. To achieve this in SACM 1.1 would require a major reorganization of the standard that would significantly break backwards compatibility.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Properties as Assertions

  • Key: SACM11-7
  • Legacy Issue Number: 16505
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    The property elements of various kinds contain assertions concerning proper values for various properties (or attributes). Should they not therefore inherit from Assertion? This includes tagged values unless these are used to tag kinds of “annotations” instead of using general Annotation elements.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    RTF agree that the standard needs to make a sharper distinction between ‘uncontestable’ properties and assertions made (e.g. about evidence). All assertions should inherit off a based Assertion class. To achieve this in SACM 1.1 would require a major reorganization of the standard that would significantly break backwards compatibility.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Assurance Cases under development or Incomplete

  • Key: SACM11-4
  • Legacy Issue Number: 16289
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    SACM standard must accommodate assurance cases under development as this is expected to be a common usage ­ transferring assurance cases among their developers or maintainers. This includes those incomplete.

    In addition to incompleteness, decisions may yet to be concerning option options including the type of certain relations ­ e.g. does an inference relation challenge or not. As the relative distinctions are not always known, particularly early in assurance cases construction, which currently abstract classes should be concrete classes should be reviewed and changed as required to accommodate this.

    Recording explicit options yet to be decided among (and optionally their effects) could be useful (and also relevant to patterns).

    More elements similar in name to the UnknownSubject might be included if required to meet this need.

  • Reported: ARM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    The validity of this issue is still recognized. Providing full support for the issue as described requires support for exchanging assurance case patterns / templates. It has not been possible to implement this support in the current revision.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims

  • Key: SACM11-12
  • Legacy Issue Number: 16511
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Claims and other items can have versions that simultaneously exist but have different meanings. For example, what a Claim might represent includes:
    • Required values
    • Planned values to be achieved
    • Supported (established, justified) values
    Two or more of these can be relevant at the same time.
    A suggestion has been made that SBVR be used (within associated properties?) to make this distinction. This would require that SBVR be available for these contents. Use of a TaggedValue is another possibility. Regardless of what mechanism is used, some standardization should be included for the key meanings.

    Placing this distinction within the contents of claim true-false statement might be more awkward and not make it as readily handled by tools as having it reside in a property.

    In any case, what is standardized needs to have precise definitions or distinguishable among multiple definitions (or explicitly made usage/implementation dependent?) as subtle variations in meaning are possible. Note that for some assertions differences might be entirely in the value for confidence.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    This can be handled at present using the adhoc mechanism of TaggedValue. However, it is recognized that a more systematic solution is desirable. It is recognized that multiple stakeholders may have various roles with respect to assurance case elements (e.g. proposer, reviewer, endorsement). In addition, it could be useful to link these roles to a lifecycle model (similar to that proposed for Evidence in Section 7.7). This issue should be taken forward with the resolution of the change management and version control issue (16281), which was deferred in Ballot 4 (the 2nd Ballot of the SACM 1.1 RTF).

  • Updated: Tue, 21 Apr 2015 01:16 GMT

InformationAssertion Dependencies on other Elements

  • Key: SACM11-17
  • Legacy Issue Number: 16521
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    An InformationAssertion, particularly a ResultsAssertion, will commonly depend on other elements particularly EvidenceElements and Artifacts. These can be shown by AssertedLinks, but hould they also be able to be shown by HasDependenceOn.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    InformationAssertion is not an element in the released SACM 1.0.

    The comment/issue was against an element that didn't end up in the published SACM 1.0 release.

    This issue is N/A.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Multiple Fact types/Rolebindings in a Claim Statement

  • Key: SACM11-16
  • Legacy Issue Number: 16519
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Claim true-false statements in SBVR can contain a variety of kinds of concerns. A variety of terms and values can occur. The diagram appears to show/allow only one facttype. Is this appropriate?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    Whilst it is understood that Claims (and EvidenceAssertions etc.) could be categorized with multiple types, it is also understood that as a statement in SBVR it must be said to be associated with just one facttype (i.e. facttype defines the template that the claim expression must conform to).

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Need for Groups of Asserted Links

  • Key: SACM11-15
  • Legacy Issue Number: 16518
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Asserted links are already one-to-many, but only one is allowed at the supported-by (single) end. However, a strong case can be made for being able to have multiple ones and being able to group them. Substantial discussions both leading to the conclusion this should be included occurred during two FTF meetings ­ most recently in June 2011. Unfortunately, this occurred as the last discussion at the June meeting and exactly how best to do it (e.g. element names) evidentially due to time constraints was not judged firmly enough agreed upon to appear in the diagram resulting from this meeting.

    This still needs to be included/finalized.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    Current arrangement for AssertedRelationship has 0..* source, and 0..* target. No additional constraints are given. Consequently it is possible to have multiple 1..* AssertedRelationships.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Usage of Specializations of Claim

  • Key: SACM11-14
  • Legacy Issue Number: 16517
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    May a specialization of Claim element appear anywhere a Claim may? and vice versa? In June Day 2 diagram allows Calims in Augumentation elements but not InformationElements. However, InformationAssertions can appear both places. What is the reasoning behind this?

    One might consider questions such as: For example, do restrictions exist on where an InformationAssertion may appear? Why should not a Claim element be used in place of each of the kinds or elements that inherit from it (e.g. in 2011 June Day 2)?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    May a specialization of Claim element appear anywhere a Claim may? and vice versa? In June Day 2 diagram allows Claims in Augumentation elements but not InformationElements. InformationAssertions can appear both places. What is the reasoning behind this?

    This issue has gone away because of the resolution to Issue 16838 (SR-24) that has now removed EvidenceAssertion as a specialization of Claim.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Justification of Methods of Reasoning

  • Key: SACM11-13
  • Legacy Issue Number: 16514
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    How might and/or should the justification for an ArgumentReasoning element’s method(s) of argumentation be represented in SACM? Several options or possibilities exist. This justification might be a supplied by a Claim, a DescriptiveAssertion, or Assumption connected by an AssertedInference link or an AssertedConext link in turn potentionally supported by InformationElement, EvidenceElement, or Artifact. More generally justification for its method(s) of argumentation can be in the form of an assurance case. On the other hand might it be supplied by an AssertedContextLink to an Artifact or even simply a citation?

    What is the designers approach? Should these options be restricted or others used ­ particularly for the link between the ArgumentReasoning element and justification of its methods? Should some approaches be preferred?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    On further discussion, this issue was determined as being supported by the current SACM 1.0 structure, by means of a) being able to have an associated Argumentation structure to a ArgumentReasoning element (and that this structure – alongside presenting the expansion of the reasoning of the reasoning step (e.g. AssertedInference) – could also present backing for that reasoning) and b) being able to provide backing directly for a reasoning step by means of presenting an AssertedInference (or AssertedEvidence) in support of an AssertedInference (or AssertedEvidence). The issue of the ‘reusability’ of a generic piece of reasoning that is associated to an Argument Reasoning step is connected with the provision of generic but instantiable argument patterns. (Side note thought about Argument patterns requiring a peer concept to Argumentation – e.g. called ‘ArgumentationPattern’ that with the application / association of the necessary information to instantiate can fulfill the same role as ‘Argumentation’.

  • Updated: Tue, 21 Apr 2015 01:16 GMT

Assurance case composed of assurance cases

  • Key: SACM11-36
  • Legacy Issue Number: 16880
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    An assurance case should be able to be composed of assurance cases. This can both math the history of development of the larger assurance case and potentially be a mechanism facilitating structuring and reuse.

  • Reported: ARM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    An assurance case should be able to be composed of assurance cases. This can both math the history of development of the larger assurance case and potentially be a mechanism facilitating structuring and reuse.

    The existing packaging of evidence, and reflexive composition (nesting) of Argumentation structures remains valid. Therefore an additional composition association is proposed on the AssuranceCase class to support the hierarchical composition of AssuranceCases

  • Updated: Tue, 21 Apr 2015 01:16 GMT
  • Attachments:

Needed assurance case compliance point

  • Key: SACM-164
  • Legacy Issue Number: 16881
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    A compliance point is needed that combines ARM and simply Exhibit/Artifact thereby providing the minimum needed for an assurance case and also essentially matching several existing tools.

  • Reported: ARM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This resolution has been merged with 16857.
    Disposition: Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name AssertedEvidence

  • Key: SACM-163
  • Legacy Issue Number: 16879
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    “AssertedEvidentiary” might be better than “AssertedEvidence”. Another less prevalent term is “evidential”.

  • Reported: ARM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Rejected - keep as ARM
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A more generally available "citation" capability

  • Key: SACM-3
  • Legacy Issue Number: 16288
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    A generally available "citation" capability is needed. This should be able to refer to points throughout the assurance case and outside. This is particularly required inside ArgumentDescriptions, Context, and narrative elements but potentially useful essentially everywhere throughout SACM. In addition to all the merits of referencing, it is potentially a means to avoid duplication.

    How to do this from within an ArgumentDescription such as to localize within the referring element may require a different kind of mechanism than one that is associated with the element as a whole. Although not necessarily as critical, being able to cite a portion of an element is also important.

  • Reported: ARM 1.0b1 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Add the following to attributes subsection of 11.1.2 Document, page 43:
    citation:String The full citation of the document (bibliographical reference)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InformationAssertion’s and Informational Contents

  • Key: SACM-18
  • Legacy Issue Number: 16520
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    May InformationAssertion’s contain explanatory or contextual material as well as assertion.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Existing mechanisms exist for annotation, and providing contextual relations to information. This is
    unchanged from ARM. TaggedValue and Annotation mechanism is made universal across SACM (per
    resolution of the issue 16836).
    There is no longer an element InformationAssertion. There is an InformationElement, which may contain a
    reference to an EvidenceItem, and an abstract element called Assertion, which has a concrete subclass
    called Claim, and another set of subclasses related to an AssertedRelationship.
    It should be discouraged to use the TaggedValue mechanism to add assertion to an InformationElement,
    since this violates the nature of the SACM as a structured approach to exchanging assurance cases -
    subclasses of Assertion element should be used instead.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Linking to Portions of an Artifact if this is what is Represented by a Model Element

  • Key: SACM-17
  • Legacy Issue Number: 16516
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    For example, a ResultsAssertion may be detailed in only a portion or portions of an artifact (or artifacts). Whether mapped via an Artifact or not, how are this or these linked to so that the scope is clear? A means is needed.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    If you need to reference a portioned item, you need an artifact. Can use tagged values and annotation to
    include other referencing information No further action planned The relationship between the artefact and
    the EvidenceAssertion is made clear by the association. REJECT.
    The SACM Evidence Metamodel provides more detailed solution.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Link to Actual Artifact Represented by Model Element

  • Key: SACM-16
  • Legacy Issue Number: 16515
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    How does a model element link to what it represents, in particular, to an actual artifact? Is it via using Artifact element? If so, what kind of links are used to link to appropriate Artifact element(s)? Issue includes how do Artifact elements link to actual artifacts. In addition, how this is done needs to be explained in standard.

    Note that duplication of contents should be avoided, and duplication of the contents of artifacts’ bodies never required.

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Accessibility achieved by Location: URN Question of how to characterize the identity of the “artifact-assuch”,
    as well as its URN. May need a “name” attribute for the “source” class (Issue raised) SUGGESTED
    MODIFICATION: Add identification to Exhibit Change name of 'url' attribute to 'location' keep as string.
    In text will need to comment on the relationship to chain of custody
    DRAFT EDIT: No action on changing the attribute, however add cross reference to custody section to
    remind reader there is infrastructure for other kinds of location information.
    Resolution to this issue is provided as part of the accumulated model changes resolution
    17347, where both a link to an EvidenceItem element as well as a url are added to the
    InformationElement.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Hierarchical Collections of Artifacts or Other Items

  • Key: SACM-15
  • Legacy Issue Number: 16513
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Artifacts ­ e.g. documentation, test results, components ­ are often organized into subsets (of all artifacts) and subsuming subsets and these sets given labels and treated for some purposes as units. EvidenceElements and InformationElements are not shown as being possible to structure in this way (say by a looped composition or association “arrow”). Some structuring mechanism is needed for this.

    In addition, non-hierarchical structures also have uses

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Response: Check with TPK whether we intended to edit the model to include a self-inclusion loop on
    InformationElement? For non-hierarchichal structures can use “nature of dependency” RESOLUTION:
    This is already allowed in SAEM (and that's what we're sticking with)
    The SACM Evidence Metamodel provides a detail mechanism for achieving this (called EvidenceGroup).
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of HasDependencyOn

  • Key: SACM-14
  • Legacy Issue Number: 16512
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    Various meanings would appear possible including:
    • Version derives from prior version
    • Version derives from these versions of items
    • Copy
    • Uses information from
    • Conclusion based on
    • Change together or should change if other changes
    • Uses
    • Subsumes
    • Compiled from or otherwise results from tool processing of
    • Analysis result regarding
    • Obtains resources from
    • Share contents
    This list is by no means exhaustive and not all may apply to a set of exhibits/artifacts of interest, but having some relations with more restricted meanings than HasDependencyOn or standardizing vaules for natureofdependency would be useful for key kinds of dependencies, e.g. is version derived from. Apparently, as natures of dependencies could vary multiple relations related to a single dependent element must be allowed.
    Fanally, should:
    • Values for natureofdependency that duplicate meanings of AssertedLinks be allowed?
    • HasDependencyOn inherit from AssertedLinks (or less preferably just Assertion)?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    add the following text to Semantics subsection of 11.1.8 IsBasedOn, page 46:
    Derivation of one Document from another can have various meanings including, but not limited to the
    following:
    • Version derives from prior version
    • Version derives from these versions of items
    • Copy
    • Uses information from
    • Conclusion based on
    • Change together or should change if other changes
    • Uses
    • Subsumes
    • Compiled from or otherwise results from tool processing of
    • Analysis result regarding
    • Obtains resources from
    • Share contents
    This list is by no means exhaustive and not all may apply to a set of exhibits of interest. Apparently, as
    natures of dependencies could vary multiple relations related to a single dependent element are possible.
    The SACM Evidence Metamodel does not provide a normative enumeration of the nature of dependency.
    However, should an author of a SACM document desire so, a TaggedValue mechanism shall be used for
    this purpose with a tag 'natureofdependency'.
    Add the following text to section 15.2.6 DependsOn, page 97:
    Dependency of one ProjectElement on another can have various meanings. The SACM Evidence
    Metamodel does not provide a normative enumeration of the nature of dependency. However, should an
    author of a SACM document desire so, a TaggedValue mechanism shall be used for this purpose with a tag
    'natureofdependency'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confidence as an Assertion

  • Key: SACM-13
  • Legacy Issue Number: 16508
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    A Confidence element contains an assertion concerning proper confidence. Should it not therefore inherit from Assertion?

  • Reported: ARM 1.0b1 — Thu, 25 Aug 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Authors response: Although every property can be considered to be asserted, SACM focus is on argument
    structuring elements. Therefore no change made. Decision: This is not how represented in ARM or SAEM

    • REJECT
      Disposition: Closed, no change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ArgumentReasoning available for more relations

  • Key: SACM-10
  • Legacy Issue Number: 16299
  • Status: closed  
  • Source: MITRE ( Samuel Redwine)
  • Summary:

    ArgumentReasoning should be allowed to describe any kind of AssertedRelationship ­ most importantly describe AssertedChallange, which is equivalent to the opposite of AssertedInference. This element might also be used in SAEM derived material to avoid duplication.

  • Reported: ARM 1.0b1 — Mon, 30 May 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This issue is resolved as part of the accumulated model improvement, esp. resolution 17347. The updated
    Argumnetation Metamodel includes element AssertedChallenge. Also the Evidence Metamodel includes a
    related element Challenges.
    Disposition: Closed, not change

  • Updated: Fri, 6 Mar 2015 20:58 GMT