1. OMG Mailing List
  2. Structured Assurance Case Metamodel (SACM) 1.2 Revision Task Force

All Issues

  • All Issues
  • Name: sacm-rtf
  • Issues Count: 85

Issues Summary

Key Issue Reported Fixed Disposition Status
SACM2-30 Inconsistent naming of class SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-81 Typo in reference to ISO/IEC 15026 SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-23 Properties as Assertions ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-29 SBVR should be available in SACM for use wherever this would make sense SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-26 Ownership needs improved representation SAEM 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-28 Scope of availability of change management information SAEM 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-12 We are missing an SBVR vocabulary for ARM SACM 1.0 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-14 Integration Issue: Inconsistency in level of prescription in the models SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-13 Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel SACM 1.0 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
SACM2-15 combined standard should include a vocabulary for talking about standards of proof SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-11 There is no support for patterning, which is found to be useful current practice. SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-5 prefixes in the SAEM 'Evidence.... SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-1 Add missing definitions to SBVR Vocabulary in Annex A SACM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-33 Apparently spurious associations on class diagram SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-32 Superclass in text is inconsistent with diagram SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-8 Issue: No approach to allowing Structured Expression of Claims within ARM SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-6 No method of handling confidence in the ARM SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-2 Integration Issue: Inconsistent approaches to handling counter argument and evidence SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-10 Integration Issue: Inconsistent terminology SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-9 Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-3 Page73 ,section 13.2, figure21 SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-27 EvidenceProperty inherit from Property SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-4 Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ... SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-7 fundamental difference in modelling style of each metamodel SACM 1.0 SACM 2.0 Closed; No Change closed
SACM2-31 Reference to non-existent class SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-25 Uncertainty characteristic for claims SAEM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-24 Identifying nature of element contents SAEM 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-6 SBVR should be available in SACM for use wherever this would make sense SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-5 Ownership needs improved representation SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-4 Assurance Cases under development or Incomplete ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-3 Uncertainty characteristic for claims SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-2 Scope of availability of change management information SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-1 Need for general facility for stating and handling issues SAEM 1.0b1 SACM 1.1 Closed; No Change 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-44 "ArgumentResoning" Class and "Assertedinferce" Class SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-43 AssertedRelationship Class SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-34 All associations need to be labeled with a verb SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-33 combined standard should include a vocabulary for talking about standards of proof SACM 1.0 SACM 1.1 Deferred closed
SACM11-32 Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ... SACM 1.0 SACM 1.1 Deferred closed
SACM11-31 There is no support for patterning, which is found to be useful current practice. SACM 1.0 SACM 1.1 Deferred closed
SACM11-30 fundamental difference in modelling style of each metamodel SACM 1.0 SACM 1.1 Deferred closed
SACM11-29 prefixes in the SAEM 'Evidence.... SACM 1.0 SACM 1.1 Deferred closed
SACM11-28 Issue: No approach to allowing Structured Expression of Claims within ARM SACM 1.0 SACM 1.1 Deferred closed
SACM11-27 No method of handling confidence in the ARM SACM 1.0 SACM 1.1 Deferred closed
SACM11-26 Integration Issue: Inconsistent approaches to handling counter argument and evidence SACM 1.0 SACM 1.1 Deferred closed
SACM11-25 Integration Issue: Inconsistency in level of prescription in the models SACM 1.0 SACM 1.1 Deferred closed
SACM11-24 Integration Issue: Overlapping scope SACM 1.0 SACM 1.1 Resolved closed
SACM11-23 Integration Issue: Inconsistent terminology SACM 1.0 SACM 1.1 Deferred closed
SACM11-22 Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel SACM 1.0 SACM 1.1 Deferred closed
SACM11-21 Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel SACM 1.0 SACM 1.1 Deferred closed
SACM11-20 Page73 ,section 13.2, figure21 SACM 1.0 SACM 1.1 Deferred closed
SACM11-19 ARM: Page 20, section 8.2.17 SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-18 ARM: Page 18, section 8.2.14 SACM 1.0 SACM 1.1 Resolved 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-93 editing error & typo in 10.1.1 & 10.2.3 SACM 1.0 SACM 1.1 Resolved closed
SACM11-91 typo: facctype section 12.3.1 SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-85 AssertedRelationship Class SACM 1.0 SACM 1.1 Resolved closed
SACM11-84 "ArgumentResoning" Class and "Assertedinferce" Class SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-83 Replace Individual Class Examples with Single Integrated Example SACM 1.0 SACM 1.1 Resolved closed
SACM11-82 Rationalizing Citations within the Argumentation structure SACM 1.0 SACM 1.1 Resolved closed
SACM11-81 ArgumentReasoning associations with AssertedRelations SACM 1.0 SACM 1.1 Resolved closed
SACM11-42 Use uniform 'statement' language for describing evidence properties SACM 1.0b1 SACM 1.1 Resolved closed
SACM11-41 Add missing definitions to SBVR Vocabulary in Annex A SACM 1.0b1 SACM 1.1 Deferred closed
SACM11-40 Need examples of the Evidence Metamodel XMI SACM 1.0b1 SACM 1.1 Resolved closed
SACM11-39 Use name "Artfact" rather than Exhibit" SAEM 1.0b1 SACM 1.1 Closed; No Change closed
SACM11-38 Identifying nature of element contents SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-37 EvidenceProperty inherit from Property SAEM 1.0b1 SACM 1.1 Deferred closed
SACM11-36 Assurance case composed of assurance cases ARM 1.0b1 SACM 1.1 Resolved closed
SACM11-35 We are missing an SBVR vocabulary for ARM SACM 1.0 SACM 1.1 Deferred closed

Issues Descriptions

Inconsistent naming of class

  • Key: SACM2-30
  • Legacy Issue Number: 19868
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The class is described as ArgumentElementCitation in the section title, but CitationElement in the body text. For consistency with InformationCitationElement, it is probably supposed to be ArgumentCitationElement

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Closed, no change.

    As part of the SACM 2.0 update we addressed all inconsistent class naming in SACM 1.0. The particular classes discussed in this issue are no longer in SACM.

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

Typo in reference to ISO/IEC 15026

  • Key: SACM2-81
  • Status: closed  
  • Source: Luxembourg Institute of Science and Technology ( Eric Grandry)
  • Summary:

    In Semantics sub-section, the text refers to ISO/IEC 15026, but it is written:
    "An AssuranceCase element represents assurance cases as defined in ISO/IEC 15206."
    It should be written:
    "An AssuranceCase element represents assurance cases as defined in ISO/IEC 15026."

  • Reported: SACM 1.1 — Wed, 28 Dec 2016 15:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    As part of the SACM 2.0 update the sub-section in question was rewritten and the typo referred to, that was present in SACM 1.1, was removed.

    As part of the SACM 2.0 update the sub-section in question was rewritten and the typo referred to, that was present in SACM 1.1, was removed.

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

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

SBVR should be available in SACM for use wherever this would make sense

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

    SBVR should be available in SACM for use wherever this would make sense. This includes in (ARM) claims and ReasoningElements and in SAEM many assertions particularly claims and possible rationales. Wherever narrative or prose, or mathematical expressions are allowed, why not also allow SBVR (and some places graphics or even other media also) unless strong reasons exist for doing otherwise?

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 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 did 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

Ownership needs improved representation

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

    The following aspects need to be accommodated:
    Owning, creating, and approving can be done concurrently by multiple entities and different (sets of) entities over time.

    Ownership can be divided unequally among owners and fractions could need to be recorded.

    Ownership can have aspects, for example IP rights versus physical object ­ I own the book, but not its copyright.

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    SACM 2 allows explicit representation of Participants in the Artefact model. This allows the representation of stakeholders. It also now provides a very flexible means of documenting multiple relationships (using ParticipantRoleRelationship) between Artefacts and Participants.

  • 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

Scope of availability of change management information

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

    Timing or change management information needs to be able to be associated with anything as anything can change over time. This includes for example with Attributes (and any Properties). In addition, how to best handle changes and change information over time needs to be reviewed throughout SACM.

    The version and change management related information ­ although often kept in a CM system ­ needs to be exchangeable along with an assurance case. At least one exchange standard for CM information exists, TECHAMERICA EIA-836B: Configuration Management Data Exchange and Interoperability, publication date: Mar 1, 2010. It is reportedly both ANSI and DoD approved. (http://engineers.ihs.com/document/abstract/BMVKACAAAAAAAAAA) One option is for this to be appropriately included by reference.

    Versioning should be available for everything. Identification and “HasVersion” attribute should be associated with a near root element, or this availability should be achieved in some other fashion. The standard should not restrict its availability and smallness of possible granularity of elements it may be applied to.

  • Reported: SAEM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    This level of fine grained versioning is outside the scope of SACM.

    Versioning has been maintained as an attribute for the Artefact class, because in SACM’s management of evidence we are responsible for ensuring the complete and correct management of the artefact inventory. However, versioning of all of the other model elements lies outside the scope of the exchange model.

    Comment – there must be other fine-grained model management / versioning standards) 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.

  • 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

We are missing an SBVR vocabulary for ARM

  • Key: SACM2-12
  • Legacy Issue Number: 16864
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    We are missing an SBVR vocabulary for ARM (authors view - this is work someone else
    to do, maybe close/postpone)

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    We are no longer using SBVR.

  • 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

Integration Issue: Inconsistency in level of prescription in the models

  • Key: SACM2-14
  • Legacy Issue Number: 16841
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistency in level of prescription in the models (e.g. raised by Jeremy). E.g. arm does not prescribe what kinds of claims, instead SAEM has more presciption of the subtypes of

    claims.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    As part of the SACM 2.0 update we removed much of the prescription of domain-specific content in the artefact model of SACM. In particular, we avoided prescription where there was no industry consensus on the ways in which artefacts should be described. Instead, SACM 2.0 focuses on providing a standardised exchange model format within which description can be customized (see Description element of ModelElement) for communities of interest using user-defined vocabularies and structured expressions.

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

Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel

  • Key: SACM2-13
  • Legacy Issue Number: 16781
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    SupportLevel enumeration has been removed. In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

  • 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

combined standard should include a vocabulary for talking about standards of proof

  • Key: SACM2-15
  • Legacy Issue Number: 16861
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    combined standard should include a vocabulary for talking about standards of proof

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

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

There is no support for patterning, which is found to be useful current practice.

  • Key: SACM2-11
  • Legacy Issue Number: 16853
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    There is no support for patterning, which is found to be useful current practice.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05: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. This allows us to represent Argumentation and Artefact patterns as models. The full documentation of these patterns lies outside the scope of SACM, but was recognized as being possible using SPMS referring to these SACM models.

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

prefixes in the SAEM 'Evidence....

  • Key: SACM2-5
  • Legacy Issue Number: 16849
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    The name 'Evidence' implies a certain association between some Information / some artefact and some claim. In ARM it was recognised that information can be used both to define context and as

    supporting evidence to an assertion. This suggests that many of the prefixes in the SAEM 'Evidence....' should be changed to allow them to more generally refer to Information (and specialise to Evidence if

    required)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05: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 changed the use of the term ‘Evidence’ to become ‘Artefact’ to avoid this problem.

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

Add missing definitions to SBVR Vocabulary in Annex A

  • Key: SACM2-1
  • Legacy Issue Number: 17335
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    The SBVR vocabulary for evidence in Annex A is missing several definitions.

  • Reported: SACM 1.0b1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    SACM 2.0 is no longer using the SBVR approach.

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

Apparently spurious associations on class diagram

  • Key: SACM2-33
  • Legacy Issue Number: 19870
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    Figure 9.1 shows associations between ArgumentReasoning and AssertedInference, and between ArgumentReasoning and AssertedChallenge, which are not described in the text. Because these can be captured by the association between ArgumentReasoning and AssertedRelationship, I assume they are spurious

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Spurious associations removed

    These spurious associations have been removed and are no longer present in SACM.

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

Superclass in text is inconsistent with diagram

  • Key: SACM2-32
  • Legacy Issue Number: 19867
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The superclass of ArgumentElement is shown as ModelElement in the text but as ArgumentationElement in figure 9.1 on page 27.

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Diagram and text use same name.

    ArgumentAsset (the new name for ArgumentElement) now refers to the superclass as ArgumentationElement in both the diagram and text.

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

Issue: No approach to allowing Structured Expression of Claims within ARM

  • Key: SACM2-8
  • Legacy Issue Number: 16844
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Issue: No approach to allowing Structured Expression of Claims within ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05: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 no longer make use of 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

No method of handling confidence in the ARM

  • Key: SACM2-6
  • Legacy Issue Number: 16843
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    No method of handling confidence in the ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

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

Integration Issue: Inconsistent approaches to handling counter argument and evidence

  • Key: SACM2-2
  • Legacy Issue Number: 16842
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent approaches to handling counter argument and evidence. Both standards have evaluation mechanisms (e.g. refuting, rebutting mechanisms)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    There were a number of examples where evidence relationships were considered to be more appropriately represented as being between Claims regarding Artefacts. These relationships between Claims are now represented in SACM 2.0 only using the AssertedRelations of the argumentation parts of SACM.

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

Integration Issue: Inconsistent terminology

  • Key: SACM2-10
  • Legacy Issue Number: 16837
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent terminology

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    As part of the SACM 2.0 update we addressed all inconsistent terminology that was present in SACM 1.0. This was one of the primary drivers of the update was to address this.

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

Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel

  • Key: SACM2-9
  • Legacy Issue Number: 16807
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    Contributes is an example of a relationship that was considered to be more appropriately represented as being between Claims regarding Artefacts. These relationships between Claims are now represented in SACM 2.0 only using the AssertedRelations of the argumentation parts of SACM.

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

Page73 ,section 13.2, figure21

  • Key: SACM2-3
  • Legacy Issue Number: 16712
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Some of the concepts being captured in the model here overlap quite strongly with those of
    Configuration Management, and would probably best left to standards in that domain rather
    than creating a conceptual overlap here.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    Versioning has been maintained as an attribute for the Artefact class, because in SACM’s management of evidence we are responsible for ensuring the complete and correct description of the artefact inventory. However, 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.

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

EvidenceProperty inherit from Property

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

    With integration EvidenceProperty inherit from Property as should all properties - directly or indirectly.

  • Reported: SAEM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Removed multiple inheritence and different definition path.

    The only occurrence of Properties within SACM 2.0 is with the class ArtefactProperty, which inherits from ArtefactAsset. There are no longer any other (inconsistent) definitions of properties with different inheritance.

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

Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...

  • Key: SACM2-4
  • Legacy Issue Number: 16854
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    As part of the SACM 2.0 update we removed much of the prescription of domain-specific content in the artefact model of SACM. In particular, we avoided prescription where there was no industry consensus on the ways in which artefacts should be described. This has removed these overlapping elements. Instead, SACM 2.0 focuses on providing a standardised exchange model format within which description can be customized (see Description element of ModelElement) for communities of interest using user-defined vocabularies and structured expressions.

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

fundamental difference in modelling style of each metamodel

  • Key: SACM2-7
  • Legacy Issue Number: 16850
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    There is a fundamental difference in how modelling style of each metamodel. For example SAEM has a more "fact oriented" (nouns and verbs) approach which has a simpler MOF implementation. ARM has

    classes instead.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Addressed by harmonization to create SACM 2.0.

    We have consolidated and standardized the model approach and style to ensure consistency between the Argumentation and Artefact elements of SACM.

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

Reference to non-existent class

  • Key: SACM2-31
  • Legacy Issue Number: 19869
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The text states that the ArgumentReasoning class has a reference structure:Argument[0..1]

    There is no Argument class defined. This should presumably be structure:Argumentation[0..1], as shown in Figure 9.1

  • Reported: SACM 1.1 — Mon, 14 Dec 2015 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    Typo has been removed

    This spurious typo has been removed and is no longer present in SACM.

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

Uncertainty characteristic for claims

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

    From the viewpoint of compatibility with ISO/IEC 15026, the most important issue is that SACM contain an "Uncertainty" characteristic or attribute, a key aspect of 15026-2, in order to facilitate use of SACM with ISO/IEC 15026 conformant assurance cases. These would be useful throughout SACM as attributes of assertions or claims (not relations).

    Current usage means a need exists for several data type options ­ not necessarily mutually exclusive.

    Data Types
    • Probability true: 0-1.00
    • Type I error: 0-1.00
    • Type 2 error: 0-1.00
    • Enumeration: None, low, medium, large, unknown
    • Standard deviation: real number
    One might also want to include a data type with customizable meaning (values: 1-100) that would parallel the data type for “Strength” in present draft if this is retained.

    This attribute element is associated with claims (assertions) and not with relations. Current SAEM draft defines characteristics ­ such as “Strength,” and “Confidence” ­ of evidence relations between an EvidenceItem (e.g. exhibit) and a DominAssertion. These relate to uncertainty but are associated with a relation and not with a DomainAssertion (claim). Note that the draft of SAEM states these are one-to-one relations unlike the many-to-one inferential relations in ARM.

  • Reported: SAEM 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.

    In redefining SACM 2 it was recognized that there was no established approach (accepted by even a small group of industry) as to how to represent confidence and uncertainty on SACM artefact and argumentation elements. Consequently, SACM 2 deliberately pulled back from standardising in these areas. Confidence information could be added to any model element (if required) using TaggedValue (which could use a community consensus vocabulary established using the Terminology package). In addition, SACM 2 recognises that substantiative assertions about artefacts / evidence should be documented as Claims. It also recognizes the potential (which may be particularly relevant when discussing confidence) to attach metaclaims to any Assertion (see metaClaim association on Assertion).

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

Identifying nature of element contents

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

    2. What is needed to be known by tool or human is information required to establish the meaning of its content (interpret it) for this the notation/means used to express contents needs to be identified. An associated property could do this ­ and with more power/flexibility as any notation could be identified. Among other things, one should not presume that multiple tool vendors would never chose to support a (mathematically) formal notation other than SBVR. The use of different element types to identify nature of contents as “informal” or “structured” would be overkill. Rather, rename/combine “Consistency,” “ IsExpressed InLanguage”or other element to NotationUsed and provide appropriate attributes.

  • Reported: SAEM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 2.0
  • Disposition Summary:

    This level of prescription of description is no longer included in SACM 2.0.

    This level of prescription of description in the Artefact model (i.e. referring to the form of expression of artefact contents) is no longer included in SACM 2.0. However, a community could standardize on an expected set of ArtefactProperties, description of these properties and vocabulary using a common Terminology Package.

  • 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

SBVR should be available in SACM for use wherever this would make sense

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

    SBVR should be available in SACM for use wherever this would make sense. This includes in (ARM) claims and ReasoningElements and in SAEM many assertions particularly claims and possible rationales. Wherever narrative or prose, or mathematical expressions are allowed, why not also allow SBVR (and some places graphics or even other media also) unless strong reasons exist for doing otherwise?

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 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

Ownership needs improved representation

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

    The following aspects need to be accommodated:
    Owning, creating, and approving can be done concurrently by multiple entities and different (sets of) entities over time.

    Ownership can be divided unequally among owners and fractions could need to be recorded.

    Ownership can have aspects, for example IP rights versus physical object ­ I own the book, but not its copyright.

  • Reported: SAEM 1.0b1 — Sun, 5 Jun 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).

  • 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

Uncertainty characteristic for claims

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

    From the viewpoint of compatibility with ISO/IEC 15026, the most important issue is that SACM contain an "Uncertainty" characteristic or attribute, a key aspect of 15026-2, in order to facilitate use of SACM with ISO/IEC 15026 conformant assurance cases. These would be useful throughout SACM as attributes of assertions or claims (not relations).

    Current usage means a need exists for several data type options ­ not necessarily mutually exclusive.

    Data Types
    • Probability true: 0-1.00
    • Type I error: 0-1.00
    • Type 2 error: 0-1.00
    • Enumeration: None, low, medium, large, unknown
    • Standard deviation: real number
    One might also want to include a data type with customizable meaning (values: 1-100) that would parallel the data type for “Strength” in present draft if this is retained.

    This attribute element is associated with claims (assertions) and not with relations. Current SAEM draft defines characteristics ­ such as “Strength,” and “Confidence” ­ of evidence relations between an EvidenceItem (e.g. exhibit) and a DominAssertion. These relate to uncertainty but are associated with a relation and not with a DomainAssertion (claim). Note that the draft of SAEM states these are one-to-one relations unlike the many-to-one inferential relations in ARM.

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

    Deferred as still valid for SACM

    Whilst still a gap between what is discussed in ISO 15026 and what is supported in SACM, it was recognized that there still is no common established state of the practice for recording confidence and uncertainty values on assurance case argument elements. It may be that a probability value would allow for the most commonality amongst current approaches. Guidance would be required on how to map to a probability value under different confidence determination regimes as listed above. There was still some disagreement about whether the current approach to modeling confidence in the evidence portion of SACM is fit for purpose. However for backward compatibility now changes have been made to this.

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

Scope of availability of change management information

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

    Timing or change management information needs to be able to be associated with anything as anything can change over time. This includes for example with Attributes (and any Properties). In addition, how to best handle changes and change information over time needs to be reviewed throughout SACM.

    The version and change management related information ­ although often kept in a CM system ­ needs to be exchangeable along with an assurance case. At least one exchange standard for CM information exists, TECHAMERICA EIA-836B: Configuration Management Data Exchange and Interoperability, publication date: Mar 1, 2010. It is reportedly both ANSI and DoD approved. (http://engineers.ihs.com/document/abstract/BMVKACAAAAAAAAAA) One option is for this to be appropriately included by reference.

    Versioning should be available for everything. Identification and “HasVersion” attribute should be associated with a near root element, or this availability should be achieved in some other fashion. The standard should not restrict its availability and smallness of possible granularity of elements it may be applied to.

  • Reported: SAEM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    This is still felt to be valid issue, and it remains a difference between the evidence and argument portions of SACM. However, it still remains unclear how best to address this fine-grained change management and versioning issue for individual model elements (e.g. individual claims).

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

Need for general facility for stating and handling issues

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

    As everything is disputable (that is, can be challenged) and issues of many natures can arise, a general “Issue” facility is required. This should also span all of SACM.

    Currently, “EvidenceObservation” is used in the sense of “comment” or “issue”. Its name could be changed and its availability be made more general. Possibly it should include a sub-element with a more general name for issues that do not fit into current sub-element categories (or possibly not yet categorized).

    While probably not belonging in the core compliance point, facilities for issue resolution need to be likewise generally applicable.

  • Reported: SAEM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    Felt not necessary to have specific Issue element as general commenting and issue tagging can easily be done with TaggedValue which already exists.

  • 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

"ArgumentResoning" Class and "Assertedinferce" Class

  • Key: SACM11-44
  • Legacy Issue Number: 19544
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    According to "ArgumentResoning" Class and "Assertedinferce" Class on the SACM 1.0 spec,

    >ArgumentReasoning can be used to provide additional description or explanation
    >of the asserted inference or challenge that connects one or more Claims (premises)
    >to another Claim (conclusion). ArgumentReasoning elements are therefore
    >related to AssertedInferences and AssertedChallenges

    and

    >The AssertedInference association class records the inference that
    >a user declares to exist between one or more Assertion
    >(premises) and another Assertion (conclusion).

    It seems that AsseretedInference and AssertedChallenges implies
    strategy(Parallelogram) on the GSN.

    On the other hand, in "B.2.1 Goal Structuring Notation(GSN) Examples" in Annex B
    Parallelogram corresponds to ArgumentReasoning.

    These are confusing.
    Which one is correct?

    Clarify the above.

  • Reported: SACM 1.0 — Fri, 25 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Duplicate of SR-84

    This issue is a duplicate of SR-84 - somehow it was added into JIRA twice.

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

AssertedRelationship Class

  • Key: SACM11-43
  • Legacy Issue Number: 19539
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    According to the SACM 1.0 spec,
    AssertedRelationship Class is abstract association class.
    However, AssertedRelationship isn't an association class on
    the Figure 9.1 (It is just a normal association.)
    Which is correct?

  • Reported: SACM 1.0 — Thu, 24 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Duplicate of SR-85

    This issue is a duplicate of SR-85 - somehow it was added into JIRA twice.

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

All associations need to be labeled with a verb

  • Key: SACM11-34
  • Legacy Issue Number: 16863
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    All associations need to be labeled with a verb

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    Discussed at Boston 2014 June meeting and decided that this change is not necessary and that the issue should be closed.

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

combined standard should include a vocabulary for talking about standards of proof

  • Key: SACM11-33
  • Legacy Issue Number: 16861
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    combined standard should include a vocabulary for talking about standards of proof

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...

  • Key: SACM11-32
  • Legacy Issue Number: 16854
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

There is no support for patterning, which is found to be useful current practice.

  • Key: SACM11-31
  • Legacy Issue Number: 16853
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    There is no support for patterning, which is found to be useful current practice.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05: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

fundamental difference in modelling style of each metamodel

  • Key: SACM11-30
  • Legacy Issue Number: 16850
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    There is a fundamental difference in how modelling style of each metamodel. For example SAEM has a more "fact oriented" (nouns and verbs) approach which has a simpler MOF implementation. ARM has

    classes instead.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

prefixes in the SAEM 'Evidence....

  • Key: SACM11-29
  • Legacy Issue Number: 16849
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    The name 'Evidence' implies a certain association between some Information / some artefact and some claim. In ARM it was recognised that information can be used both to define context and as

    supporting evidence to an assertion. This suggests that many of the prefixes in the SAEM 'Evidence....' should be changed to allow them to more generally refer to Information (and specialise to Evidence if

    required)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Issue: No approach to allowing Structured Expression of Claims within ARM

  • Key: SACM11-28
  • Legacy Issue Number: 16844
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Issue: No approach to allowing Structured Expression of Claims within ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

No method of handling confidence in the ARM

  • Key: SACM11-27
  • Legacy Issue Number: 16843
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    No method of handling confidence in the ARM

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Integration Issue: Inconsistent approaches to handling counter argument and evidence

  • Key: SACM11-26
  • Legacy Issue Number: 16842
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent approaches to handling counter argument and evidence. Both standards have evaluation mechanisms (e.g. refuting, rebutting mechanisms)

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Integration Issue: Inconsistency in level of prescription in the models

  • Key: SACM11-25
  • Legacy Issue Number: 16841
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistency in level of prescription in the models (e.g. raised by Jeremy). E.g. arm does not prescribe what kinds of claims, instead SAEM has more presciption of the subtypes of

    claims.

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Integration Issue: Overlapping scope

  • Key: SACM11-24
  • Legacy Issue Number: 16838
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Overlapping scope

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    Remove duplicate

    Delete Section 9.1.9 EvidenceAssertion from the Argumentation section.
    Rename all occurrences of Assertion in the Evidence section to EAssertion.

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

Integration Issue: Inconsistent terminology

  • Key: SACM11-23
  • Legacy Issue Number: 16837
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Inconsistent terminology

  • Reported: SACM 1.0 — Wed, 30 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel

  • Key: SACM11-22
  • Legacy Issue Number: 16807
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel

  • Key: SACM11-21
  • Legacy Issue Number: 16781
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

Page73 ,section 13.2, figure21

  • Key: SACM11-20
  • Legacy Issue Number: 16712
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Some of the concepts being captured in the model here overlap quite strongly with those of
    Configuration Management, and would probably best left to standards in that domain rather
    than creating a conceptual overlap here.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

ARM: Page 20, section 8.2.17

  • Key: SACM11-19
  • Legacy Issue Number: 16694
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    One may want to state the context in which an AssertedRelationship holds. At present, the invariants on AssertedContext disallow this.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    The issued SACM 1.0 already allows this.

    AssertedContext relationship is from InformationElement to ReasoningElement (which includes AssertedRelationship as a subtype).

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

ARM: Page 18, section 8.2.14

  • Key: SACM11-18
  • Legacy Issue Number: 16693
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    : In the AssertedInference class, the invariants leave the possibility of inferring an AssertedRelationship from a set of claims. They do not, however, allow a Claim to be inferred from an AssertedRelationship. Since an AssertedRelationship is a kind of claim (not in the sense of the model, but in a general sense), it seems reasonable to allow it; that is, “I claim A because of the relationship between claims B and C”.

  • Reported: SACM 1.0 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    *Invariant should be changed *

    Agreed – Invariant should be changed to read:

    On Page 49, section 9.1.12
    context AssertedInference
    inv SourceMustBeAssertion : self.source->forAll(s|s.oclIsTypeOf(Assertion))
    inv TargetMustBeAssertion : self.target->forAll(t|t.oclIsTypeOf(Assertion))

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

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

editing error & typo in 10.1.1 & 10.2.3

  • Key: SACM11-93
  • Status: closed  
  • Source: MITRE ( Bob Martin)
  • Summary:

    In Section 10.1.1 "(things)." should be “primary elements of the Evidence Metamodel (things).” and in Section 10.2.3 “eleements” should be “elements”

  • Reported: SACM 1.0 — Tue, 28 Oct 2014 21:07 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    In Section 10.1.1 "(things)." should be “primary elements of the Evidence Metamodel (things).” and in Section 10.2.3 “eleements” should be “elements”

    Change "(things)." to “primary elements of the Evidence Metamodel (things).”
    and “eleements” to “elements”

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

typo: facctype section 12.3.1

  • Key: SACM11-91
  • Status: closed  
  • Source: MITRE ( Bob Martin)
  • Summary:

    In Section 12.3.1 "facctype" should be "facttype"

  • Reported: SACM 1.0 — Fri, 24 Oct 2014 10:26 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    facttype" is correct in the formal version

    facttype" is correct in the formal version – mistake was in ptc-12-06-06.pdf version

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

AssertedRelationship Class

  • Key: SACM11-85
  • Status: closed  
  • Source: MITRE ( Bob Martin)
  • Summary:

    According to the SACM 1.0 spec, AssertedRelationship Class is abstract association class. However, AssertedRelationship isn't an association class on the Figure 9.1 (It is just a normal association.) Which is correct?

  • Reported: SACM 1.0 — Wed, 15 Oct 2014 18:44 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    This is an error in the text of Section 9.1.11 rather than an error in Figure 9.1

    This is an error in the text of Section 9.1.11 rather than an error in Figure 9.1

    The first line of Section 9.1.11 should be changed from: “AssertedRelationship Class is the abstract association class” to “AssertedRelationship Class is the abstract class”.

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

"ArgumentResoning" Class and "Assertedinferce" Class

  • Key: SACM11-84
  • Status: closed  
  • Source: MITRE ( Bob Martin)
  • Summary:

    According to "ArgumentResoning" Class and "Assertedinferce" Class on the SACM 1.0 spec, ArgumentReasoning can be used to provide additional description or explanation of the asserted inference or challenge that connects one or more Claims (premises) to another Claim (conclusion). ArgumentReasoning elements are therefore >related to AssertedInferences and AssertedChallenges and The AssertedInference association class records the inference that a user declares to exist between one or more Assertion (premises) and another Assertion (conclusion). It seems that AsseretedInference and AssertedChallenges implies strategy(Parallelogram) on the GSN. On the other hand, in "B.2.1 Goal Structuring Notation(GSN) Examples" in Annex B Parallelogram corresponds to ArgumentReasoning. These are confusing. Which one is correct? Clarify the above.

  • Reported: SACM 1.0 — Wed, 15 Oct 2014 18:43 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    The description of AssertedInference, AssertedChallenge and ArgumentReasoning is correct. The Annex B example is correct

    AssertedInference in SACM relates to the SupportedBy relationship in GSN. In GSN, to explain and describe a (collection) of SupportedBy links from parent goals to child goals, GSN Strategy can be used. In SACM, to explain and describe an AssertedInference from child claims to parent claims, ArgumentReasoning can be used. ArgumentReasoning is analogous to GSN Strategy. AssertedInference is the relationship described by (potentially multiple) SupportedBy links in GSN.

    The description of AssertedInference, AssertedChallenge and ArgumentReasoning is correct. The Annex B example is correct.

    No change is required to the standard.

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

Replace Individual Class Examples with Single Integrated Example

  • Key: SACM11-83
  • Status: closed  
  • Source: MITRE ( Bob Martin)
  • Summary:

    Currently SACM 1.0 attempts to provide XMI examples of individual classes within the Argumentation section. The Evidence section does not provide such examples (it leaves these sections blank). The individual examples are hard to understand outside of the context of a complete Argumentation structure. An integrated example is already provided in Annex B.

  • Reported: SACM 1.0 — Wed, 15 Oct 2014 18:38 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    Remove individual example snippets and replace with reference to the example in Annex B

    It was felt that the individual examples could simply be replaced by a cross-reference to an updated Annex B (updated to reflect all changes made to the rest of the Argumentation section, and to ensure coverage of all concrete Argumentation classes).

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

Rationalizing Citations within the Argumentation structure

  • Key: SACM11-82
  • Status: closed  
  • Source: MITRE ( Bob Martin)
  • Summary:

    InformationElements should be able to play a dual role. They should be able to provide (contain) information content to be used ‘in line’ within an Argumentation structure, or be used to refer (cite) to a container of evidence outside of the (current) Argumentation structure. At present, only the latter role is described in SACM 1.0.
    Regarding the interface between the Argumentation and Evidence aspects of SACM, at present SACM 1.0 only allows an InformationElement to refer to an EvidenceItem. However, there are other classes within the Evidence part of SACM (e.g. EvidenceContainer) that it should also be possible to reference.
    The current CitationElement has dual roles. This element can be used to refer to a specific ArgumentationElement within an Argumentation structure, or can be used to refer to an entire Argumentation structure as a container. It is desirable (for clearer semantics) to simplify to a single role per ArgumentationElement subtype.

  • Reported: SACM 1.0 — Wed, 15 Oct 2014 18:37 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    InformationElements should be able to play a dual role.

    The current CitationElement has dual roles. This element can be used to refer to a specific ArgumentationElement within an Argumentation structure, or can be used to refer to an entire Argumentation structure as a container. It is desirable to simplify to a single role per subtype.

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

ArgumentReasoning associations with AssertedRelations

  • Key: SACM11-81
  • Status: closed  
  • Source: MITRE ( Bob Martin)
  • Summary:

    In SACM 1.0 it is possible to associate an ArgumentReasoning object to an AssertedInference or AssertedChallenge. This supports the claim-argument-claim (or claim-counterargument-claim) structure described in ISO 15026-2, but not the claim-argument-evidence structure described in ISO 15026-2.

  • Reported: SACM 1.0 — Wed, 15 Oct 2014 18:35 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    In SACM 1.0 it is possible to associate an ArgumentReasoning object to an AssertedInference or AssertedChallenge. This supports the claim-argument-claim structure in ISO 15026-2, but not the claim-argument-evidence structure in ISO 15026-2.

    There are 2 possible approaches to resolving. The first is to add associations. The second is to remove the existing two associations, and replace these with a single new association to the parent class. This is recognised as a potentially useful.

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

Use uniform 'statement' language for describing evidence properties

  • Key: SACM11-42
  • Legacy Issue Number: 17336
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    Various evidence properties and attributes represent 'statements' about evidence. Specification needs to be systematically edited to introduce this language.

  • Reported: SACM 1.0b1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    Various evidence properties and attributes represent 'statements' about evidence. Specification needs to be systematically edited to introduce this language.

    To better describe many of the evidence related properties and attributes in 60 pages of the narrative text of the SACM specification several of the concepts need to be better described and some spelling errors addressed.

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

Add missing definitions to SBVR Vocabulary in Annex A

  • Key: SACM11-41
  • Legacy Issue Number: 17335
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    The SBVR vocabulary for evidence in Annex A is missing several definitions.

  • Reported: SACM 1.0b1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    This issue is being deferred to a future RTF due to the lack of time.

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

Need examples of the Evidence Metamodel XMI

  • Key: SACM11-40
  • Legacy Issue Number: 17334
  • Status: closed  
  • Source: KDM Analytics ( Nikolai Mansourov)
  • Summary:

    The Evidence Metamodel specification missed examples of the XMI. Such examples are present in the Argumentation Metamodel and significantly increase the clarity of the specification.

  • Reported: SACM 1.0b1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.1
  • Disposition Summary:

    The Evidence Metamodel specification missed examples of the XMI. Such examples are present in the Argumentation Metamodel and significantly increase the clarity of the specification.

    A variety of Examples are added and one section has a section number added that was missing - resulting in renumbering of the subsequent sub-sections.

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

Use name "Artfact" rather than Exhibit"

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

    The term “Exhibit” should be replaced with Artifact” because some Exhibits/Artifacts are not evidentiary but are descriptive or, for example, provide definitions in other words they have other roles than exhibits constituting evidence.

  • Reported: SAEM 1.0b1 — Fri, 9 Dec 2011 05:00 GMT
  • Disposition: Closed; No Change — SACM 1.1
  • Disposition Summary:

    Change not considered necessary

    Discussed at Boston 2014 June meeting and decided that this change is not necessary and that the issue should be closed.

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

Identifying nature of element contents

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

    2. What is needed to be known by tool or human is information required to establish the meaning of its content (interpret it) for this the notation/means used to express contents needs to be identified. An associated property could do this ­ and with more power/flexibility as any notation could be identified. Among other things, one should not presume that multiple tool vendors would never chose to support a (mathematically) formal notation other than SBVR. The use of different element types to identify nature of contents as “informal” or “structured” would be overkill. Rather, rename/combine “Consistency,” “ IsExpressed InLanguage”or other element to NotationUsed and provide appropriate attributes.

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

    Deferred as still valid for SACM

    The extension and unification of language and vocabulary support in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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

EvidenceProperty inherit from Property

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

    With integration EvidenceProperty inherit from Property as should all properties - directly or indirectly.

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

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

  • 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:

We are missing an SBVR vocabulary for ARM

  • Key: SACM11-35
  • Legacy Issue Number: 16864
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    We are missing an SBVR vocabulary for ARM (authors view - this is work someone else
    to do, maybe close/postpone)

  • Reported: SACM 1.0 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Deferred — SACM 1.1
  • Disposition Summary:

    Deferred as still valid for SACM

    To address this in revision to SACM would require a substantial change that would significantly negatively impact backwards compatibility that is beyond what can be done in SACM 1.1.

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