Structured Assurance Case Metamodel Avatar
  1. OMG Specification

Structured Assurance Case Metamodel — Closed Issues

  • Acronym: SACM
  • Issues Count: 362
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SACM23-12 List of companies, copyright dates, and description of changes needed SACM 2.2 SACM 2.3 Resolved closed
SACM23-17 AB request that new UML profile be normative and covered by a compliance point SACM 2.2 SACM 2.3 Resolved closed
SACM23-22 Errors in machine consumable files - emof and uml profile SACM 2.2 SACM 2.3 Resolved closed
SACM23-3 Figure 8.1 Mislabeled SACM 2.2 SACM 2.3 Resolved closed
SACM23-16 EMOF and UML profile files were html SACM 2.2 SACM 2.3 Resolved closed
SACM23-13 mistakenly created SACM 2.2 SACM 2.3 Duplicate or Merged closed
SACM23-1 SACM lacks display information for tool interchange SACM 2.1 SACM 2.3 Closed; Out Of Scope closed
SACM23-4 UML profile for SACM SACM 2.2 SACM 2.3 Resolved closed
SACM23-2 Terminology Categories need to nest SACM 2.2 SACM 2.3 Resolved closed
SACM23-5 List of companies, copyright dates, and description of changes needed SACM 2.2 SACM 2.3 Duplicate or Merged closed
SACM22-13 Referring to wrong version of SACM SACM 2.1 SACM 2.2 Resolved closed
SACM22-19 Typo in text of 11.7 SACM 2.1 SACM 2.2 Resolved closed
SACM22-17 Typo in OCL SACM 2.1 SACM 2.2 Resolved closed
SACM22-9 Section 3.1 Normative References SACM 2.1 SACM 2.2 Resolved closed
SACM22-3 "ID" never defined in Annex C graphical notation. Is it the gid? SACM 2.1 SACM 2.2 Resolved closed
SACM22-26 Graphical Notation Dot too small to work in tools. SACM 2.1 SACM 2.2 Resolved closed
SACM22-25 Remove duplicate text SACM 2.1 SACM 2.2 Resolved closed
SACM22-23 Missing words in 11.11 SACM 2.1 SACM 2.2 Resolved closed
SACM22-21 Missing line break in 11.8 SACM 2.1 SACM 2.2 Resolved closed
SACM22-20 Typo in text of 11.8 SACM 2.1 SACM 2.2 Resolved closed
SACM22-22 Typo in 11.9 SACM 2.1 SACM 2.2 Resolved closed
SACM22-28 Wrong package name used in second sentence of 9.3. SACM 2.1 SACM 2.2 Resolved closed
SACM22-12 Defining terms used in SACM SACM 2.1 SACM 2.2 Resolved closed
SACM22-11 Section 3.2 Non-normative References SACM 2.1 SACM 2.2 Resolved closed
SACM22-16 Flexibility in relationships SACM 2.1 SACM 2.2 Resolved closed
SACM22-15 Clarify bindings and interfaces SACM 2.1 SACM 2.2 Resolved closed
SACM22-14 Confusing use of the term property SACM 2.1 SACM 2.2 Resolved closed
SACM22-18 Definition is unclear SACM 2.1 SACM 2.2 Resolved closed
SACM22-7 Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it. SACM 2.1 SACM 2.2 Resolved closed
SACM22-2 SACM lacks display information for tool interchange SACM 2.1 SACM 2.2 Deferred closed
SACM22-1 Figure 11.1. Missing 'content' composition on ArgumentAsset SACM 2.1 SACM 2.2 Resolved closed
SACM22-24 Clarification of use of AssertedContext SACM 2.1 SACM 2.2 Resolved closed
SACM21-109 New notations for asserted context and asserted artifact context SACM 2.0 SACM 2.1 Resolved closed
SACM21-84 http -> https in MOF file SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-83 Why MOF 2.0 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-82 PNG images SACM 2.0 SACM 2.1 Resolved closed
SACM21-81 !!.14 or 11.14 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-80 SACM21-1 through 13 were unnecessary SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-79 Issue 55 material includes Issue 30 changes SACM 2.0 SACM 2.1 Resolved closed
SACM21-78 multiplicity change missing figures SACM 2.0 SACM 2.1 Resolved closed
SACM21-77 Missing Concrete Syntax in 11.10 SACM 2.0 SACM 2.1 Resolved closed
SACM21-76 Date or date in 12.11 SACM 2.0 SACM 2.1 Resolved closed
SACM21-72 newline SACM 2.0 SACM 2.1 Resolved closed
SACM21-71 multiplicity in figure and text do not match SACM 2.0 SACM 2.1 Resolved closed
SACM21-70 trailing bullet SACM 2.0 SACM 2.1 Resolved closed
SACM21-69 SPMS version SACM 2.0 SACM 2.1 Resolved closed
SACM21-68 Typo on pdf pg 10 SACM 2.0 SACM 2.1 Resolved closed
SACM21-67 http -> https SACM 2.0 SACM 2.1 Resolved closed
SACM21-65 SACM21-20 the changes are inconsistent with pdf SACM 2.0 SACM 2.1 Resolved closed
SACM21-64 SACM21-14 and SACM21-16 bad urls SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-13 Address missing elements of first 12 issues and address style consistency SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-12 Need for the ability to group SACMElements SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-11 Better support for patterns is needed SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-10 Simplification of ArtifactAssetRelationship SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-9 Need to simplify the citation classes of SACM SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-8 Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured. SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-7 Need more consistency in packages, interfaces and binding SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-6 SACM needs support for Internationalization SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-5 Simplification of elements contained in packages SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-4 Need to simplify internationalization support in Expressions. SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-3 Alow AssertedRelationship to express if it is a counter relationship SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-2 Simplify ArtifactElement and its sub-types SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-1 Align with American English to support use of SACM by The Open Group SACM 2.0b2 SACM 2.1 Closed; No Change closed
SACM21-31 B and A or A and B SACM 2.0 SACM 2.1 Resolved closed
SACM21-30 Replace "that" with "whether"? SACM 2.0 SACM 2.1 Resolved closed
SACM21-25 Spelling mistake in 11.8 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-22 Spelling mistake in 2.5 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-21 Mistake in element name in 2.3 text SACM 2.0 SACM 2.1 Resolved closed
SACM21-20 Concepts in SACM 2 have no direct graphical notation SACM 2.0 SACM 2.1 Resolved closed
SACM21-19 Missing role discription for terminology model SACM 2.0 SACM 2.1 Resolved closed
SACM21-18 Misleading section title for 1.3 Artifact SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-62 Outdated constraints for class Claim SACM 2.0 SACM 2.1 Duplicate or Merged closed
SACM21-58 In 11.13 the +target should have multiplicity of 1 SACM 2.0 SACM 2.1 Resolved closed
SACM21-55 Unnecessary constraint statement in 11.11 SACM 2.0 SACM 2.1 Resolved closed
SACM21-107 Graphical notation for SACM Argumentation concepts SACM 2.0 SACM 2.1 Resolved closed
SACM21-75 Date or date in 12.9 SACM 2.0 SACM 2.1 Resolved closed
SACM21-74 Date or date in 12.7 SACM 2.0 SACM 2.1 Resolved closed
SACM21-73 text and figure mismatch ArgumentPackage<-->ArgumentPackageInterface SACM 2.0 SACM 2.1 Resolved closed
SACM21-66 Confirm URI on title page SACM 2.0 SACM 2.1 Resolved closed
SACM21-17 Incorrect description of package SACM 2.0 SACM 2.1 Resolved closed
SACM21-16 Invalid URL SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-15 Association is inconsistent with semantics SACM 2.0 SACM 2.1 Resolved closed
SACM21-14 Broken Link SACM 2.0 SACM 2.1 Closed; No Change closed
SACM21-29 Duplicative paragraphs? SACM 2.0 SACM 2.1 Resolved closed
SACM21-24 Punctuation and spacing errors SACM 2.0 SACM 2.1 Resolved closed
SACM21-23 Spelling mistake in 9.1 SACM 2.0 SACM 2.1 Closed; No Change closed
SACM2_-9 Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured. SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-8 Align with American English to support use of SACM by The Open Group SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-7 Simplification of ArtifactAssetRelationship SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-6 Simplify ArtifactElement and its sub-types SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-5 Alow AssertedRelationship to express if it is a counter relationship SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-4 Need to simplify internationalization support in Expressions. SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-3 Simplification of elements contained in packages SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-1 Need to simplify the citation classes of SACM SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-10 Better support for patterns is needed SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-11 Need for the ability to group SACMElements SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-2 SACM needs support for Internationalization SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-24 Need more consistency in packages, interfaces and binding SACM 2.0b2 SACM 2.0 Deferred closed
SACM2_-26 Address missing elements of first 12 issues and address style consistency SACM 2.0b2 SACM 2.0 Deferred closed
SACM2-73 There is no compliance point for those that support/use the Terminology Package specified in SACM 2.0’s metamodel. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-72 Model uses undefined ‘date’ type. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-71 In the classes related to Citations, the terms Element and Asset are inconsistently used. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-70 Section 2 doesn’t make it clear that AssuranceCase compliance point is mandatory. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-69 Incorrect description of the Argumentation compliance point. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-81 Typo in reference to ISO/IEC 15026 SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-30 Inconsistent naming of class SACM 1.1 SACM 2.0 Closed; No Change closed
SACM2-68 The SACM 2.0 meta-model requires implementation of the Terminology Package in spite of the text of Chapter 2 on compliance points saying it is optional. SACM 2.0b1 SACM 2.0 Resolved closed
SACM2-67 Inconsistent use of the word “Model” in describing the three compliance points SACM 2.0b1 SACM 2.0 Resolved 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-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-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-16 Property Inherence Hierarchy ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-20 Properties of Model Elements must be Distinguished from Properties of what they Represent ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-22 Events should be able to be Associated with all Kinds of ModelElements ARM 1.0b1 SACM 2.0 Closed; No Change closed
SACM2-21 Making Role Binding and SBVR more generally available 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-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-15 combined standard should include a vocabulary for talking about standards of proof 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-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-27 EvidenceProperty inherit from Property SAEM 1.0b1 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-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-11 Events should be able to be Associated with all Kinds of ModelElements ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-10 Making Role Binding and SBVR more generally available ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-9 Property Inherence Hierarchy ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-8 Properties of Model Elements must be Distinguished from Properties of what they Represent ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-7 Properties as Assertions ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-4 Assurance Cases under development or Incomplete ARM 1.0b1 SACM 1.1 Deferred closed
SACM11-3 Uncertainty characteristic for claims SAEM 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-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-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-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-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-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-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
SACM11-91 typo: facctype section 12.3.1 SACM 1.0 SACM 1.1 Closed; No Change closed
SACM11-93 editing error & typo in 10.1.1 & 10.2.3 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-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
SACM_-2 Incorrect URL for SACM in Appendix B SACM 1.0b2 SACM 1.0 Resolved closed
SACM_-3 Duplicate rolename 'subject' in class 'ProvidesContext' SACM 1.0b2 SACM 1.0 Resolved closed
SACM_-1 Association names should be nouns SACM 1.0b2 SACM 1.0 Resolved closed
SACM-145 Integration issue: introductory text should cover SAEM introductory material SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-152 We need a common route to support instance packaging SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-151 Using the term 'Argument' as the container for the "Claims-Argument-Evidence" aspect of ARM is confusing as people expec SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-147 evidence evaluation attributes SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-146 Lack of agreement the attribute types for some of the evidence evaluation subtypes - e.g. confidence 0..100 as integer SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-154 Need a revised compliance point approach SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-156 exchanged model instances should indicate which compliance points have been satisfied SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-155 The detailed enumerated attributes in SAEM need a corresponding location in SACM SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-149 If AssertedRelationships are genuinely Assertions then they should be subtypes of Assertion SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-148 No AssuranceCase Element in either ARM or SAEM - necessary for a Structured Assurance Case Metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-153 Metamodel packaging should broadly align with ARM/SAEM elements SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-157 Combined specification should have routes and guidance broadly corresponding to ARM and SAEM SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-150 counter evidence and challenge should be better modelled by a polarity attribute on the relation (AB comment) SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-167 Argument metamodel needs improvement SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-166 Evidence Metamodel needs a Record element SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-162 Need to provide motivation (the underlying issue) for new “link group” SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-161 Question of how to characterize the identity of the “artifact-as-such”, as well as its URN SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-165 Wrong figure in Evidence Evaluation example SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-164 Needed assurance case compliance point ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-160 Need to clarify usage of “nature of dependency” to indicate this is not for evidential or argumentation relations SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-159 motivate link groups SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-168 ArgumentReasoning should also attach to AssertedChallange SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-158 The frontispiece sections (introduction, background, scope etc) needs to be edited to reflect integration SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-163 Name AssertedEvidence ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-144 Integration Issue: Combined scope needs to include original scopes, and any emergent scope SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-143 Integration issue: An overall goal is to integrate the ARM and SAEM specifications into SACM in a coherent way. SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-142 Incorporate 12.5.1 EvidenceRequest (p82) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-141 Incorporate 12.4.4 HasRoleIn (p81) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-135 Incorporate 12.3.2 Service (p79) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-134 Incorporate 12.3.1 CollectionMethod (abstract) (p78) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-138 Incorporate 12.4.1 Originator (abstract) (p80) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-137 Incorporate 12.3.4 Tool (p79) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-133 Incorporate 12.2.6 DependsOn (p77) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-140 Incorporate 12.4.3 Organization (p81) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-139 Incorporate 12.4.2 Person (p80) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-136 Incorporate 12.3.3 Method (p79) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-125 Incorporate 12.1.3 StandardOfProof (enumeration) (p73) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-124 Incorporate 12.1.2 Package (p72) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-123 Incorporate 12.1.1 AdministrativeElement (abstract) (p71) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-122 Incorporate 11.7.1 EvidenceGroup (p69) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-126 Incorporate 12.1.4 AdministrativeProperty (abstract) (p74) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-119 Incorporate 11.6.2 Negates (p67) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-118 Incorporate 11.6.1 EvidenceResolution (abstract) (p66) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-121 Incorporate 11.6.4 Resolves (p68) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-120 Incorporate 11.6.3 Refutes (p67) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-129 Incorporate 12.2.2 ActivityProperty (abstract) (p76) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-128 Incorporate 12.2.1 Activity (p75) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-127 Incorporate 12.1.5 RequiresPackage (p74) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-130 Incorporate 12.2.3 Satisfies (p76) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-117 Incorporate 11.5.5 Amplifies (p65) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-63 Incorporate 9.2.1 FormalObject (abstract) (p33) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-62 Incorporate 9.1.3 RoleBinding (p31) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-61 Incorporate 9.1.2 DomainClaim (p 31) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-60 Incorporate 9.1.1 Assertion (p30) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-65 Incorporate 9.2.3 UnknownSubject (p34) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-64 Incorporate 9.2.2 Object (p33) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-59 Incorporate 8.1.12 IsReleasableTo (p28) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-58 Incorporate 8.1.11 HasSecurityClassification (p28) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-57 Incorporate 8.1.10 HasVersion (p27) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-56 Incorporate 8.1.9 IsExpressedInLanguage (p26) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-66 Incorporate 9.2.4 CompositeSubject (p34) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-54 Incorporate 8.1.6 HasMedia (p25) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-55 Incorporate 8.1.8 IsBasedOn (p26) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-28 SAEM: Page 16, section 8.2.2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-27 SAEM: Page 13, section 7.4, in table SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-30 SAEM: Page 19, section 8.2.8 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-29 Page 16, section 8.2.2 (2) SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-38 SAEM: Typographical errors SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-37 SAEM: Page 35, section 11 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-34 SAEM: Page 24,section 9.1.4 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-33 SAEM: Page 21,section 9.1,figure 6 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-31 SAEM: The class DocumentAttribute does not seem to be described in the standard SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-32 SAEM: Page 21, section 9.1, figure 6 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-26 SAEM: Page 12, text under figure 3 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-25 SAEM: Page 11, section 7.3, figure 2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-36 SAEM: Page 33, section 10.2.2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-35 SAEM: Page 33, section 10.2.1 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-109 Incorporate 11.4.1 EvidenceInterpretation (abstract) (p60) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-115 Incorporate 11.5.2 Conflicts (p64) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-114 Incorporate 11.5.1 EvidenceObservation (abstract) (p64) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-106 Incorporate 11.3.6 CompletenessLevel (enumeration) (p59) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-105 Incorporate 11.3.5 Completeness (p58) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-108 Incorporate 11.3.8 ReliabilityLevel (enumeration) (p59) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-107 Incorporate 11.3.7 Reliability (p59) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-111 Incorporate 11.4.3 MeansThat (p61) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-110 Incorporate 11.4.2 IsA (p61) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-112 Incorporate 11.4.4 IsCharacterizedBy (p62) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-113 Incorporate 11.4.5 IsScopedBy (p62) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-116 Incorporate 11.5.4 Weakens (p65) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-104 Incorporate 11.3.4 ConsistencyLevel (enumeration) (p58) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-88 Incorporate 11.1.2 Supports (p50) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-87 Incorporate 11.1.1 EvidenceRelation (abstract) (p50) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-84 Incorporate 10.4.8 CareOf (p46) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-83 Incorporate 10.4.7 CustodyProperty (abstract) (p46) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-92 Incorporate 11.2.4 ReportingLevel (enumeration) (p53) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-91 Incorporate 11.2.3 Reporting (p52) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-82 Incorporate 10.4.6 IsGeneratedAt (p45) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-81 Incorporate 10.4.5 IsRevokedAt (p44) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-90 Incorporate 11.2.1 Support (p51) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-89 Incorporate 11.1.3 Challenges (p50) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-80 Incorporate 10.4.4 IsTransferredTo (p43) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-85 Incorporate 10.4.9 AtLocation (p47) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-86 Incorporate 10.4.10 UsingProcess (p47) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-5 Increased clarity needed SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-2 General mistaken cardinality issue SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-1 Difference between properties and attributes fuzzy and unneccessary SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-8 Change name “Amplifies" SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-7 Eliminate or change name of “EffectiveTime" SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-4 Modify term “evidence collection project” SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-3 A more generally available "citation" capability ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-10 ArgumentReasoning available for more relations ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-9 Definition for “Rationale” element missing SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-6 Improve wording (editorial) SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-71 Incorporate 10.2.1 TimingProperty (abstract) (p37) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-70 Incorporate 10.1.4 OwnedBy (p36) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-79 Incorporate 10.4.3 IsCreatedAt (p42) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-78 Incorporate 10.4.2 IsAcquiredAt (p41) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-69 Incorporate 10.1.3 ApprovedBy (p36) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-68 Incorporate 10.1.2 CreatedBy (p35) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-74 Incorporate 10.2.4 EndTime (p38) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-73 Incorporate 10.2.3 StartTime (p38) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-77 Incorporate 10.4.1 EvidenceEvent (abstract) (p40) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-72 Incorporate 10.2.2 EffectiveTime (abstract) (p38) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-67 Incorporate 10.1.1 Provenance (abstract) (p35) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-75 Incorporate 10.2.5 AtTime (p39) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-76 Incorporate 10.3.1 Description (p40) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-21 ARM: Page 21, section 8.3.1 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-15 Hierarchical Collections of Artifacts or Other Items ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-14 Meaning of HasDependencyOn ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-11 Change name of “Originator” SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-20 ARM: Page 16, section 8.2.9 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-19 ARM: Page 12, Figure 2, Page 15, section 8.2.6 and page 16, section 8.2.9: In Figure 2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-23 ARM Typographical errors SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-22 ARM: Page 21, sections 8.3.1 and 8.3.2 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-18 InformationAssertion’s and Informational Contents ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-17 Linking to Portions of an Artifact if this is what is Represented by a Model Element ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-24 SAEM: Page 6, section 7.1 SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-16 Link to Actual Artifact Represented by Model Element ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-13 Confidence as an Assertion ARM 1.0b1 SACM 1.0b2 Resolved closed
SACM-12 1..2.14. Need to record modification events and who modified SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-132 Incorporate 12.2.5 IsAssociatedWith (p77) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-131 Incorporate 12.2.4 RequiresMethod (p77) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-98 Incorporate 11.2.10 Relevance (p55) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-97 Incorporate 11.2.9 Significance (p55) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-95 Incorporate 11.2.7 Confidence (p54) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-94 Incorporate 11.2.6 AccuracyLevel (enumeration) (p53) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-101 Incorporate 11.3.1 Originality (p57) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-100 Incorporate 11.2.12 Strength (p56) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-93 Incorporate 11.2.5 Accuracy (p53) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-103 Incorporate 11.3.3 Consistency (p58) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-102 Incorporate 11.3.2 OriginalityLevel (enumeration) (p57) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-96 Incorporate 11.2.8 ConfidenceLevel (enumeration) (p54) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-99 Incorporate 11.2.11 Level (enumeration) (p55) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-46 Incorporate 7.2.8 DomainAssertion (abstract) (p19) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-45 Incorporate 7.2.7 DomainObject (abstract) (p19) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-42 Incorporate 7.2.4 EvaluationAttribute (abstract) (p18) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-41 Incorporate 7.2.3 EvidenceProperty (abstract) (p17) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-44 Incorporate 7.2.6 Meaning (abstract) (p18) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-43 Incorporate 7.2.5 EvidenceItem (abstract) (p18) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-47 Incorporate 7.2.9 EvidenceEvent (abstract) (p20) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-40 Incorporate 7.2.2 EvidenceElement (abstract) (p16) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-39 Incorporate 7.2.1 Element (abstract) (p16) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-49 Incorporate 8.1.1 Exhibit (p 21) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-48 Incorporate 7.2.10 EvidenceEvaluation (abstract) (p20) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-53 Incorporate 8.1.5 IsPartOf (p25) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-52 Incorporate 8.1.4 HasElectronicSource (p24) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-51 Incorporate 8.1.3 Exhibit Property (p23) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed
SACM-50 Incorporate 8.1.2 Document (p22) in a coherent way into merged SACM metamodel SACM 1.0b1 SACM 1.0b2 Resolved closed

Issues Descriptions

List of companies, copyright dates, and description of changes needed

  • Key: SACM23-12
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

    Need to update copyrights and list of submitters too.

  • Reported: SACM 2.2 — Fri, 18 Feb 2022 12:21 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Update items in spec to reflect new version

    Added sentence about the content of SACM 2.3 and revised previous SACM 2.2 content sentence to be past tense and update Figures 8.1, 9.1, 11.1 and 12.1 to reflect different modeling tool used to generate figures.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

AB request that new UML profile be normative and covered by a compliance point

  • Key: SACM23-17
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The original proposal of an informative uml profile needs to be made normative and covered by a compliance point.

  • Reported: SACM 2.2 — Tue, 22 Mar 2022 09:45 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Change of Annex F to Normative and add compliance point

    Changing Annex F to be Normative and describe it in section 2 as part of a new compliance point.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Errors in machine consumable files - emof and uml profile

  • Key: SACM23-22
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The emof file has a missing tag and uses an old version of xmi and the uml profile is not of the correct form due to the tooling used to generate it.

  • Reported: SACM 2.2 — Tue, 29 Mar 2022 12:05 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Regenerated SACM machine readable files using MagicDraw

    The eclipse tools we had used to generate the SACM machine readable files of the SACM model and the SACM UML profile were not producing appropriate files.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Figure 8.1 Mislabeled

  • Key: SACM23-3
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Some how Figure 8.1 was relabeled with the same label as Figure 7.2

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:19 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Correct label on Figure 8.1

    Somehow in the revisions to SACM the figure in Section 8.1 was changed to the label used in the previous section (7.2). This needs to be fixed.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

EMOF and UML profile files were html

  • Key: SACM23-16
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The .xml files for emof and uml were github pages in html that had the expected emof and uml information as tables within the html. Need the content by itself.

  • Reported: SACM 2.2 — Tue, 22 Mar 2022 09:34 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Correct content of emof and uml profile files

    Pulled intended content out of html encoded material.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

mistakenly created

  • Key: SACM23-13
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    mistakenly created

  • Reported: SACM 2.2 — Fri, 18 Feb 2022 12:26 GMT
  • Disposition: Duplicate or Merged — SACM 2.3
  • Disposition Summary:

    This issue is extraneous and should be closed

    This issue was accidentally created and should be removed.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

SACM lacks display information for tool interchange

  • Key: SACM23-1
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

    However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

    There are many ways to include such information.

    One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

    An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

    I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

    Thank you for your time.

  • Reported: SACM 2.1 — Sat, 24 Oct 2020 19:06 GMT
  • Disposition: Closed; Out Of Scope — SACM 2.3
  • Disposition Summary:

    Graphical layout formats out of scope of SACM standard

    The requested functionality is out of scope of the SACM work.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

UML profile for SACM

  • Key: SACM23-4
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    To allow for more consistent and direct use of SACM concepts in tools and other environments, a SACM UML profile is needed.

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:21 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Add an annex with a UML profile of SACM

    Add a SACM UML profile to allow UML-based tools to work with SACM concepts by leveraging the SACM UML profile.

    Having the separate explicit UML profile of SACM that is maintained as part of the SACM specification will allow others to leverage that profile. For example, the GSN team can constrain the SACM UML profile into a GSN UML profile in a similar manner to how they leverage the SACM meta-model to define their GSN meta-model, making it cleaner for external groups leveraging GSN.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Terminology Categories need to nest

  • Key: SACM23-2
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    To allow for capturing terminology use as it occurs in communities there is a need to support nesting of categories in SACM’s Terminology Category class.

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:17 GMT
  • Disposition: Resolved — SACM 2.3
  • Disposition Summary:

    Allow Categories to have sub-categories

    Add to SACM::Terminology::Category class a field called category of type Category, with cardinality 0..* allowing composite categories to be directly definable.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

List of companies, copyright dates, and description of changes needed

  • Key: SACM23-5
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    For SACM 2.3 the list of companies involved, their respective copyrights, and a sentence about the scope of SACM 2.3 is needed.

  • Reported: SACM 2.2 — Wed, 16 Feb 2022 22:26 GMT
  • Disposition: Duplicate or Merged — SACM 2.3
  • Disposition Summary:

    This issue is extraneous and should be closed

    This issue was accidentally marked as deferred and balloted. The content of the issue was addressed by resolving SACM23-12. This issue is duplicative of that issue.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Referring to wrong version of SACM

  • Key: SACM22-13
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Section 6.1 is referring to the wrong version of SACM.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:18 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Referring to wrong version of SACM

    Update to refer to 2.1.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in text of 11.7

  • Key: SACM22-19
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Typo in 11.7 ArguementAsset (abstract) first line of section.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:32 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in text of 11.7

    Replace "bsse" with "base".

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in OCL

  • Key: SACM22-17
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Typo first line of OCL, there is an extra space.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:29 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in OCL

    Typo first line of OCL, there is an extra space in the word AssuranceCasePackage.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Section 3.1 Normative References


"ID" never defined in Annex C graphical notation. Is it the gid?

  • Key: SACM22-3
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    Annex C repeatedly refers to an "ID". However, nowhere is an "ID" defined.

    Section 8.1 page 17, figure 8.1, show that every SACMElement has an optional "gid", and that is subclass ModelElement has an optional "name". Either might be an ID, but I can't find any specific statement making that clear. I'm guessing that the gid is the ID, since otherwise you'd have to match all the possible language strings. However, that should be made clear.

    Even more confusingly, an asCited Claim must state a package as well as the claim ID, so it appears that an ID is unique within a package but not between packages. A gid must be unique across the whole model. If IDs are unique across entire model, then in annex C it should made clear that package names are optional in an asCited Claim since they aren't needed to make it unique.

  • Reported: SACM 2.1 — Mon, 26 Oct 2020 03:19 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    ID for graphical elements - should be name not ID

    The figures mistakenly labelled with ID are revised to use name.

  • Updated: Tue, 29 Jun 2021 12:55 GMT

Graphical Notation Dot too small to work in tools.

  • Key: SACM22-26
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The "dot" in SACM 2.1's graphical notations is too small for tool implementation

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:46 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Graphical Notation Dot too small to work in tools.

    Increase "dot" size and update Figures.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Remove duplicate text

  • Key: SACM22-25
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The last sentence of the last paragraph of section 12.1 does not look right (not counting the misspelling of the second occurrence of “Artifacts”).

    Typo - phrase accidentally repeated.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:44 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Remove duplicate text

    Typo - phrase accidentally repeated.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Missing words in 11.11

  • Key: SACM22-23
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Missing "or counter argument" after "counter evidence" in 11.11 Semantics, last line of page.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:41 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Missing words in 11.11

    Insert missing “or counter argument" after "counter evidence" in 11.11.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Missing line break in 11.8

  • Key: SACM22-21
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Missing line break before "needsSupport" in Enumeration Litterals of 11.8.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:35 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Missing line break in 11.8

    Add line break before "needsSupport" to separate terms.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in text of 11.8

  • Key: SACM22-20
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In “Enumeration Litterals” of 11.8

    “Litterals” mis-spelled.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:34 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in text of 11.8

    “Litterals” mis-spelled.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Typo in 11.9

  • Key: SACM22-22
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In 11.9 Semantics, misspelling – “with in” should be “within”

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:38 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Typo in 11.9

    Replace “with in” with “within”

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Wrong package name used in second sentence of 9.3.

  • Key: SACM22-28
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Wrong package name used in second sentence of 9.3.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 16:19 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Wrong package name used in second sentence of 9.3.

    Need to correct package name

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Defining terms used in SACM

  • Key: SACM22-12
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Several terms are used in the specification without definition. Specifically: package binding, package interface, participant package, attribute and property. Defining these terms early in the specification will make it much easier for readers to understand the material.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:17 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Defining terms used in SACM

    Add the following to section 4.

    Attribute
    A feature of a meta-element with a primitive type, such as integer, real, text, boolean, or date.

    Feature
    Super class of attribute and reference.

    Participant Package
    A Participant Package is any Package or Package Interface referenced by a Package Binding.

    Package Binding
    A Package that has references to at least two Participant Packages and to elements of those Participant Packages and defines the relationships among those elements.

    Package Interface
    A Package that is used to specify the elements of one Package that are declared “public” and available for use by other Packages.

    Reference
    A feature of a meta-element whose type is of another meta-element, such as +ParticipantPackage for AssuranceCasePackage

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Section 3.2 Non-normative References

  • Key: SACM22-11
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Section 3.2 Non-normative References, 1 of the references have been updated and there is one new reference to add.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:16 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Section 3.2 Non-normative References

    Shown in pdf, described below.

    Replace:
    Goal Structuring Notation (GSN) Community Standard, Nov 2011. <http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf>

    With:
    Assurance Case Working Group. Goal Structuring Notation Community Standard. Technical Report
    SCSC‐141BA v2.0, Safety Critical Systems Club, 2018. <https://scsc.uk/SCSC-141B>.

    Add to end of list of references:
    Model Based System Assurance Using the Structured Assurance Case Metamodel. R. Wei, TP. Kelly*, X. Dai, S. Zhao, R. Hawkins. Elsevier Journal of Systems and Software (JSS), 154, 211-233, 2019.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Flexibility in relationships

  • Key: SACM22-16
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:26 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Flexibility in relationships

    The relationships discussed in 9.4 should be more flexible – any sub-packages in any AssuranceCasePackage can be used by any other AssuranceCasePackage if the appropriate interfaces and bindings are defined/available.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Clarify bindings and interfaces

  • Key: SACM22-15
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The relationship and use of bindings and interfaces are not well described for packages.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:24 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Clarify bindings and interfaces

    The relationship and use of bindings and interfaces are not well described for packages - propose to add clarifying text for package interface and package binding elements and add an annex with examples.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Confusing use of the term property

  • Key: SACM22-14
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Sections 8.5 & 10.10 the Constraints sections and for 101.10 the Semantics section too, use the word “property”, which is already defined as another part of the model – need to change to another word to avoid confusion.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:20 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Confusing use of the term property

    On pages 19 and 30, change the word “property” to “feature”.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Definition is unclear

  • Key: SACM22-18
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Definition of 11.5 ArgumentPackageBinding is unclear. More details needed to make it understandable and the constraints need enhancement to convey model details.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:30 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Definition is unclear

    Revised to expand description and fixed label in constraints as well as added constrain language.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

  • Key: SACM22-7
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need to revise this section to reflect the new version.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 14:37 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Need to update last paragraph on page 6 to reflect existence of version 2.2 of SACM and describe it.

    Added sentence about the content of SACM 2.2 and revised previous SACM 2.1 content sentence to be past tense. Proposed change in attached pdf.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

SACM lacks display information for tool interchange

  • Key: SACM22-2
  • Status: closed  
  • Source: Linux Foundation ( David A. Wheeler)
  • Summary:

    SACM provides an abstract model for information on assurance cases. However, most humans normally interact with assurance cases shown as diagrams with supporting text. SACM 2.1 finally adds a standard graphical notation, and I'm happy to see it.

    However, SACM currently does not provide enough information to enable sharing diagrams in this notation. For example, there's no positioning or size information for displaying each ArgumentationElement in an ArgumentPackage. Tools do not always do a great job doing automatic layout, and in any case, humans often set up a layout to maximize human understanding. I believe this inability to exchange such information is a serious weakness in SACM.

    There are many ways to include such information.

    One way would be to require sharing display information in a standard form (like SVG) and provide a standard way to map between the SVG display information and the metamodel.

    An alternative is to extend the metamodel to include display information. Some basic constructs from SVG could be borrowed (being maximally compatible with SVG in general is recommended). An ArgumentationElement could have a new optional "location" with contents min_x, min_y, width, and height per SVG. Each ArgumentPackage would establish a viewpoint (and essentially determine portrait, landscape, or some other display is preferred).

    I'm sure there are many details to work out, but the first step is to agree that display information needs to be shared somehow.

    Thank you for your time.

  • Reported: SACM 2.1 — Sat, 24 Oct 2020 19:06 GMT
  • Disposition: Deferred — SACM 2.2
  • Disposition Summary:

    Defer for further discussion

    Exchangeable graphic notations are an interesting addition to the SACM exchange standard for assurance cases but need more discussion.

  • Updated: Tue, 29 Jun 2021 12:55 GMT

Figure 11.1. Missing 'content' composition on ArgumentAsset

  • Key: SACM22-1
  • Status: closed   Implementation work Blocked
  • Source: Dependable Computing, LLC ( Will Hawkins)
  • Summary:

    I hope that this is not an erroneously reported issue. I am still very new to reading through OMG specifications and UML diagrams. Forgive me if this is a waste of your time.

    It appears that the EMOF and the description of ArgumentAsset in section 11.7 on page 38 list a content composition but that composition is not shown in Figure 11.1.

    I hope that this is useful. Thank you for all the great work on standardizing SACM 2.1. It's great to see the version out of Beta!

  • Reported: SACM 2.1 — Fri, 22 May 2020 23:37 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Figure 11.1 is correct but EMOF and text in 11.7 Associations are incorrect

    Updating EMOF file to reflect change and deleting the Associations section from section 11.7 of the SACM specification.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

Clarification of use of AssertedContext

  • Key: SACM22-24
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

  • Reported: SACM 2.1 — Thu, 18 Feb 2021 15:42 GMT
  • Disposition: Resolved — SACM 2.2
  • Disposition Summary:

    Clarification of use of AssertedContext

    The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.

    Corrections for clarity and readability.

  • Updated: Tue, 29 Jun 2021 12:55 GMT
  • Attachments:

New notations for asserted context and asserted artifact context

  • Key: SACM21-109
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The notation previously selected for these concepts could cause confusion when viewed by those familiar with UML notations or when viewing UML notations in proximity to these SACM concepts.

  • Reported: SACM 2.0 — Wed, 20 Mar 2019 20:54 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    New notations for asserted context and asserted artifact context

    Replace diamond line heads with squares with small line at end to distinguish them from UML notations in the 19 figures that used diamond line heads.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

http -> https in MOF file

  • Key: SACM21-84
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS18 - http -> https throughout for omg.org (all URIs)

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:34 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    http -> https in MOF file

    https is not supported in MOF 2.0 and we can not generate MOF 2.5.1 from the version of MagicDraw we have available.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Why MOF 2.0

  • Key: SACM21-83
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS19 - Why MOF 2.0, and not 2.5.1?  If no technical reason, update to 2.5.1.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:33 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Why MOF 2.0

    The MagicDraw version University of York has does not support exporting to MOF any more. We are trying to find any alternatives, but in the meantime we are stuck to this version.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

PNG images

  • Key: SACM21-82
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS17 - The PNG images are less than optimal, and fuzzy throughout Section 11 and Annex C in both clean and changebar docs.  SVG preferred in general.  Can these be regenerated appropriately?

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:33 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    PNG images

    new figures were generated for previous png figures - will be attached to the new report and used in the updated specification.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

!!.14 or 11.14

  • Key: SACM21-81
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS16 - Filename for SACM21-31/!!.14 - A2B.pdf  - I assume this should be 11.14… that’s going to wreak havoc with some filesystems.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:32 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    JIRA file names for files included in Report

    Passed on to Mariano for resolution - no change in specification or issue resolution materials.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

SACM21-1 through 13 were unnecessary

  • Key: SACM21-80
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS15 - SACM21-1 through 13 were unnecessary to add to archive and muddied the waters.  One for Mariano?

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:31 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    SACM21-1 through 13 were unnecessary

    When finishing the previous Report - 14 issues that were resolved in that Report were incorrectly passed to this RTF. Referred to Mariano to resolve.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Issue 55 material includes Issue 30 changes

  • Key: SACM21-79
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS14 - Issue 55 (ptc-19-02-33/SACM21-55/11.11-deletion.pdf) includes editorial ‘that’ to ‘whether’ that is listed in changebar as Issue 30.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:31 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    showing changes from different issue

    removed edit notations from a different issue from 11.11-deletion pdf

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

multiplicity change missing figures

  • Key: SACM21-78
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS13 - Issue 58 (ptc-19-02-33/SACM21-58/11.13 multiplicity.pdf) does not include the graphic for Figure 7.2 on pg 12 and changes on pg 37 11.14 marked as Issue 31, 20 - should not have been in this file.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:30 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    multiplicity change missing figures

    included figures in pdf of changes

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Missing Concrete Syntax in 11.10

  • Key: SACM21-77
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS12 - Issue 20 (ptc-19-02-33/SACM21-20/Concrete Syntax.pdf) does not include the Concrete Syntax added to Section 11.10 Assertion (abstract) and includes an editorial change (‘that’ to ‘whether’) on page 38 Sec 11.13 under Attributes that is not in the changebar or clean documents for issue 20. 

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:29 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Missing Concrete Syntax in 11.10

    Added note of insertion in early pages of Concrete Syntax pdf for missing Concrete Syntax in 11.10. Change in word ”that” to “whether” is correctly marked as Issue 30 (not 20) in the clean and changebar pdfs. Removed from Issue 20’s Concrete Syntax pdf.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Date or date in 12.11

  • Key: SACM21-76
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS11 – In 12.11 Activity, under Attributes, startDate:Date[0..1] does not match naming of type in Figure 12.1, which is startDate:date[0..1] and under Attributes, endDate:Date[0..1] does not match naming of type in Figure 12.1, which is endDate:date[0..1]

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:28 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Date or date in 12.11

    resolve difference

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

newline

  • Key: SACM21-72
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS7 – In 8.6 ModelElement (abstract), under Associations, need a newline between implementationConstraint and description.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:24 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    missing newline

    added newline to address comment

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

multiplicity in figure and text do not match

  • Key: SACM21-71
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS6 – In 8.2 SACMElement (abstract), under Attributes, isCitation and isAbstract do not match multiplicity in Figure 8.1

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:24 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    multiplicity in figure and text do not match

    figure is correct - fix text

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

trailing bullet

  • Key: SACM21-70
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS5 - In 6.2 Acknowledgements, there is an extra trailing bullet.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:23 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    fix trailing bullet

    line after bulleted list has an empty bullet - removed.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SPMS version

  • Key: SACM21-69
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS4 - In 3.2 Non-normative References, SPMS is at 1.2, update doc number to formal/17-11-01.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:23 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    updating SPMS version reference

    In 3.2 Non-normative References, SPMS reference updated.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Typo on pdf pg 10

  • Key: SACM21-68
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS3 - Typo on pdf pg 10: Issues: hhttp in URI -> https

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:22 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    hhttp to https

    typo in url and need to move to https

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

http -> https

  • Key: SACM21-67
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS2 - http -> https throughout for omg.org, please check other sites and changeover as possible for futureproofing ( on omg.org: pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67).

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:22 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    http -> https for document urls?

    Reviewed pdf pgs 1, 3, 4, 9, 10, 16 and pdf pgs 16, 65, 67 and updated urls for https were applicable and resolved broken url for fda document.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SACM21-20 the changes are inconsistent with pdf

  • Key: SACM21-65
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    RB2 – For SACM21-20 the changes are inconsistent with the changes specified in the associated PDF file. In Concrete Syntax.pdf, Figure 11.2 contains the title "Concrete Syntax for ArguementPackage" whereas "ArgumentPackage" is used in the actual text. The misspelled version is still present in the table of contents.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:20 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Arguement-Argument

    Correct spelling now shown in the track changes and clean specifications - see RB2-Arguement-Argument.pdf

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SACM21-14 and SACM21-16 bad urls

  • Key: SACM21-64
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    RB1 – Two of the issues, SACM21-14 and SACM21-16, referred to bad urls and were marked as “Closed; No Change,” but the resolution was not specified – what was done to resolve these two issues?

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:20 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    URL reactivated

    The web site behind the urls had lost its registration on the University of York DSN system – that was fixed in a day or so.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Address missing elements of first 12 issues and address style consistency

  • Key: SACM21-13
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There are several areas where the work packages for addressing issues 1, 2, 3, 5, 6, 7, 9, 11, or 12 missed changes, additions, and deletions to support internationalization and package simplification. Additionally, there are several style issues in the text that need to be made consistent.

  • Reported: SACM 2.0b2 — Fri, 25 Aug 2017 18:13 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Need for the ability to group SACMElements

  • Key: SACM21-12
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:44 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Better support for patterns is needed

  • Key: SACM21-11
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The ability to create patterns (e.g. AssuranceCase patterns, ArgumentPackage patterns, etc) that contain only abstract SACMElements is needed and the patterns should be re-usable.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:42 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Simplification of ArtifactAssetRelationship

  • Key: SACM21-10
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    ArtifactAssetRelationship can be simplified by removing all its sub-classes. The purpose of an ArtifactAssetRelationship can then be recorded by the property +property:Property in the ArtifactAsset class.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Need to simplify the citation classes of SACM

  • Key: SACM21-9
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Citations can be simplified by removing them from Argumentataion, Artifact and Terminology classes and replacing them with +isCitation and +citedElement properties in SACMElement in the Base classes.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:13 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured.

  • Key: SACM21-8
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    If all elements in Argumentation, Terminology, Artifact and AssuranceCase can be considered as artifacts the assertion that one or more artifact provide context for another artifact; and the assertion that one or more artifact support another artifact needs to be captured.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:41 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Need more consistency in packages, interfaces and binding

  • Key: SACM21-7
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.

  • Reported: SACM 2.0b2 — Thu, 24 Aug 2017 20:03 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

SACM needs support for Internationalization

  • Key: SACM21-6
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need to add internationalization of the languages used so that elements can be described using multiple languages

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:14 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Simplification of elements contained in packages

  • Key: SACM21-5
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In packages (e.g. ArgumentPackage, TerminologyPackage), atomic references are too complicated.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:16 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Need to simplify internationalization support in Expressions.

  • Key: SACM21-4
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There is currently no direct mechanism to support internationalization in SACM content.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:16 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Alow AssertedRelationship to express if it is a counter relationship

  • Key: SACM21-3
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:18 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Simplify ArtifactElement and its sub-types

  • Key: SACM21-2
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In SACM, all elements in the Argumentation package, Artifact package, Terminology package, and AssuranceCase package are considered to be Artifacts.

    Consequently ArtifactElement needs to be moved to the Base classes and be a direct sub-type of ModelElement. All elements in other packages then will sub-type ArtifactElement.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Align with American English to support use of SACM by The Open Group

  • Key: SACM21-1
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:21 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly rolled from SACM 2.0 FTF to SACM 2.1 RTF even though addressed/closed

    SACM 2.1 RTF Issues 1-13 were mistakenly rolled over from the SACM 2.0 FTF even though they were addressed and closed in that FTF.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

B and A or A and B

  • Key: SACM21-31
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    p39:Last sentences of 11.13 and 11.14: Is A and B intentionally exchange in "the truth of" parts of the two sentences?

    11.13: "An inference asserted between two claims (A � the source � and B � the target) denotes that the truth of Claim A is said to infer the truth of Claim B."

    11.14: "An AssertedInference between two claims (A � the source � and B � the target) denotes that the truth of Claim B is said to infer the truth of Claim A."

    I would expect that the inference of truth comes from the source and is asserted for the target so the other way than 11.14 Semantics part defines. [Remark: I am not a native English speaker so it might be strange just for me why the "said to infer" expression is used instead of "inferred from". I interpret "The truth of X is said to infer the truth of Y." as "Truth of Y can be inferred from the truth of X." or "The truth of X logically necessitates the truth of Y."- is it correct?]

  • Reported: SACM 2.0 — Sun, 17 Feb 2019 04:03 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    A and B are mistakenly swapped in the specification text

    Need to revise labels in section 11.14 to correctly describe the functionality.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Replace "that" with "whether"?

  • Key: SACM21-30
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    p38, 11.13, Attributes: If "isCounter" seems to be set to false then stating that "a flag indicating that the AssertedRelationship counters its declared purposes" seems to be controversial, although I understand that the "false" is a default value. I think, adding "that whether the AssertedRelationship counters" is more clear. E.g. in 11.10 at a similar case, it writes "indicating the state ..." which was more clear.

  • Reported: SACM 2.0 — Sun, 17 Feb 2019 04:03 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Whether for that

    The observation is correct - replacing "That" with "Whether" in Section 11.13

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Spelling mistake in 11.8

  • Key: SACM21-25
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The section title "Literals" is misspelled.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 19:26 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly opened issue on spelling mistake.

    This is correct in specification - was looking at wrong version.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Spelling mistake in 2.5

  • Key: SACM21-22
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Terminology misspelled as "Termonology" in Section 2.5

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:58 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Again was looking at the wrong version of the SACM file

    The term is correctly spelled - no change needed.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Mistake in element name in 2.3 text

  • Key: SACM21-21
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Mistake in element name – remove “Model” from ArtifactModel::ArtifactPackage

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:56 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Name of element in compliance point mistakenly has "Model" in it

    Revise in specification section 2.3 - SACM 2.0 metamodel is not impacted.
    ArtifactModel::ArtifactPackage should be Artifact::ArtifactPackage

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Concepts in SACM 2 have no direct graphical notation

  • Key: SACM21-20
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Need a concrete syntax for the Argumentation metamodel that can represent the semantic definitions of the elements for semantic transparency, easing the burden of learning the elements and allowing them to be perceived directly from the notation.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:54 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Concrete Syntax and Graphical notation

    As a result of the work by a graduate student at University of York - which was presented in draft at the March and September meetings we now have a proposed graphical notation for the Argumentation portions of SACM. The proposed revisions to the last part of Section 1 to add this to the history of SACM, along with a new compliance point (2.6) for those choosing to support the notation, update to section 5 on symbols, and the specific notations in many parts of section 11, as well as examples in the new Annex C are provided.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Missing role discription for terminology model

  • Key: SACM21-19
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There is no discussion of the terminology model’s role in SACM.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:32 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    No discussion of the role of the terminology model

    In the scope of SACM we should include a discussion of vocabulary and the role of the terminology model at a high level.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Misleading section title for 1.3 Artifact

  • Key: SACM21-18
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The Artifact title is misleading label for this portion of the scope description, this section is actually is about Evidence.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 18:30 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly opened issue on Section number name.

    Thought section was named "Artifact" and wanted to change it to "Evidence" but in fact it was already named that way. Had looked at earlier version of specification.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Outdated constraints for class Claim

  • Key: SACM21-62
  • Status: closed  
  • Source: LogicalHacking.com ( Achim D. Brucker)
  • Summary:

    The constraint section of the class Claims revers to two attributes ("assumed" and "toBeSupported") that are not part of the SACM 2.0 metamodel (they are replaced by the attribute "assertionDeclaration" of type "AssertionDeclaration).

    Proposed fix:

    Remove the constraint section. It is no longer required, as the "exclusive or"-constraint is already enforced by AssertionDeclaration being an enumeration.

  • Reported: SACM 2.0 — Tue, 19 Feb 2019 19:30 GMT
  • Disposition: Duplicate or Merged — SACM 2.1
  • Disposition Summary:

    Duplicative request for removal of constraint from 11.11

    Addressed in ballot 3.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

In 11.13 the +target should have multiplicity of 1

  • Key: SACM21-58
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The multiplicity of +target should be 1 (target:ArgumentAsset[1]).

  • Reported: SACM 2.0 — Mon, 18 Feb 2019 03:18 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    In 11.13 the +target should have multiplicity of 1

    Update text, diagrams, and emof model.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Unnecessary constraint statement in 11.11

  • Key: SACM21-55
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The constraint statement in 11.11 is unnecessary since there is no longer an assumed nor a toBeSupported attribute in the standard

  • Reported: SACM 2.0 — Mon, 18 Feb 2019 02:59 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    remove unnecessary constraint statement in 11.11

    There is no longer an assumed nor a toBeSupported attribute in the standard, can remove the constraint.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Graphical notation for SACM Argumentation concepts

  • Key: SACM21-107
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Shouldn't have a compliance point for the Concrete Syntax as part of this revision.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 20:58 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Graphical notation for SACM Argumentation concepts

    Remove the compliance point and definitions for a graphical notation that maps to all of SACM Argumentation concepts from the body of the specification and putting that graphical notation into an new Annex to parallel the existing notation mappings to SACM contained in Annex A.

    Three supporting pdfs provided to 1) remove compliance point and notation definitions from main body, 2) rename Annex C examples to Annex D, and 3) create new Annex C with graphical notations that represent all SACM Argumentation concepts.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Date or date in 12.9

  • Key: SACM21-75
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS10 – In 12.9 Event, under Attributes, date:Date[0..1] does not match naming of attribute in Figure 12.1, which is occurence:date[0..1]

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:28 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Date or date in 12.9

    aligned text

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Date or date in 12.7

  • Key: SACM21-74
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS9 - In 12.7 Artifact, under Attributes, date:Date[0..1] does not match naming of type in Figure 12.1, which is date:date[0..1]

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:27 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Date or date in 12.7

    align spelling

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

text and figure mismatch ArgumentPackage<-->ArgumentPackageInterface

  • Key: SACM21-73
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    JS8 – In 11.5 ArgumentPackageBinding, under Associations, participantPackage is listed as ArgumentPackageInterface, should be ArgumentPackage to match Figure 11.1.  Change type, or diagram.  The analogous Sec 12.4 ArtifactPackageBinding indicates the diagram here is likely correct.

  • Reported: SACM 2.0 — Mon, 18 Mar 2019 15:26 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    address discrepancy between text and figure

    Figure is correct - made text change

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:


Incorrect description of package

  • Key: SACM21-17
  • Status: closed  
  • Source: TGR Safety Management Ltd ( Timothy G Rowe)
  • Summary:

    The specification relates to ArtifactPackage, but the description of the package describes it as ArgumentPackage.

  • Reported: SACM 2.0 — Tue, 12 Jun 2018 01:56 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Element name mistake in 12.2

    In section 12.2 ArtifactPackage the element is mistakenly named ArgumentPackage - should be ArtifactPackage - correct in model.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Invalid URL

  • Key: SACM21-16
  • Status: closed   Implementation work Blocked
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    Details of the of the mapping between GSN elements and SACM are claimed to be at http://www.goalstructuringnotation.info/gsn-metamodel, but the link is invalid.

  • Reported: SACM 2.0 — Mon, 11 Jun 2018 02:00 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Fixed within a day of being reported

    This broken link was fixed within a few days of being reported.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Association is inconsistent with semantics

  • Key: SACM21-15
  • Status: closed  
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The association `value` is shown as LangString[1..*], but the semantics describe it as a list of ExpressionLangString, not LangString.

  • Reported: SACM 2.0 — Sun, 10 Jun 2018 23:09 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    ExpressionLangString should be LangString

    Correct element name and change criteria from "must" to "should"

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Broken Link

  • Key: SACM21-14
  • Status: closed   Implementation work Blocked
  • Source: gmail.com ( Timothy Rowe)
  • Summary:

    The link "http://www.goalstructuringnotation.info/sacm-examples
    Structured" leads to a "Site Unavailable" page.

  • Reported: SACM 2.0 — Fri, 8 Jun 2018 03:54 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Fixed within a day of being reported

    University of York had an issue with the routing to their web site - resolved shortly after it was reported.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Duplicative paragraphs?

  • Key: SACM21-29
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    p33: the last two paragraphs seem to be the same (from word to word) except the last words: "AssertedContext" and "ArtifactReference". I have no consistent understanding yet but it seems that the second paragraph should be removed (or something else was intended to be written there).

  • Reported: SACM 2.0 — Sun, 17 Feb 2019 04:02 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Duplicative paragraphs needing revision

    The two paragraphs at the bottom of page 33 of the specification need to be rewritten and merged to remove duplicative materials.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Punctuation and spacing errors

  • Key: SACM21-24
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In section 1.4 there is a missing "," after the word "Basically" at the beginning of the second sentence in the second paragraph. In section 9.2 "top level" should be hyphenated in the second sentence of the first paragraph. In the last sentence of section 11.1 the "." at the end is in the wrong place.

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 19:23 GMT
  • Disposition: Resolved — SACM 2.1
  • Disposition Summary:

    Minor edits to address mistakes

    Add comma after Basically in 1.4, in 9.2 hyphenate top-level, and correctly place the period in 11.1

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Spelling mistake in 9.1

  • Key: SACM21-23
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The word contained is spelled as"containined"

  • Reported: SACM 2.0 — Sat, 16 Feb 2019 19:06 GMT
  • Disposition: Closed; No Change — SACM 2.1
  • Disposition Summary:

    Mistakenly opened issue on spelling mistake.

    Word correctly spelled - was looking at the wrong version of SACM.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

Elements in all parts of SACM need to be considered as artifacts and appropriate context and support relationships captured.

  • Key: SACM2_-9
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    If all elements in Argumentation, Terminology, Artifact and AssuranceCase can be considered as artifacts the assertion that one or more artifact provide context for another artifact; and the assertion that one or more artifact support another artifact needs to be captured.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:41 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT

Align with American English to support use of SACM by The Open Group

  • Key: SACM2_-8
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:21 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Simplification of ArtifactAssetRelationship

  • Key: SACM2_-7
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    ArtifactAssetRelationship can be simplified by removing all its sub-classes. The purpose of an ArtifactAssetRelationship can then be recorded by the property +property:Property in the ArtifactAsset class.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Simplify ArtifactElement and its sub-types

  • Key: SACM2_-6
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In SACM, all elements in the Argumentation package, Artifact package, Terminology package, and AssuranceCase package are considered to be Artifacts.

    Consequently ArtifactElement needs to be moved to the Base classes and be a direct sub-type of ModelElement. All elements in other packages then will sub-type ArtifactElement.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:19 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Alow AssertedRelationship to express if it is a counter relationship

  • Key: SACM2_-5
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:18 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Need to simplify internationalization support in Expressions.

  • Key: SACM2_-4
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There is currently no direct mechanism to support internationalization in SACM content.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:16 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT

Simplification of elements contained in packages


Need to simplify the citation classes of SACM

  • Key: SACM2_-1
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Citations can be simplified by removing them from Argumentataion, Artifact and Terminology classes and replacing them with +isCitation and +citedElement properties in SACMElement in the Base classes.

  • Reported: SACM 2.0b2 — Thu, 3 Aug 2017 19:13 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Better support for patterns is needed

  • Key: SACM2_-10
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The ability to create patterns (e.g. AssuranceCase patterns, ArgumentPackage patterns, etc) that contain only abstract SACMElements is needed and the patterns should be re-usable.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:42 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT

Need for the ability to group SACMElements

  • Key: SACM2_-11
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.

  • Reported: SACM 2.0b2 — Tue, 22 Aug 2017 15:44 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

SACM needs support for Internationalization


Need more consistency in packages, interfaces and binding

  • Key: SACM2_-24
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.

  • Reported: SACM 2.0b2 — Thu, 24 Aug 2017 20:03 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:10 GMT
  • Attachments:

Address missing elements of first 12 issues and address style consistency

  • Key: SACM2_-26
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    There are several areas where the work packages for addressing issues 1, 2, 3, 5, 6, 7, 9, 11, or 12 missed changes, additions, and deletions to support internationalization and package simplification. Additionally, there are several style issues in the text that need to be made consistent.

  • Reported: SACM 2.0b2 — Fri, 25 Aug 2017 18:13 GMT
  • Disposition: Deferred — SACM 2.0
  • Disposition Summary:

    deferred

  • Updated: Sun, 3 Feb 2019 18:09 GMT
  • Attachments:

There is no compliance point for those that support/use the Terminology Package specified in SACM 2.0’s metamodel.

  • Key: SACM2-73
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In making support for the Terminology Package optional a compliance point for those that want to support the Terminology Package was mistakenly left out.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:04 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    Add a Terminology Package Compliance point

    In the first sentence of section 2.1 change “three” to “four”; in bulleted list in section 2.1 add a fourth bulleted item “Terminology Model”; and add a new section “2.5 Terminology Model compliance point”, with the text “Software that conforms to the specification at the Terminology Model compliance point shall be able to import and export XMI documents that conform with the SACM XML Schema produced by applying XMI rules to the normative MOF metamodel defined in this entire specification. The top object of the Terminology package as a unit of interchange shall be the SACM::TerminologyPackage element.

    The Conformance clause identifies with clauses of the specification are mandatory (or conditionally mandatory) and which are optional for an implementation to claim conformance to the specification.”

    See pdf “Adding Terminology Compliance Point.pdf” for markup of proposed changes.

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

Model uses undefined ‘date’ type.

  • Key: SACM2-72
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Currently, the Artefact, and Activity classes use the type ‘date’ for some of their attributes, and the ‘date’ attribute is missing from the model and diagrams for ActivityEvent, despite appearing in the text of the specification.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:03 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    Change date to string

    In section 12.5.2 (Attributes of Artefact class) change “date: Date” to “date: String”. In section 12.5.4 (Attributes of ArtefactEvent class) add “date: String”. In section 12.5.6 (Attributes of Activity class) change “startTime: Date” to “startTime: String” and “endTime: Date” to “endTime: String”.

    See pdf “Model uses undefined date type.pdf” for markup of proposed changes to Figure 2 and 12.1

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

In the classes related to Citations, the terms Element and Asset are inconsistently used.

  • Key: SACM2-71
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    The 31 uses of the class name “ArtefactElementCitation” and the 10 uses of the class name “ArgumentElementCitation” are inconsistent with the 20 uses of the class name “ArtefactAssetCitation” and 7 uses of the class name “ArgumentAssetCitation”.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:02 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    Align terminology to use '...AssetCitation(s)'

    To be consistent across the SACM 2.0 metamodel the “ArtefactElementCitation” and “ArgumentElementCitation” uses should be changed to “ArtefactAssetCitation” and “ArgumentAssetCitation” respectively, the class “ArtefactElementCitation” in figure 6 should be changed to “ArtefactAssetCitation”, and the 2 uses of the term “citedElement” should be changed to “citedAsset”.

    See the pdf “terms Element and Asset are inconsistently used in citation-related classes.pdf” for markup of proposed changes.

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

Section 2 doesn’t make it clear that AssuranceCase compliance point is mandatory.

  • Key: SACM2-70
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Section 2 doesn’t make it clear that AssuranceCase compliance point is mandatory. Also, some text in section 2.4 should be moved to precede all the compliance point descriptions.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:01 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    Make it clear that the Assurance Case compliance point is mandatory.

    The sentence, “This compliance point is mandatory.” should be added at the beginning of the first paragraph of Section 2.4. The second paragraph should be moved to immediate follow the bullet point list of compliance points at the beginning of Section 2.

    See the pdf “AssuranceCase compliance point is mandatory.pdf” for markup of proposed changes.

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

Incorrect description of the Argumentation compliance point.

  • Key: SACM2-69
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    In the second paragraph of Section 2.1 there is currently the text, “The ‘ArtefactElementCitation’ class shall not be used.” This is incorrect. The ArtefactElementCitation class is still necessary for the use of Argumentation compliance point.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:01 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    Correct erroneous text about 'ArtefactElementCitation’ class

    Omit the sentence. “The ‘ArtefactElementCitation’ class shall not be used.”

    See the pdf “Incorrect description of the Argumentation compliance point.pdf” for markup of proposed changes.

  • 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

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

The SACM 2.0 meta-model requires implementation of the Terminology Package in spite of the text of Chapter 2 on compliance points saying it is optional.

  • Key: SACM2-68
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Because all the significant classes of the argumentation and artefact package inherit from ModelElement, and ModelElement must use the Description class to provide content (e.g. the text of a Claim), and Descriptions must (given the current multiplicity) contain an Expression object, both argumentation and artefact packages must use the terminology package.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:00 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    Fix model to allow Terminology Package to be optional as intended

    The multiplicity from TaggedValue to Expression and UtilityElement to Expression must be changed from ‘1’ to ‘0..1’ to allow this to be optional. In addition, a new attribute called “sExpression: String” (referring to ‘simple expression’) should be added to UtilityElement, and an additional attribute called “sKey: String” (referring to ‘simple Key’) should be added to TaggedValue.

    In Section 8.4 (The description of UtilityElement) the following text needs to be added:

    “Attributes
    sExpression: String – the text that describes the value of the UtilityElement”

    and

    “Constraints
    If an Expression class is associated (through the expression association) with UtilityElement then sExpression should be null”

    In Section 8.8 (The description of TaggedValue) the following text needs to be added to the current ‘Attributes’ section:

    “sKey: Expression – the text that describes the key of the tagged value”

    and the following text to the existing ‘Constraints’ section:

    “If an Expression class is associated (through the key association) with TaggedValue then sKey should be null”

    See the pdf “The SACM 2.0 meta-model requires implementation of the Terminology Package.pdf” for markup of proposed changes to figures and “Terminology Package Implementation-8.4 and 8.8.pdf” for text changes.

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

Inconsistent use of the word “Model” in describing the three compliance points

  • Key: SACM2-67
  • Status: closed  
  • Source: MITRE ( Mr. Robert Martin)
  • Summary:

    Of the three compliance points, one is referred to with the word “Model” while the other two are not. All three should consistently use this word in describing the compliance points. Additionally, two times “model” is used instead of “Model”.

  • Reported: SACM 2.0b1 — Thu, 29 Dec 2016 19:00 GMT
  • Disposition: Resolved — SACM 2.0
  • Disposition Summary:

    Change section 2 to be consistent in use of term "model"

    In the bulleted list in section 2.1; the title of section 2.2; the first sentence of the first and second paragraphs of section 2.2; section 2.3; the title of section 2.4; and the first sentence of the first paragraph replace the text “Argumentation” and “Assurance Case” with “Argumentation Model” and “Assurance Case Model” respectively and replace “Artefact model” with “Artefact Model”.

    See pdf “Use of word Model in Chapter 2.pdf” for markup of proposed changes.

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

Assurance Cases under development or Incomplete

  • Key: SACM2-17
  • Legacy Issue Number: 16289
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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

Properties as Assertions

  • Key: SACM2-23
  • Legacy Issue Number: 16505
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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 ( Mr. 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

Justification of Methods of Reasoning

  • Key: SACM2-18
  • Legacy Issue Number: 16514
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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

Property Inherence Hierarchy

  • Key: SACM2-16
  • Legacy Issue Number: 16507
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. Samuel Redwine)
  • Summary:

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

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

    Addressed by harmonization to create SACM 2.0.

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

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

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

  • Key: SACM2-22
  • Legacy Issue Number: 16510
  • Status: closed  
  • Source: MITRE ( Mr. 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

Making Role Binding and SBVR more generally available

  • Key: SACM2-21
  • Legacy Issue Number: 16509
  • Status: closed  
  • Source: MITRE ( Mr. 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

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

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

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

  • Key: SACM2-15
  • Legacy Issue Number: 16861
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

Add missing definitions to SBVR Vocabulary in Annex A

  • Key: SACM2-1
  • Legacy Issue Number: 17335
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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

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

EvidenceProperty inherit from Property

  • Key: SACM2-27
  • Legacy Issue Number: 16882
  • Status: closed  
  • Source: MITRE ( Mr. 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

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 ( Mr. 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 ( Mr. 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

Scope of availability of change management information

  • Key: SACM11-2
  • Legacy Issue Number: 16281
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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 ( Mr. 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

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

  • Key: SACM11-11
  • Legacy Issue Number: 16510
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. Samuel Redwine)
  • Summary:

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

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

    Deferred as still valid for SACM

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

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

Assurance Cases under development or Incomplete

  • Key: SACM11-4
  • Legacy Issue Number: 16289
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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

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

  • Key: SACM11-6
  • Legacy Issue Number: 16313
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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

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 ( Dr. 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

Usage of Specializations of Claim

  • Key: SACM11-14
  • Legacy Issue Number: 16517
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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

InformationAssertion Dependencies on other Elements

  • Key: SACM11-17
  • Legacy Issue Number: 16521
  • Status: closed  
  • Source: MITRE ( Mr. 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 ( Mr. 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 ( Mr. 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

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:

"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

Use uniform 'statement' language for describing evidence properties

  • Key: SACM11-42
  • Legacy Issue Number: 17336
  • Status: closed  
  • Source: KDM Analytics ( Dr. 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 ( Dr. 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 ( Dr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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

typo: facctype section 12.3.1

  • Key: SACM11-91
  • Status: closed  
  • Source: MITRE ( Mr. Robert 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

editing error & typo in 10.1.1 & 10.2.3

  • Key: SACM11-93
  • Status: closed  
  • Source: MITRE ( Mr. Robert 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:

Rationalizing Citations within the Argumentation structure

  • Key: SACM11-82
  • Status: closed  
  • Source: MITRE ( Mr. Robert 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 ( Mr. Robert 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:

AssertedRelationship Class

  • Key: SACM11-85
  • Status: closed  
  • Source: MITRE ( Mr. Robert 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 ( Mr. Robert 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 ( Mr. Robert 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:

Incorrect URL for SACM in Appendix B

  • Key: SACM_-2
  • Legacy Issue Number: 17432
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Annex B (updated by Issue 16695) has the same problems as the XSD file (below), and further has no URI at all in the declaration of namespace SACM. Also oddly TARGET and TRUE are capitalized for no reason

    The namespaces declared for the SACM namespaces e.g. xmlns:SACM="http://schema.omg.org/SACM/1.0" are inconsistent with those in the inventory.

    Correct URLs are:

    xmlns:ARM="www.omg.org/spec/SACM/20120501/Argumentation" schemaLocation="http://www.omg.org/spec/SACM/20120501/Argumentation.xsd"

    xmlns:EM=" www.omg.org/spec/SACM/20120501/Evidence" schemaLocation="http://www.omg.org/spec/SACM/20120501/Evidence.xsd"

    xmlns:SACM=" www.omg.org/spec/SACM/20120501/SACM" schemaLocation="http://www.omg.org/spec/SACM/20120501/SACM.xsd"

  • Reported: SACM 1.0b2 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.0
  • Disposition Summary:

    Change example in section B.1 into the following:
    <?xml version="1.0" encoding="ASCII"?>
    <ARM:Argumentation xmi:version="2.1"
    xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ARM=" www.omg.org/spec/SACM/20120501/Argumentation"
    xmi:id="0" id="IPSA">
    <xsd:import namespace=http://schema.omg.org/spec/XMI/2.1"
    schemaLocation="http://www.omg.org/spec/XMI/20071213/XMI.xsd"/>
    <xsd:import namespace="www.omg.org/spec/SACM/20120501/Argumentation" schemaLocation="
    http://www.omg.org/spec/SACM/20120501/Argumentation.xsd" />
    <argumentElement xsi:type="ARM:Claim" xmi:id="1" id=“C1" description="" content="C/S logic is fault
    free"/> <argumentElement xsi:type="ARM:ArgumentReasoning" xmi:id="2" id=“RC1.1" content="Argument by
    omission of all identified software hazards" describes="5 6"/>
    <argumentElement xsi:type="ARM:ArgumentReasoning" xmi:id="3" id=“RC1.2" content="Argument by
    satisfaction of all C/S safety requirements" describes="7 8 9"/>
    <argumentElement xsi:type="ARM:InformationElement" xmi:id="4" id=“IRC1.1" description="Identified
    software hazards"/>
    <argumentElement xsi:type="ARM:Claim" xmi:id="5" id=“C1.1" description="" content="Unintended
    opening of press (after PoNR) can only occur as a result of component failure"/>
    <argumentElement xsi:type="ARM:Claim" xmi:id="6" id=“C1.2" description="" content="Unintended
    closing of press can only occur as a result of component failure"/>
    <argumentElement xsi:type="ARM:Claim" xmi:id="7" id=“C2.1" content="Press controls being 'jammed
    on' will cause press to halt"/>
    <argumentElement xsi:type="ARM:Claim" xmi:id="8" id=“C2.2" content="Release of controls prior to
    press passing physical PoNR will cause press operation to abort"/>
    <argumentElement xsi:type="ARM:Claim" xmi:id="9" id=“C2.3" description="" content="C/S fails safe
    (halts on) and annunciates (by sounding Klaxon) all component failures" toBeSupported=”true”/>
    <argumentElement xsi:type="ARM:Claim" xmi:id="12" id=“C2.1.1" content="Failure 1 of PLC state
    machine includes BUTTON_IN remaining true"/>
    <argumentElement xsi:type="ARM:Claim" xmi:id="13" id=“C2.2.1" content="Abort transition of PLC
    state machine includes BUTTON_IN going false"/>
    <argumentElement xsi:type="ARM:InformationElement" xmi:id="10" id=“S1.1" content="Fault tree
    analysis cutsets for event 'Hand trapped in press due to command error'"/>
    <argumentElement xsi:type="ARM:InformationElement" xmi:id="11" id=“S1.2" content="Hazard directed
    test results"/>
    <argumentElement xsi:type="ARM:InformationElement" xmi:id="14" id=“S2.1" description=""
    content="black box testing"/>
    <argumentElement xsi:type="ARM:InformationElement" xmi:id="15" id=“S2.2.1" content="C/S state
    machine"/>
    <argumentElement xsi:type="ARM:AssertedInference" xmi:id="16" id=“C1.1.1" description=""
    source="5" target="1"/>
    <argumentElement xsi:type="ARM:AssertedInference" xmi:id="17" id=“C1.1.2" source="6" target="1"/>
    <argumentElement xsi:type="ARM:AssertedInference" xmi:id="18" id=“C1.2.1" source="7" target="1"/>
    <argumentElement xsi:type="ARM:AssertedInference" xmi:id="19" id=“C1.2.2" source="8" target="1"/>
    <argumentElement xsi:type="ARM:AssertedInference" xmi:id="20" id=“C1.2.3" source="9" target="1"/>
    <argumentElement xsi:type="ARM:AssertedContext" xmi:id="21" id=“CIRC1.1" source="4" target="2"/>
    <argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="22" id=“S1.1" source="10" target="5 6"/>
    <argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="23" id=“S1.2" source="11" target="5 6"/>
    <argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="24" id=“SC2.1" source="14" target="7"/>
    <argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="25" id=“SC2.1.1" source="15"
    target="12"/>
    <argumentElement xsi:type="ARM:AssertedEvidence" xmi:id="26" id=“SC2.2.1" source="15"
    target="13"/>
    <argumentElement xsi:type="ARM:AssertedInference" xmi:id="27" id=“DI C2.1" source="12"
    target="7"/>
    <argumentElement xsi:type="ARM:AssertedInference" xmi:id="28" id=“DI C2.2" source="13"
    target="8"/>
    <argumentElement xsi:type="ARM:AssertedContext" xmi:id="29" id=“AR29" source="2" target="16
    17"/>
    </ARM:Argumentation>
    Change example in section B.2 into the following:
    <?xml version="1.0" encoding="ASCII"?>
    <ARM:Argumentation xmi:version="2.1"
    xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ARM=" www.omg.org/spec/SACM/20120501/Argumentation"
    xmi:id="0" id="BSC11">
    <xsd:import namespace=http://schema.omg.org/spec/XMI/2.1"
    schemaLocation="http://www.omg.org/spec/XMI/20071213/XMI.xsd"/>
    <xsd:import namespace="www.omg.org/spec/SACM/20120501/Argumentation" schemaLocation="
    http://www.omg.org/spec/SACM/20120501/Argumentation.xsd" />
    <argumentElement xsi:type="ARM:Claim" xmi:id="1" id=“Bluetooth secure" content="A bluetooth
    enabled network provides adequate security"/>
    <argumentElement xsi:type=“ARM: Claim" xmi:id="2" id=“Availability" content="A bluetooth enabled
    network is adequately available [1] Section 1 para 3"/>
    <argumentElement xsi:type=“ARM: Claim" xmi:id="3" id=“Access" description="" content="A bluetooth
    enabled network provides adequate control for access to services and data [1] Section 1 para 3"/>
    <argumentElement xsi:type=“ARM: Claim" xmi:id="4" id=“Confidentiality" content="A bluetooth
    enabled network provides adequate levels of confidentiality [1] Setion 1 para 3"/>
    <argumentElement xsi:type=“ARM: Claim" xmi:id="5" id=“Integrity" content="A bluetooth enabled
    network provides adequate levels of integrity [1] Section 1 para 3"/>
    <argumentElement xsi:type=“ARM: InformationElement" xmi:id="6" id=“Context: security policy and
    scenario for use" content="Definitions are required of the intented security policy and the scenario of use
    for the system, including what is regarded as 'adequate'"/>
    <argumentElement xsi:type=“ARM: InformationElement" xmi:id="7" id=“References" content="[1]
    Bluetooth security white paper 19/4/ 02"/>
    <argumentElement xsi:type=“ARM: InformationElement" xmi:id="8" id=“Definition: Availability"
    content="The system is capable of providing requested services to authorised users, in an
    acceptable/defined time"/>
    <argumentElement xsi:type=“ARM: InformationElement" xmi:id="9" id=“Definition: Access"
    content="Only users permitted by the defined security policy have access to services and data"/>
    <argumentElement xsi:type=“ARM: InformationElement" xmi:id="10" id=“Define: Confidentiality"
    content="Unauthorised persons cannot intercept and understand information to which they are not
    entitled"/>
    <argumentElement xsi:type=“ARM: InformationElement" xmi:id="11" id=“Define: Integrity"
    description="" content="Services and data are provided to authorised users as intended and without
    corruption"/>
    <argumentElement xsi:type=“ARM: AssertedContext" xmi:id="12" id=“AC1" source="7" target="1"/>
    <argumentElement xsi:type=“ARM: AssertedContext" xmi:id="13" id=“AC2" source="6" target="1"/>
    <argumentElement xsi:type=“ARM: AssertedContext" xmi:id="14" id=“AC3" source="8" target="2"/>
    <argumentElement xsi:type=“ARM: AssertedContext" xmi:id="15" id=“AC4" source="9 " target="3"/>
    <argumentElement xsi:type=“ARM: AssertedContext" xmi:id="16" id=“AC5" source="10" target="4"/>
    <argumentElement xsi:type=“ARM: AssertedContext" xmi:id="17" id=“AC6" source="11" target="5"/>
    <argumentElement xsi:type=“ARM: AssertedInference" xmi:id="18" id=“AI1" source="5 4 3 2"
    target="1"/>
    <argumentElement xsi:type=“ARM: ArgumentReasoning" xmi"id="19" id=“Argue over vulnerabilities"
    description="" content="Argue for each security requirement identified in the security white paper"
    describes="18"/>
    </ARM:Argument>

  • Updated: Sun, 8 Mar 2015 13:50 GMT

Duplicate rolename 'subject' in class 'ProvidesContext'

  • Key: SACM_-3
  • Legacy Issue Number: 17433
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Class ProvidesContext Figure 14.3 already inherits the 'subject' association from the EvidenceInterpretation element.

  • Reported: SACM 1.0b2 — Tue, 19 Jun 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.0
  • Disposition Summary:

    Remove association 'subject' from class 'ProvidesContext' (section 14.3.6, page 98):
    subject:EvidenceElement[1]The subject of the ProvidesContext clause
    Change Figure 14.3 with the following: << figure on p 134 of ptc/2012-06-04>>

  • Updated: Sun, 8 Mar 2015 13:50 GMT

Association names should be nouns

  • Key: SACM_-1
  • Legacy Issue Number: 17369
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Applies to: Sysa/10-03-15, section 8.1

    Title: Association names should be nouns

    Detail: The association names between classes in ARM should be labelled
    with nouns. This will better conform to the OMG naming recommendations.

  • Reported: SACM 1.0b2 — Tue, 15 May 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.0
  • Disposition Summary:

    Update the document as follows, assuming resolution for issue 17347 has already been applied
    Argumentation class (was previously 9.2.3, and has been renamed from Argument by other edits),
    Association
    “containsArgumentelement:ArgumentElement[0..*]” -> “argumentElement:ArgumentElement[0..*]
    “containsArgumentation:Argumentation[0..*]” -> “argumentation:Argumentation[0..*]
    CitationElement class (previously 9.2.8), Associations
    “refersToArgumentelement:ArgumentElement[0..1]” ->
    “argumentElementReference:ArgumentElement[0..1]
    “refersToArgument:Argument[0..1]” -> “argumentationReference:Argumentation[0..1]
    ArgumentReasoning class (previously 9.2.11), Associations
    “hasStructure:Argument[0..1]” -> “structure:Argument[0..1]
    “describes:AssertedInference [0..*]” -> “describedInference:AssertedInference [0..*]
    Replace figure 9.1 with the following << figure on p 129 of ptc/2012-06-04>>

  • Updated: Sun, 8 Mar 2015 13:50 GMT

Integration issue: introductory text should cover SAEM introductory material

  • Key: SACM-145
  • Legacy Issue Number: 16840
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration issue: introductory text should cover SAEM introductory material

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

    Replace section 7.5. Evidence Metamodel with the following:
    7.5. Precise statements related to evidence
    In the simplest form, evidence consists of a collection of documents or records that provide evidentiary
    support to a set of claims. These claims are called subject claims, as the are made by an argument related to
    some selected subject area. Subject claims are different from evidence claims, which are the assertions
    about the evidence items that help establish the exact nature of the evidentiary support they provide to the
    subject claims in a clear, comprehensive and defensible way. Evidence claims can be reused as opposed to
    subject claims and arguments, which are specific to each subject area for which an assurance case is
    developed. Thus the SACM Evidence Metamodel defines the evidence vocabulary for constructing precise
    statements related to evidence. Evidence vocabulary is reused in every argument for various diverse subject
    areas.
    The Evidence Metamodel defines an interchange format for evidence (XSD schema defined through the
    application of XMI rules defined by MOF and XMI specifications) in which each evidence element,
    including claims about evidence, is represented by a specific XML tags. The evidence interchange format is
    then utilized to exchange bodies of evidence related to specific projects that require argumentation, for
    example, in presenting an assurance case. describing evidence-related efforts, including
    Collection of evidence
    Management of evidence
    Interpretation of evidence
    Evaluation of evidence
    Collection of Evidence includes activities of identifying evidence items, and recording various information
    about them, including their origin, timing and custody. Evidence Metamodel defines precise statements
    related to the pedigree of an evidence item, including evidence collection method or tool used.
    The primary items of evidence are Documents, Records, Assertions and Objects. Documents may have
    Properties that are characteristics independent of an assurance case being developed.
    Properties in the Evidence Metamodel include the following:
    Fundamental characteristics of Documents, for example
    Media of document
    Language of document
    Security classification of document
    Quality of Documents, for example
    Primary or secondary document
    Original or derived document
    Consistency
    Completeness
    Accuracy
    Management of Evidence compliments evidence collection activities with some planning and tracking
    activities. Important to the management of evidence is the set of Project Elements, including an Evidence
    Container, for grouping evidence items and assertions, as well as several elements for planning
    management collection Activities, including their dependencies, objectives, input and output data, and the
    evidence requests, which are the placeholders for evidence items that are being planned to be obtained.
    Combined with the evidence events, provenance, custody and timing clauses, these project elements are
    powerful enough to support management of evidence-related efforts and interchange of the relevant
    managerial data as part of evidence packages.
    Provenance of Evidence Elements, for example
    Who created
    Who approved
    Who owns
    Custody of Evidence Elements, for example
    Where the element was aquired
    Where the element is located
    Who is the custodian of the element
    Timing of Evidence Elements, for example
    When the element was created or acquired
    Effective Time of an assertion
    Interpretation of Evidence includes activities of assigning meaning to documents (what a document is,
    what claims does it make, etc). Interpretation of evidence is an important step in legal community, when a
    physical object is submitted as evidence.
    The following assertions are made to establish the meaning of evidence items.
    Meaning of Documents, for example
    Definition
    Meaning
    Scope
    Characteristics
    Evaluation of Evidence includes the activities of making certain assertions about evidence items and their
    relation to subject claims.
    Evidence Assertions are defined within the Evidence Metamodel and include the following categories: Quality Attributes of Evidentiary Support
    Direct or indirect
    Relevance
    Confidence
    Strength
    Significance
    Nature of the Evidentiary support
    Supports
    Challenges
    Observations and Resolutions
    The entire evidence package needs to be evaluated
    Relations between Evidence Items need to satisfy one of the well-defined “Standards of proof,” such as
    Clean and Convincing Evidence (CCE)
    Preponderance of evidence (POE)
    Resolved Counter Evidence (RCE), often used in the field of Genealogy as the Genealogical Proof
    Standard
    Beyond the reasonable doubt (BRD)
    The following diagram is related to the so-called Resolved Counter Evidence Proof Standard, which
    illustrates the steps involved in evaluating evidence.
    Remove section 7.8 Evaluation of Evidence
    Remove section 7.9. Design Characteristics of the Evidence Metamodel
    Replace introductory text to Part 3, page 33, with the following:
    This part of the Strucutred Assurance Case Metamodel defines the normative SACM Evidence Metamodel.
    SACM Evidence Metamodel consists of 18 class diagrams. SACM Evidence Metamodel is delivered as a
    single UML subpackage ‘Evidence’ of SACM.
    The SACM Evidence Metamodel consists of the following logical parts:
    Evidence Items
    Formal Elements
    Evidence Assertions
    Administration
    The Evidence Items part defines the physical evidence, provided in the form of documents, records and
    sometimes other material exhibits. The Formal Elements part defines the logical assertions, provided in
    the form of individual propositions. These propositions use an external vocabulary related to the subject
    area for which an argument is being provided. The Formal Elements part defines a subset of an OMG
    Semantics of Business Vocabularies and Business Rules (SBVR) fact model in the form of atomic
    formulations based on fact types with role bindings to individual concepts. SBVR is not used directly
    because of the semantic differences between fact models in linguistic models as they are defined in SBVR,
    conceptual models and “asserted fact models” involved in evidence collection and evaluation. Formal
    Elements represent a conceptual model underlying the entire assurance case. Evidence Assertions part
    defines various statements that can be made about the evidence items, such as documents, records and
    exhibits, and their relations to the subject area claims. Evidence Assertions includes statements that are
    related to various esential properties of evidence items. A large group of statements are the so-called
    evidence evaluations, including assertions of the evidentiary support (relations between evidence items and
    the subject area claims), assertions related to the interpretation of physical evidence and document,
    assertions about the conflicts in evidenctiay support and resolutions of these conflicts. Other statements are
    assertions related to provenance, custody and timing of the evidence items and evidence evaluations. The
    last group of statements qualify the evidentiary support that evidence items confer on the subject area
    claims. The Administration part defines an EvidenceContainer element which organizes individual
    evidence items and evaluations into a package that becomes a unit of exchange. The Administrative part
    also provides several means for managing evidence collection projects.
    Remove Figure 10.1 in Part 3 (page 33)

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

We need a common route to support instance packaging

  • Key: SACM-152
  • Legacy Issue Number: 16855
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    we need a common route to support instance packaging. Proposal is to use “Assurance
    repository” as the main packaging element.

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Add Figure Administration to chapter 8 SACM Assurance Case as follows: << diagram on p 117 of ptc/2012-06-04>> Add section Administration
    This section describes the common elements of SACM that are involved in managing
    assurance cases, exchanging assurance cases and related concerns. The elements
    described in this chapter organize instances of SACM. In particular, this section defines
    the root object of an assurance case - the AssuranceCase element. This element contains
    other objects in the assurance case, such as the Argumentation objects and
    EvidenceContainer objects and constitutes a unit of exchange using the SACM as the
    protocol.
    In addition, the SACM Argumentation Metamodel and the SACM Evidence Metamodel
    constitute two independent protocols within SACM, so Argumentation packages can be
    developed and exchanged using the Argumentation elements, and also the
    EvidenceContainers can be developed, managed and exchanged independently of the
    Argumentation elements or in combination with them. Independently developed
    Argumentation packages and EvidenceContainer packages can be later assembled into
    complete assurance cases. Specifications of the Evidence Metamodel can be used to
    develop an evidence repository that can be used to store and manage evidence in support
    of multiple assurance cases.
    Add sub section AssuranceCase
    AssuranceCase
    AssuranceCase element Superclass
    ModelElement
    Attributes
    name:String the name of the assurance case
    gid:String the globally unique identifier assigned to the current assurance case
    Associations
    argument:Argumentation::Argumentation[0..*] the argument component of the assurance
    case
    evidence:Evidence::EvidenceContainer[0..*] the evidence component of the assurance
    case
    Semantics
    An AssuranceCase element represents assurance cases as defined in ISO/IEC 15206.
    Argument and Evidence components of an AssuranceCase are optional which allows
    representing incomplete assurance cases.
    An AssuranceCase element involves both a globally unique "gid" and a locally unique
    "id". The global referencing scheme may involve gid+id combination, while a local
    scheme may use id component.

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

Using the term 'Argument' as the container for the "Claims-Argument-Evidence" aspect of ARM is confusing as people expec

  • Key: SACM-151
  • Legacy Issue Number: 16852
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Using the term 'Argument' as the container for the "Claims-Argument-Evidence" aspect of ARM is confusing as people expect to see Claim first.

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

    Heading -> Rename to “Argumentation Class”
    Para 1, 2nd word -> rename to “Argumentation”
    Associations section -> rename association “containsArgumentLink” into
    containsArgumentation" The nested Argumentation contained in a given instance of an
    Argumentation.
    Semantics section, first sentence -> delete “and ArgumentLinks between
    ArgumentElements”
    Semantics section add after 1st sentence: "Argumentation elements can be nested."
    Section 9.2.9 Claim Class
    First para, first sentence -> change “structured Argument.” to “structured
    Argumentation”
    Edit section 9.2.8. CitationElement as follows:
    change the 1st sentence from " The CitationElement Class cites an Argument, or an
    ArgumentElement within another Argument, for use within an Argument"
    into
    The CitationElement Class cites an Argumentation, or an ArgumentElement within
    another Argumentation, for use within the current Argumentation.
    in subsection Associations change 'refersToArgument:Argument[0..1] into
    "refersToArgumentation:Argumentation[0..*] References to Argumentation.
    change 'refersToArgumentElement;ArgumentElement[0..1] into
    "refersToArgumentElement:ArgumnetElement[0..*]
    Replace Argumentation Metamodel diagram Figure 9.1 according to the new Figure 9.1
    in related resolution 17347 that addresses other model improvements. change the semantics subsection from:
    Within an Argument (package) it can be useful to be able to cite elements of an
    Argument (i.e., ArgumentElements) to act as explicit proxies for those elements acting
    within the argument structure. For example, in supporting a Claim it may be useful to
    cite a Claim or InformationElement declared within another Argument. It can also be
    useful to be able to cite entire Arguments. For example, in supporting a Claim it may be
    useful to cite an existing (structured) Argument.
    into
    Within an Argumentation (package) it can be useful to be able to cite elements of an
    Argumentation (i.e., ArgumentElements) to act as explicit proxies for those elements
    acting within the argumentation structure. For example, in supporting a Claim it may be
    useful to cite a Claim or InformationElement declared within another Argumentation. It
    can also be useful to be able to cite entire Argumentationss. For example, in supporting a
    Claim it may be useful to cite an existing (structured) Argumentation.

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

evidence evaluation attributes

  • Key: SACM-147
  • Legacy Issue Number: 16846
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Some of the evidence evaluation attributes were allowed to be applied to exhibit, rather than the relation between exhibit and evidence assertion

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

    Action - text describing Accuracy subclass to be improved to make it clear it is on the
    link.
    This issue has been resolved due to resolutions of related issues 16730 and 168737.
    Disposition: Merged

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

Lack of agreement the attribute types for some of the evidence evaluation subtypes - e.g. confidence 0..100 as integer

  • Key: SACM-146
  • Legacy Issue Number: 16845
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Lack of agreement in the attribute types for some of the evidence evaluation subtypes - e.g. confidence 0..100 as integer

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

    In diagram "EvidenceAttributes" add concrete class "ExtendedEvidenceAttribute" and
    make it a subclass of the abstract class EvidenceAttribute.
    In section Evidence Attributes Class Diagram replace Figure EvidenceAttributes Class
    Diagram with the following: <<diagram on p 112 of ptc/2012-06-04>> After subsection "Strength" in the section Evidence Attributes Class Diagram add the
    following subsection describing the new element:
    "
    ExtendedEvidenceAttribute
    ExtendedEvidenceAttribute element represents a user-defined characteristic of the
    evidence relations that is asserted during the course of evaluation.
    Superclass
    EvidenceAttribute
    Constraints
    • ExtendedEvidenceAttribute element shall own at least one TaggedValue
    describing the meaning of the element.
    Semantics
    ExtendedEvidenceAttribute is a user-defined characteristic. Its meaning is represented by
    the key-value pair of the corresponding TaggedValue element.
    ExtendedEvidenceAttribute characteristic can not be verbalized using the standard
    vocabulary of the Structured Assurance Case Metamodel. However, the key and value
    pair may be carefully named to result in meaningful verbalizations for the targeted
    community in the selected language. In diagram "DocumentAttributes" add concrete class "ExtendedDocumentAttribute" and
    make it a subclass of the abstract class DocumentAttribute.
    In section Document Attributes Class Diagram replace Figure DocumentAttributes Class
    Diagram with the following: << diagram on p 113 of ptc/2012-06-04>> After subsection "ReliabilityLevel (enumeration)" in the section Document Attributes
    Class Diagram add the following subsection describing the new element:
    "
    ExtendedDocumentAttribute
    ExtendedDocumentAttribute element represents a user-defined characteristic of a
    document that is asserted during the course of evaluation.
    Superclass
    DocumentAttribute
    Constraints
    • ExtendedDocumentAttribute element shall own at least one TaggedValue
    describing the meaning of the element.
    Semantics
    ExtendedDocumentAttribute is a user-defined characteristic. Its meaning is represented
    by the key-value pair of the corresponding TaggedValue element.
    ExtendedDocumentAttribute characteristic can not be verbalized using the standard
    vocabulary of the Structured Assurance Case Metamodel. However, the key and value
    pair may be carefully named to result in meaningful verbalizations for the targeted
    community in the selected language.
    "

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

Need a revised compliance point approach

  • Key: SACM-154
  • Legacy Issue Number: 16857
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Need a revised compliance point approach. Suggestion is that there is a compliance point
    such that existing tool vendors can claim compliance. Perhaps other complicance points. This
    would be of interest to OMG/ISO.

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    replace the entire section 2. Conformance with the following:
    2. Conformance
    Structured Assurance Case Metamodel (SACM) specification defines the following 3 compliance points:
    Argumentation
    Evidence Container
    Assurance Case
    2.1. Argumentation compliance point
    Software that conforms to the SACM specification at the Argumentation compliance point shall be able to
    import and export XMI documents that conform with the SACM XML Schema produced by applying XMI
    rules to the normative MOF metamodel defined in the Argumentation subpackage of the SACM
    specification, including the common elements defined in the Common and Predefined diagrams of the
    SACM. The top object of the Argumentation package as a unit of interchange shall be the
    Argumentation::Argumentation element of the SACM.
    Conformance to the Argumentation compliance point does not entail support for the Evidence subpackage
    of SACM, or the Administration diagram of the SACM. Links to the evidence items in the Argumentation::InformationElement shall be made using the ‘url’ attribute. The ‘evidence’ association
    shall not be used.
    This compliance point facilitates interchange of the structured argumentation documents produced by
    existing tools supporting The Goal Structuring Notation (GSN) and Claims-Arguments-Evidence (CAE)
    notation. Examples of the SACM XML interchange documents and the corresponding GSN and CAE
    diagrams are provided in Annex B.
    2.2. Evidence Container compliance point
    Software that conforms to the specification at the Evidence Container compliance point shall be able to
    import and export XMI documents that conform with the SACM XML Schema produced by applying XMI
    rules to the normative MOF metamodel defined in this Evidence subpackage of the SACM specification,
    including the common elements defined in the Common and Predefined diagrams of the SACM. The top
    object of the Evidence package as a unit of interchange shall be the Evidence::EvidenceContainer element
    of the SACM.
    Conformance to the Evidence compliance point does not entail support for the Argumentation subpackage
    of SACM, or the Administration diagram of the SACM. Claims in the Evidence::ReferencedClaim element
    shall be explicitly defined using the ‘content’ attribute of the Evidence::ReferencedClaim element. The
    ‘claim’ association shall not be used.
    This compliance point facilitates interchange of the precise statements related to evidence. In particular,
    this compliance point facilitates development of evidence repositories in support of software assurance and
    regulatory compliance.
    2.3. Assurance Case compliance point
    Software that conforms to the specification at the Assurance Case compliance point shall be able to import
    and export XMI documents that conform with the SACM XML Schema produced by applying XMI rules
    to the normative MOF metamodel defined in this entire specification. The top object of the Assurance Case
    package as a unit of interchange shall be the SACM::AssuranceCase element.

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

exchanged model instances should indicate which compliance points have been satisfied

  • Key: SACM-156
  • Legacy Issue Number: 16859
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    exchanged model instances should indicate which compliance points have been satisfied

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is achieved by observing the top element. See related resolution 16855.
    Disposition: Closed, no change

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

The detailed enumerated attributes in SAEM need a corresponding location in SACM

  • Key: SACM-155
  • Legacy Issue Number: 16858
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    The detailed enumerated attributes in SAEM need a corresponding location in SACM.
    Choosing to use these could be defined using a seperate compliance point.

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The SACM Evidence Metamodel provides a comprehensive vocabulary for constructing and interchanging
    precise statements related to evidence. Detailed enumeration attributes contribute to the precision of the
    interchange. Without them semantic interoperability and reasonable automation processing of the
    interchanged content is hard to achieve. Related resolutions are 16845, 16737 and 16857.

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

If AssertedRelationships are genuinely Assertions then they should be subtypes of Assertion

  • Key: SACM-149
  • Legacy Issue Number: 16848
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    If AssertedRelationships are genuinely Assertions then they should be subtypes of Assertion

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

    Related issue: 16852 (id=145)
    The agreed resolution is that asserted relationships to be moved to be a sub class of
    assertion, and to remove abstract class “ArgumentLink”. Update the text to reflect that
    the “toBeSupported” attribute attaches to the Claim class (as shown in the diagram).
    This issue is resolved as part of the accumulated model changes addressed by 17347.
    Disposition: Merged

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

No AssuranceCase Element in either ARM or SAEM - necessary for a Structured Assurance Case Metamodel

  • Key: SACM-148
  • Legacy Issue Number: 16847
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    No AssuranceCase Element in either ARM or SAEM - necessary for a Structured Assurance Case Metamodel

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

    This issue has been resolved due to resolutions of related issues 16855.
    Disposition: Merged

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

Metamodel packaging should broadly align with ARM/SAEM elements

  • Key: SACM-153
  • Legacy Issue Number: 16856
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Metamodel packaging should broadly align with ARM/SAEM elements. Will support
    understandability

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The discussion details are as follows:
    Modularity of the specification itself provides this modularity
    The corresponding resolutions are provided in resolutions to issue 16836.
    Disposition: Merged

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

Combined specification should have routes and guidance broadly corresponding to ARM and SAEM

  • Key: SACM-157
  • Legacy Issue Number: 16860
  • Status: closed  
  • Source: AIST ( Kenji Taguchi)
  • Summary:

    Combined specification should have routes and guidance broadly corresponding
    to ARM and SAEM, and supports ease of adoption for ARM.

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This resolution has been merged with 16857.
    Disposition: Merged

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

counter evidence and challenge should be better modelled by a polarity attribute on the relation (AB comment)

  • Key: SACM-150
  • Legacy Issue Number: 16851
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    counter evidence and challenge should be better modelled by a polarity attribute on the relation (AB comment)

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

    No Data Available

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

Argument metamodel needs improvement

  • Key: SACM-167
  • Legacy Issue Number: 17347
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    The argument metamodel has some limitations that should be addressed to
    make it more coherent and simple. The following aspects need to be
    addressed:

    1. The annotation class is generally useful and should be promoted up
    the class diagram so it can be used more widely

    2. AssertedRelationships seem to be kinds of assertions (see related
    issue 16848) and so a number of related modelling updates will be needed
    to reorganise the model to reflect this, and to simplify by removing or
    renaming some of the abstract classes. An abstract Assertion class could
    be a useful common parent for both Claim and AssertedRelationship
    Classes. A simplification can be made then to rename the existing
    ArgumentLink as AssertedRelationship.

    3. We should have a simple referencing mechanism to allow referencing
    evidence in the evidence metamodel, or to reference other evidence by
    means of a URL directly (for when the user is only choosing to comply
    with the Argument compliance point)

    4. As the models are integrated it will be necessary to rename the top
    level element in ARM to be less generic

    I propose the following changes:

    Create a new Assertion class, as a subclass of ReasoningElement

    Set the Claim class to be a subclass of Assertion

    Rename the ArgumentLink abstract to be AssertedRelationship (removing
    the previous abstract class AssertedRelationship) and move the new
    AssertedRelationship class to be a child of the Assertion class

    Move the Annotation Class to a shared top level ModelElement, and
    include a content:String attribute

    Add an optional association from InformationElement to
    Evidence::EvidenceItem and add an attribute URL to InformationElement to
    be used to refer to evidence not held in the evidence model.

    Rename the ModelElement to be ArgumentationElement, and move the
    id:String attribute to its new parent ModelElement, which is part of the
    shared classes for the argumentation and evidence parts of SACM.

  • Reported: SACM 1.0b1 — Tue, 1 May 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Rename 9.2.1 to “ArgumentationElement class (Abstract)”
    Delete paragraph 1 of 9.2.1 and replace with:
    “An ArgumentationElement is the top level element of the hierarchy for argumentation
    elements”
    In the Attributes section:
    delete the “identifier: String” attribute
    delete the text under “description: String”, and replace with “A description of the
    Argumentation entity”
    delete the text under “content: String”, and replace with “Supporting content for the
    Argumentation entity”
    delete the “Associations” heading and its content
    change the text of the “Semantics” section to be “The ArgumentationElement is a
    common class for all elements within a structured argument”
    delete the Invariants section
    Delete all of section 9.2.18 (Annotates Class)
    Delete all of Section 9.2.5 (ArgumentLink Class (Abstract))
    Insert a new Section 9.2.5 as follows:
    “Assertion Class (Abstract)
    Assertions are used to record the propositions of Argumentation (including both the
    Claims about the subject of the argument and structure of the Argumentation being
    asserted). Propositions can be true or false, but cannot be true and false simultaneously.
    Superclass
    ReasoningElement
    Semantics
    Structured arguments are declared by stating claims, citing evidence and contextual
    information, and asserting how these elements relate to each other.

    Edit section 9.2.6 ReasoningElement Class (Abstract) as follows: First sentence, change “namely Claims and ArgumentReasoning” to “Assertions and
    ArgumentReasoning”
    Delete Attributes section and its content.
    Delete the content of the “semantics” section, and replace with “The core of any
    argument is the reasoning that exists to connect assertions of that argument. Reasoning is
    captured in SACM through the linking of fundamental claims and the description of the
    relationships between the claims. ReasoningElements represent these two elements.”
    Edit section 9.2.7 InformationElement Class as follows:
    Add an “attributes” section with the following content:
    url : string
    An attribute recording a URL to external evidence
    Add a new sentence at the end of the Semantics section as follows:
    “The url attribute is only to be used when only the argumentation aspects of SACM are
    complied with. If compliance is claimed against both the argumentation and evidence
    packages, then an association to Evidence::EvidenceItem shall be used to reference
    evidence by means of a URL”
    Add an "associations:" section with the following content:
    evidence:Evidence::EvidenceItem[0..*]
    The EvidenceItems referenced by the current InformationElement object.
    Edit Section 9.2.9 Claim Class as follows
    Superclass section > Delete “ReasoningElement”, insert “Assertion” Attributes section>
    add “toBeSupported: Boolean An attribute recording whether further reasoning has yet to
    be provided to support the Claim (e.g. further evidence to be cited).”
    Semantics section, first para -> Delete first sentence (begins “Structured arguments are
    declared…”)
    Semantics section, 2nd para-> delete “reasoning (in the recorded Argument)”, insert
    “argumentation”
    Semantics section: add 3rd para: “A Claim that is intentionally declared as requiring
    further evidence or argumentation can be denoted by setting toBeSupported to be true. “
    Add new “Invariant” Section with the content “Self.assumed and self.toBeSupported
    cannot both be true simultaneously”
    Edit 9.2.12 AssertedRelationship Class (Abstract) as follows
    Superclass section -> delete “ArgumentLink”, insert “Assertion”
    Insert new “Associations” section after “Superclass” section, with the following content:
    Associations
    source:ArgumentElement[0..*] Reference to the ArgumentElement(s) that are the
    source (start-point) of the relationship.
    target:ArgumentElement[0..*] Reference to the ArgumentElement(s) that are the
    target (end-point) of the relationship.
    Semantics section, delete first sentence, replace with “In SACM, the structure of an
    argument is declared through the linking together of primitive ArgumentElements.”
    Edit section 9.2.13 AssertedInferenceClass as follows:
    Delete first para, replace with “The AssertedInference association class records the
    inference that a user declares to exist between one or more Assertion (premises) and another Assertion (conclusion). An assertion may be the target in more than one
    AssertedInference. It is important to note that such a declaration is itself an assertion on
    behalf of the user.”
    Semantics section, delete existing content, replace with “The core structure of an
    argument is declared through the inferences that are asserted to exist between Assertions
    (e.g. Claims). For example, an AssertedInference can be said to exist between two claims
    (“Claim A implies Claim B”). An AssertedInference between two claims (A – the source
    – and B – the target) denotes that the truth of Claim A is said to infer the truth of Claim
    B.”
    Change title of 9.1 from 'Overview' into 'Argumentation Class Diagram'
    Replace Figure 9.1 with the following new figure <<figure on p 125 of ptc/2012-06-04>>

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

Evidence Metamodel needs a Record element

  • Key: SACM-166
  • Legacy Issue Number: 17316
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Currently the Evidence metamodel has a general class Exhibit, and one concrete class Document. However the feedback from Regulatory Compliance community is that there should be an explicit element to represent electronic records of compliance.
    Suggested resolution is to add Record element as a concrete subclass of Exhibit. Resolutions in Ballot 5 are addressing the issue of moving the DocumentProperties up the inheritance chain so that these Properties are available for Records.
    This is a minor semantic enhancement that will allow better differentiation between various exhibits, and will allow management of electronic records for compliance.

  • Reported: SACM 1.0b1 — Thu, 19 Apr 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Add section Record to chapter 10 as follows:
    Record
    Record element represents Exhibits that are explicit records of compliance, for example
    log entries. Record is different from a Document, since a Document element represents
    some physical object that exists elsewhere in the physical world (even if it is an
    electronic document), while a Record element exists directly in the EvidenceContainer.
    Superclass
    EvidenceElement
    Attributes
    name:String the name of the record
    content:String the content of the record
    Semantics
    Record is defined as "a thing constituting a piece of evidence about the past, esp. an
    account of an act or occurrence kept in writing or some other permanent form". In the
    Evidence Metamodel Record element is such thing. In contrast to a Document element, a
    Record is not a representative of some other physical object, but the object itself. A
    Record is therefore similar to an Object, however it is considered a structured element
    with an informal content rather than a formal element.
    Changes to Figure EvidenceElements (Figure 10.1) were illustrated in related resolutions
    (e.g. 16800) and is presented below. <<diagram on p 121 of ptc/2012-06-04>>

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

Need to provide motivation (the underlying issue) for new “link group”

  • Key: SACM-162
  • Legacy Issue Number: 16868
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Need to provide motivation (the underlying issue) for new “link group”. Question of why
    not just use annotation/tagging to convey alternatives. We should make architectural changes
    unless strong warrant to do so.

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This issue is related to a now obsolete intermediate model of ARM and is not longer
    applicable.
    Disposition: Closed, no change

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

Question of how to characterize the identity of the “artifact-as-such”, as well as its URN

  • Key: SACM-161
  • Legacy Issue Number: 16867
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    Question of how to characterize the identity of the “artifact-as-such”, as well as
    its URN. May need a “name” attribute for the “source” class (Issue raised). Perhaps defer or
    explain usage in the document?

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This issue is a duplicate of 16515; a resolution is provided by 17347. SACM uses a URL in both the
    Argumentation Metamodel as well as in the Evidence Metamodel. Evidence Metamodel also includes a
    name. Annotations can be used to provide further clarifications. There is also a gid+id mechanism, so each
    organization can use a unique reference schema for their exhibits and artifacts.
    Disposition: Closed, no change

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

Wrong figure in Evidence Evaluation example

  • Key: SACM-165
  • Legacy Issue Number: 17309
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    he subsection Evidence Evaluation Example in chapter 6 Overview includes a Figure; the Beta-1 document has a wrong figure. Correct figure from the adopted specification must be used.

  • Reported: SACM 1.0b1 — Fri, 13 Apr 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Replace Figure in section 7.5.1 with the following:
    Change text on page 11 from 'Genealogical Proof Standard' into 'Resolved Counter
    Evidence (RCE), often used in the field of Genealogy as the Genealogical Proof
    Standard'.
    Change text on page 11 from 'the so-called Genealogical Proof Standard" into "the socalled
    Resolved Counter Evidence Proof Standard"

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

Needed assurance case compliance point

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

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

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

    This resolution has been merged with 16857.
    Disposition: Merged

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

Need to clarify usage of “nature of dependency” to indicate this is not for evidential or argumentation relations

  • Key: SACM-160
  • Legacy Issue Number: 16866
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Need to clarify usage of “nature of dependency” to indicate this is not for evidential or argumentation relations

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This issue is to some extent a duplicate of 16512. However, the updated Argumentation Metamodel does
    not have nature of dependency attribute any more. Some clarifications were added to the Evidence
    Metamodel as resolution to 16512. No further changes are required.
    Disposition: Closed, no change

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

motivate link groups

  • Key: SACM-159
  • Legacy Issue Number: 16865
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    (a missing issue) to motivate link groups

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This issue has been raised against an intermediate version of the Argumentation Metamodel; the element in
    question has been since removed and is not part of the final version.
    Disposition: Closed, no change

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

ArgumentReasoning should also attach to AssertedChallange

  • Key: SACM-168
  • Legacy Issue Number: 17354
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    This issue was raised by Sam Redwine on April 16th 2012 in a message to Luke and Nick

    Argumentation metamodel:
    ArgumentReasoning should also attach to AssertedChallange

  • Reported: SACM 1.0b1 — Sat, 5 May 2012 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    In ArgumentReasoning class (previously 9.2.11), delete the first paragraph and replace with the following:
    “ArgumentReasoning can be used to provide additional description or explanation of the asserted inference
    or challenge that connect one or more Claims (premises) to another Claim (conclusion).
    ArgumentReasoning elements are therefore related to AssertedInferences and AssertedChallenges. It is also
    possible that ArgumentReasoning elements can refer to other structured Arguments as a means of
    documenting the detail of the argument that establishes the asserted inferences. “
    In the Associations subsection, add the following:
    describedChallenge:AssertedChallenge[0..*]
    Reference to the AssertedChallenge being described by the ArgumentReasoning.
    Replace figure 9.1 with the following << figure on p 127 of ptc/2012-06-04>>

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

The frontispiece sections (introduction, background, scope etc) needs to be edited to reflect integration

  • Key: SACM-158
  • Legacy Issue Number: 16862
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    The frontispiece sections (introduction, background, scope etc) needs to be edited to
    reflect integration. Suggest to break an issue for each sections.

  • Reported: SACM 1.0b1 — Thu, 1 Dec 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Page 2-3 remove text starting from section 1.3 Why Software Assurance Evidence ? and ending with
    phrase "demonstrated through the development of assurance cases".

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

Name AssertedEvidence

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

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

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

    Rejected - keep as ARM
    Disposition: Closed, no change

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

Integration Issue: Combined scope needs to include original scopes, and any emergent scope

  • Key: SACM-144
  • Legacy Issue Number: 16839
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration Issue: Combined scope needs to include original scopes, and any emergent scope

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

    The summary of this issue does not give any further details, so the intention of the issue remains rather
    vague. Additional details are provided as follows:
    part 1 deals with the minimal new issues of assurance case containment part 2 is same
    scope as ARM part 3 is same scope as SAEM.
    The corresponding resolutions will be provided in resolutions to the issue 16836.
    Disposition: Merged

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

Integration issue: An overall goal is to integrate the ARM and SAEM specifications into SACM in a coherent way.

  • Key: SACM-143
  • Legacy Issue Number: 16836
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Integration issue: An overall goal is to integrate the ARM and SAEM specifications into SACM in a coherent way.

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

    Add new section Common Elements Class Diagram to chapter 8 SACM Assurance Case
    Add Common Elements diagram as follows: <<diagram on p 106 of ptc/2012-06-04 >> Add SACMElement section
    SACMElement
    A SACM element is a top-level element for the Structure Assurance Case Metamodel.
    This is an abstract class that directly extends MOF::Element. Every class in SACM is a
    (direct or indirect) subclass of SACMElement.
    Superclass
    MOF::Element
    Semantics
    The SACMElement is a common class for all meta-model elements that represent some
    element of a structured assurance case.
    Remove ModelElement section 9.2.1, page 23
    Add ModelElement section to chapter 8 in the following way:
    ModelElement Class (Abstract)
    A ModelElement is an atomic constituent of a structured assurance case represented
    using the Structured Assurance Case Metamodel. In the meta-model, ModelElement is the top meta-element in the SACM Common class hierarchy. ModelElement is an
    abstract meta-model element.
    Attributes
    • id: String A unique identifier for the SACM entity.
    Associations
    taggedValue:TaggedValue[0..*] This association enables the association of one or more
    user defined TaggedValues to any ModelElement.
    annotation:Annotation[0..*] user defined annotations associated with the current element
    Semantics
    The ModelElement is a common class for all meta-model elements that represent some
    element of a structured assurance case.
    Invariants
    • context ModelElement inv UniqueIdentifier: ModelElement.allInstances()->
    select(me:ModelElement|me.identifier=self.identifier)->size()= 1
    Add UtilityElement section to chapter 8 in the following way:
    UtilityElement Class (Abstract)
    A UtilityElement is an atomic constituent of a structured assurance case represented
    using the Structured Assurance Case Metamodel. In contrast to a ModelElement,
    UtiiltyElement represents auxiliary constructs that extend ModelElement and that are
    only used as part of some ModelElement. In particular, such UtilityElement cannot be
    referenced outside of the owner ModelElement. UtilityElement is an abstract class.
    Semantics
    The UtilityElement is a common class for all meta-model elements that represent some
    auxiliary element of a structured assurance case.
    Move TaggedValue section 9.2.2, page 24 to chapter 8
    Change superclass of TaggedValue to UtilityElement
    Change sentence in the description of TaggedValue element as follows:
    A TaggedValue is a structured annotation that can be provided on any ModelElement in
    the Structured Assurance Case Metamodel.
    Change sentence in semantics section from:
    This is a deliberately general mechanism to allow users to associate tags that they find
    useful for any Argumentation Metamodel instance.
    into
    This is a deliberately general mechanism to allow users to associate tags that they find
    useful for any Structure Assurance Case Metamodel object.
    Add Annotation section to chapter 8.
    "
    Annotation
    An Annotation element represents informal and unstructured user-defined content to any
    ModelElement of the Structure Assurance Case Metamodel. In contrast, a TaggedValue
    element allows more structured content to be added to elements.
    Superclass UtilityElement
    Attributes
    content:String the text of the annotation
    Semantics
    It can be useful to be able to add informal text to the ModelElements. For example,
    Annotation elements can record comments, notes and general explanations. This is a
    deliberately general mechanism to allow users to associate annotations that they find
    useful for any Structure Assurance Case Metamodel object.
    "
    Modifications to the Argumentation Metamodel and the Evidence Metamodel parts are
    described in related resolutions. In particular, we are adding a reference from
    Argumentation::InformationElement to Evidence::EvidenceItem and from
    Evidence::ReferencedClaim to Argumentation::Claim

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

Incorporate 12.5.1 EvidenceRequest (p82) in a coherent way into merged SACM metamodel

  • Key: SACM-142
  • Legacy Issue Number: 16834
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.5.1 EvidenceRequest (p82) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other changes to this element are anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 12.4.4 HasRoleIn (p81) in a coherent way into merged SACM metamodel

  • Key: SACM-141
  • Legacy Issue Number: 16833
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.4.4 HasRoleIn (p81) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The superclass of this element is changed to ProjectProperty due to renaming from AdministrativeProperty
    (see resolution 16818). Otherwise, this is a useful leaf class representing a statement related to managing
    and evaluating evidence in evidence collection projects. No change is required.
    Disposition: Closed, no change

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

Incorporate 12.3.2 Service (p79) in a coherent way into merged SACM metamodel

  • Key: SACM-135
  • Legacy Issue Number: 16827
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.3.2 Service (p79) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass.
    No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 12.3.1 CollectionMethod (abstract) (p78) in a coherent way into merged SACM metamodel

  • Key: SACM-134
  • Legacy Issue Number: 16826
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.3.1 CollectionMethod (abstract) (p78) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass.
    No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 12.4.1 Originator (abstract) (p80) in a coherent way into merged SACM metamodel

  • Key: SACM-138
  • Legacy Issue Number: 16830
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.4.1 Originator (abstract) (p80) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    No Data Available

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

Incorporate 12.3.4 Tool (p79) in a coherent way into merged SACM metamodel

  • Key: SACM-137
  • Legacy Issue Number: 16829
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.3.4 Tool (p79) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass.
    No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 12.2.6 DependsOn (p77) in a coherent way into merged SACM metamodel

  • Key: SACM-133
  • Legacy Issue Number: 16825
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.2.6 DependsOn (p77) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to the administrative elements that
    describe evidence collection and evidence evaluation projects. Any connection to the SACM common
    classes is accomplished through the element's superclass. No other changes to this element are anticipated
    according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 12.4.3 Organization (p81) in a coherent way into merged SACM metamodel

  • Key: SACM-140
  • Legacy Issue Number: 16832
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.4.3 Organization (p81) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 12.4.2 Person (p80) in a coherent way into merged SACM metamodel

  • Key: SACM-139
  • Legacy Issue Number: 16831
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.4.2 Person (p80) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass.
    No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 12.3.3 Method (p79) in a coherent way into merged SACM metamodel

  • Key: SACM-136
  • Legacy Issue Number: 16828
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.3.3 Method (p79) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass.
    No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 12.1.3 StandardOfProof (enumeration) (p73) in a coherent way into merged SACM metamodel

  • Key: SACM-125
  • Legacy Issue Number: 16817
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.1.3 StandardOfProof (enumeration) (p73) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Section 15.13. StandardOfProof (enumeration) page 93 add and attribute:
    "
    RCE
    Resolved Counter Evidence Proof Standard
    "
    in the Semantics section on page 93 change text "Genealogical Proof Standard (GPS) to
    'Resolved Counter Evidence Proof Standard (RCE)".

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

Incorporate 12.1.2 Package (p72) in a coherent way into merged SACM metamodel

  • Key: SACM-124
  • Legacy Issue Number: 16816
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.1.2 Package (p72) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Change text page 91 from
    Administration package defines key framework elements that determine patterns for
    constructing representations of evidence information.
    into
    This chapter describes the elements of the SACM Evidence Metamodel that are involved
    in managing evidence, exchanging units of evidence and related concerns. The elements
    described in this chapter organize instances on Evidence Metamodel, which can be
    referred to as an Evidence Model. In particular, this chapter defines the root object of
    Evidence Models - the EvidenceContainer. This element contains other objects in an
    evidence project and constitutes a unit of exchange using the Evidence Metamodel as the
    protocol.
    Rename section 15.1.2 Package into 15.1.2. EvidenceContainer
    Change text pages 92-93 from
    Package element is the root element that owns EvidenceItem, EvidenceEvaluation
    elements, as well as other auxiliary elements related to the processes of evidence
    identification, collection, interpretation, evaluation, and management.
    Superclass
    AdministrativeElement
    Attributes • consistency:ConsistencyLevel Globally unique identifier of a SACM evidence
    element.
    • version:String version of the package.
    • criteria:StandardOfProof Standard of Proof used for evaluation of evidence.
    • completeness:CompletenessLevel Level of completeness of the evidence package.
    Association
    • :requiresPackage[0..*] List of other evidence packages that are required by this
    package.
    • item:EvidenceItem[0..*] List of evidence items.
    • evaluation:EvidenceEvaluation[0..*] List of evaluations.
    • method:CollectionMethod[0..*] List of evidence collections methods, including
    tools.
    • originator:Originator[0..*] List of personnel and organizations involves in
    evidence collection project.
    • request:Request[0..*] List of evidence collection requests.
    • activity:Activity[0..*] List of project activities.
    • objective:ProjectObjective[0..*] List of project objectives.
    Constraints
    • Package shall not be the object of the requiresPackage relation owned by the
    Package, either directly or indirectly through requiresPackage of other Packages.
    • Any Package that is the object of the requiresPackage relation shall be available
    for exchange.
    • [Completeness of the package with respect to required packages] Any Element
    that is referenced by any of the Element that defined in the package (i.e., that are
    members of the lists item, evaluation, method, originator, request, activity, and objective
    of the Package) shall be also defined in the Package or in one of the Package that are
    referred to as objects of the requiresPackage relation either directly or indirectly. An
    Element is referenced if it is an object of an EvidenceProperty or an EvidenceEvaluation.
    • EvidenceProperty, EvidenceEvaluation, EvidenceRequest, EvidenceAction,
    ProjectObjective elements shall not be referenced across packages.
    Semantics
    Package element is the root element of an Evidence Model. A single Package is a unit of
    exchange. All Element defined in Package are exchanged together as part of the Package.
    Elements that are referenced shall be either present in the Package or in one of the
    Package that is specified as required for the Package. The Evidence Metamodel does not
    require completeness of the closure of all required packages.
    into
    EvidenceContainer element is the root object of the SACM Evidence Metamodel
    instances. This object owns EvidenceItem, and EvidenceEvaluation elements, as well as
    other ProjectElement related to the processes of evidence identification, collection,
    interpretation, evaluation, and management.
    Superclass
    EvidenceElement
    Attributes
    • name:String name of the EvidenceContainer.
    • gid:String Globally unique identifier of the EvidenceContainer. • version:String version of the EvidenceContainer.
    Association
    • item:EvidenceItem[0..*] List of evidence items.
    • evaluation:EvidenceEvaluation[0..*] List of evaluations.
    • element:ProjectElement[0..*] List project elements (objectives, activities,
    requests, methods, stakeholders).
    • property:ProjectProperty[0..*] List of project property clauses.
    Constraints
    • EvidenceContainer shall not be the object of the requiresContainer relation owned
    by the EvidenceContainer, either directly or indirectly through requiresContainer of other
    EvidenceContainers.
    • Any EvidenceContainer that is the object of the requiresContaienr relation shall
    be available for exchange.
    • [Completeness of the evidence container with respect to required evidence
    containers] Any Element that is referenced by any of the Element defined in the package
    (i.e., that are members of the lists item, evaluation, or element of the EvidenceContainer)
    shall be also defined in the EvidenceContaienr or in one of the EvidenceContainers that
    are referred to as objects of the requiresContaienr relation either directly or indirectly. An
    Element is referenced if it is an object of an EvidenceProperty or an EvidenceEvaluation.
    • EvidenceProperty, EvidenceEvaluation, EvidenceRequest, EvidenceAction,
    ProjectObjective elements shall not be referenced across evidence containers.
    Semantics
    EvidencePackage element is the root object of an instance of the Evidence Metamodel
    (which can be referred to as Evidence Model). A single EvidenceContainer is a unit of
    exchange of evidence information. All Element defined in an EvidenceContainer are
    exchanged together as part of the EvidenceContainer. Elements that are referenced shall
    be either present in the EvidenceContainer or in one of the EvidenceContaienrs that is
    specified as required for the EvidenceContainer. The Evidence Metamodel does not
    require completeness of the closure of all required packages.
    The properties of the EvidenceContainer element make assertions regarding the current
    container (use the current container as the subject of the corresponding clauses).
    Therefore, the following properties for an EvidenceContainer can be readily interpreted
    in the above way:
    RequiresContainer (for example, verbalized as "the EvidenceContainer requires container
    X1")
    ContainerConsistency (for example, verbalized as "the elements of the
    EvidenceContainer are interpreted formally")
    ContainerCompleteness (for example, verbalized as" the EvidenceContainer is in draft
    state")
    CompliesTo (for example, verbalized as "The EvidenceContainer complies to the
    Resolved Counter Evidence proof standard")
    All ProjectProperties clauses directly owned by an EvidenceContainer shall be
    interpreted with the EvidenceContainer as the main subject. For example, "The
    EvidenceContainer depends on evidentiary support rendered by exhibit E1 to the claim
    'testing is completed'"
    Replace Figure 15.1 with the following (see also resolution 16815): <<figure on p 99 of ptc/2012-06-04>> Add section ProjectProperties to chapter 15 (see also resolution 16818).
    Move section 15.1.3 StandardOfProof (enumeration) to the new section
    Move section RequiresPackage to the new section.
    Rename section RequiresPackage into RequiresContainer
    Change section RequiresContainer to the following:
    RequiresContainer is an owned property of EvidenceContainer element. This element
    represents a statement asserting that the subject EvidenceContainer requires another
    evidence container for the resolution of some references.
    Superclass
    ProjectProperty
    Associations

    • container:EvidenceContainer[1]
      EvidenceContainer that is required for the resolutions of soem references in the
      subject evidence contaienr
      Constraints
    • RequiresContainer element shall not be owned by any ProjectElement object
      -subject EvidenceContainer shall no be the 'container' of the requiresContainer
      relation, either directly or indirectly,
      Semantics
      RequiresContainer property represents a state of affairs that the subject
      EvidenceContainer requires another evidence container for the resolution of some
      references. This property contributes to the completeness constraint of the
      EvidenceContainer. This is a commitment to the set of evidence containers that need to
      be processed together. Add section ContainerConsistency as follows:
      ContainerConsistency ContainerConsistency element is a counterpart of the Consistency property of Documents.
      ContainerConsistency clause makes an assertion about the subject EvidenceContainer
      regarding the level of formality of the element of the container. In combination with other
      container properties, such as ContainerCompleteness and CompliesTo, this clause
      determines capability to interpret the elements of this container. Consistency of an
      EvidenceContainer can be informal, semiformal and formal.
      Superclass
      ProjectProperty
      Attributes
      value:ConsistencyLevel
      asserted Consistency level of the elements of the EvidenceContainer, such as informal,
      semi-formal, and formal.
      Add section ContainerCompleteness as follows:
      ContainerCompleteness
      ContainerCompleteness element is a counterpart of the Completeness property of Documents.
      ContainerCompleteness clause makes an assertion about the subject EvidenceContainer
      regarding the level of completeness of the element of the container. In combination with
      other container properties, such as ContainerConsistency and CompliesTo, this clause
      determines capability to interpret the elements of this container. Completeness of an
      EvidenceContainer can be incomplete, draft, final and obsolete.
      Superclass
      ProjectProperty
      Attributes
      value:CompletenessLevel
      asserted Completeness level of the elements of the EvidenceContainer, such as
      incomplete, draft, final and obsolete.
      Add section CompliesTo as follows:
      CompliesTo
      CompliesTo clause makes an assertion about the subject EvidenceContainer regarding the
      standard of proof used for the evaluation of evidence in the EvidenceContainer. In
      combination with other container properties, such as ContainerConsistency and
      ContainerCompleteness, this clause determines capability to interpret the elements of this
      container. Completeness of an EvidenceContainer can be incomplete, draft, final and
      obsolete.
      Attributes
      criteria:StandardOfProof Standard of Proof used for evaluation of evidence in the subject
      container.
      Add section ExtendedProjectProperty as follows:
      ExtendedProjectProperty
      ExtendedProjectProperty element represents a user-defined characteristic documents that
      is asserted during the course of evaluation for the project elements in the subject
      container.
      Superclass ProjectProperty
      Constraints
      • ExtendedProjectProperty element shall own at least one TaggedValue informally
      describing the meaning of the element.
      Semantics
      ExtendedProjectProperty is a user-defined characteristic. Its meaning is represented by
      the key-value pair of the corresponding TaggedValue element.
      ExtendedProjectProperty characteristic can not be verbalized using the standard
      vocabulary of the Structured Assurance Case Metamodel. However, the key and value
      pair may be carefully named to result in meaningful verbalizations for the targeted
      community in the selected language.
      Replace Figure 15.2 ProjectProperties (shows as part of 16818) as follows: <<diagram on p 101 of ptc/2012-06-04>>
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorporate 12.1.1 AdministrativeElement (abstract) (p71) in a coherent way into merged SACM metamodel

  • Key: SACM-123
  • Legacy Issue Number: 16815
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.1.1 AdministrativeElement (abstract) (p71) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Change text 15.1.1 AdministrativeElment (abstract), page 91 into 15.1.1 ProjectElment (abstract)
    Change definition of the AdministrativeElement section 15.1.1, page 91 from
    AdministrativeElement is an abstract class representing non-essential elements of the
    Evidence Metamodel that assist in managing evidence collection, interpretation,
    evaluation, and exchange processes.
    into
    ProjectElement represents the auxiliary elements of the Evidence Metamodel that are
    involved in the statements related to managing evidence collection, interpretation,
    evaluation, and exchange processes.
    Change superclass of AdministrativeElement to 'EvidenceElement' (page 91)
    Remove text from Attributes of the AdministrativeElement on page 91:
    id:String Globally unique identifier of a SACM evidence element.
    Add text to Attributes of the AdministrativeElement on page 91:
    name:String Name of the ProjectElment.
    content:String The statement in a selected language that is the description of the content
    of the element
    Add Associations subsection of the AdministrativeElement on page 91:
    Associations
    property:ProjectProperty[0..*] properties of the Project Element - zero or more
    predicates to the main clause in which the current element is the subject)
    Add to semantics of the ProjectElement the following:
    The properties of a ProjectElement make assertions regarding the current element (use
    the current element as the subject of the corresponding clauses). Therefore, the following
    properties for a ProjectElement can be readily interpreted in the above way:
    DependsOn when a subject element is an Activity (for example, verbalized as " Activity
    A2 depends on Activity A1")
    HasRoleIn when the subject element is a Stakeholder (for example, verbalized as " Bob is
    the president of the organization SupplierCorporation")
    Satisfies when a subject element is an Activity (for example, verbalized as" Activity A2
    satisfies project objective Perform Search")
    All ProjectProperties clauses directly owned by a ProjectElement shall be interpreted
    with the ProjectElement as the main subject. For example, "Person Researcher depends
    on activity Perform Search and satisfies project objective Find evidence"
    Add class ProjectElement to Figure 10.1 EvidenceElements
    Replace Figure 10.1 with the following (this also contains resolution to several related
    issues ). <<diagrams on p 94 of ptc/2012-06-04>> Rename 15.2 ProjectActivities Class Diagram into
    15.2 ProjectElements Class Diagram
    Change text on page 94 from
    ProjectActivities Class Diagram defines Activity AdministrativeElement and its owned
    properties. Activity element facilitates management of evidence collection and evaluation
    processes.
    into
    ProjectElements Class Diagram defines several auxiliary elements that are used in
    various statements as predicate clauses for some main clause in which the subject is some
    evidence element. The elements defined at this class diagram are collectively referred to
    as the project elements. They are required to express various evidence statements related
    to evidence collection, evaluation and evidence management.
    Move sections 15.3.1. CollectionMethod (abstract), 15.3.2 Service, 15.3.3 Method, 15.3.4
    Tool into the section 15.2 ProjectElements Class Diagram.
    Move sections 15.4.1. Originator (asbtract), 15.4.2. Person, 15.4.3 Organization into the
    section 15.2 ProjectElements Class Diagram.
    Move section 15.5.1. EvidenceRequest into the section 15.2 ProjectElements Class
    Diagram.
    change superclass of EvidenceRequest to ProjectElement
    remove association 'provenance' of EvidenceRequest.
    Create class diagram ProjectElements based on Figure 15.2 and former ProjectActivities
    diagram.
    Change superclass of CollectionMethod (section 15.3.1 page 98) to ProjectElement
    Change superclass of Originator (section 15.4.1 page 100) to ProjectElement Remove section 15.3 Methods (see also related resolution 16818)
    Remove section 15.4 Originators (see also related resolution 16818)
    Remove section 15.5 Request class diagram.

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

Incorporate 11.7.1 EvidenceGroup (p69) in a coherent way into merged SACM metamodel

  • Key: SACM-122
  • Legacy Issue Number: 16814
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.7.1 EvidenceGroup (p69) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Item related to management of evidence items as well as
    representing subjects of evidence assertions involved in the evaluations of evidence items and the
    justification support they provide. Any connection to the SACM common classes is accomplished through
    the element's superclass. No other changes to this element are anticipated according to the selected level of
    the integration.
    Disposition: Closed, no change

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

Incorporate 12.1.4 AdministrativeProperty (abstract) (p74) in a coherent way into merged SACM metamodel

  • Key: SACM-126
  • Legacy Issue Number: 16818
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.1.4 AdministrativeProperty (abstract) (p74) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Rename section 15.1.4 AdministrativeProperty (abstract) into ProjectProperty (abstract) (page 92)
    Change definition of AdministrativeProperty from
    AdminstrativeProperty is an abstract class that represents owned properties of
    AdminstrativeElement. This class is added to enhance the readability of the model.
    into
    ProjectProperty represents statements related to the structure of ProjectElement. These
    statements are predicate clauses where the main clause describes some project element.
    The subject of the ProjectProperty clause is a ProjectElement.
    Rename superclass of ProjectProperty to EvidenceProperty
    Add class ProjectProperty to EvidenceAssertions class diagram
    Change semantics from
    Defined by concrete subsclasses
    into
    Defined by concrete subclasses
    Add section ProjectProperties Class Diagram
    move section 15.1.4 ProjectProperty (abstract) to the new section
    Add Figure ProjectProperties Class Diagram <<diagram on p 103 of ptc/2012-06-04>> Move section 15.4.4 HasRoleIn to the new section
    change superclass of HasRoleIn from EvidenceProperty to ProjectProperty
    add Constraints section as follow:

    • ProjectElement shall not be affiliated with self, either directly or indirectly
      Remove class RequiresTool (the corresponding section is missing in the document, so it
      does not need to be removed)
      Move section 15.2.6. DependsOn to the new section change superclass of the DependsOn to ProjectProperty (page 97)
      Change text on page 97 from
      DependsOn element represents a relationship between the owner Activity element and
      another Activity element that is identified as the activity attribute of the DependsOn
      element.
      into
      DependsOn element represents a relationship between the owner project element and
      another project element that is identified as the element attribute of the DependsOn
      element. DependsOn element is a clause where the main subject is the ProjectElement
      that owns the current element. For example, this clause can be used to specify
      dependencies between Activities in an evidence collection project.
      Change associations from
      activity:Activity[1] Activity that the current activity depends on.
      into
      element:ProjectElement[1] Project element that the subject element depends on.
      Change semantics section from
      DependsOn element represents a state of affairs that the owner Activity is associated with
      another Activity identified as the activity attribute of the DependsOn element.
      into
      DependsOn element represents a state of affairs that the subject project element depends
      on another project element identified as the 'element' attribute of the DependsOn
      element.
      In Constraints subsection, change text 'Activity' into "ProjectElement'.
      Remove class isAssociatedWith and the corresponding section 15.2.5, page 97
      Remove class RequiresMethod and the corresponding section 15.2.4 page 97
      Move section 15.2.3. Satisfies, page 96 to the new section
      Change the superclass of the Satisfies element to ProjectProperty
      Change the associations from
      objective:ProjectObjective[1] Project objective that is satisfied by the activity.
      into
      element:ProjectElement[1] Project element that is satisfied by the current element.
      Change text from
      Satisfies element represents a relationship between the owner Activity element and a
      ProjectObjective object that is identified as the objective attribute of the Satisfies
      element.
      into
      Satisfies element represents a relationship between the owner project element and another
      project element that is identified as the element attribute of the Satisfies element. The
      Satisfies element is a clause where the main subject is the ProjectElement that owns the
      current element. For example, this clause can be used to specify that a certain Activity
      satisfies a certain ProjectObjective in an evidence collection project.
      Change associations of Satisfies into
      element:ProjectElement[1] Project element (such as a ProjectObjective) that is satisfied
      by the subject project element
      Change the semantics subsection from Satisfies element represents a state of affairs that the owner Activity object satisfies the
      ProjectObjective identified as the objective attribute of the ProjectObjective element.
      into
      Satisfies element represents a state of affairs that the owner project element satisfies
      another ProjectElement (such as a ProjectObjective) identified as the 'element' attribute of
      the Satisfies element.
      Other changes to the ProjectProperties Class Diagram are described in the related
      resolution 16816 (EvidenceContainer)
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorporate 11.6.2 Negates (p67) in a coherent way into merged SACM metamodel

  • Key: SACM-119
  • Legacy Issue Number: 16811
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.6.2 Negates (p67) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.6.1 EvidenceResolution (abstract) (p66) in a coherent way into merged SACM metamodel

  • Key: SACM-118
  • Legacy Issue Number: 16810
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.6.1 EvidenceResolution (abstract) (p66) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Change text at in the section 14.6.1 page 86 from
    EvidenceResolution is an abstract class that asserts resolution to conflicts between two
    domain assertions either directly or through refuting some domain assertion or negating
    some evidence relations.
    into
    EvidenceResolution represent statements that assert resolution to the conflict between
    two evidence assertions either directly or indirectly by refuting some evidence assertion
    or negating some evidence relation.
    Remove EvidenceContext class from EvidenceResolutions class diagram Figure 14.6
    Add EvidenceElement class to EvidenceResolutions class Diagram Figure 14.6; add an association from
    EvidenceResolution class to EvidenceElement class with rolename of EvidenceItem named 'subject' and
    multiplicity of 1.
    Remove Rationale class from EvidenceResolutions class diagram Figure 14.6
    Change associations of EvidenceResolution from
    context:EvidenceGroup[0..1] The set of evidence element that provides the context for
    the resolution.
    rationale:Rationale[1] The rationale for the resolution (prose).
    into
    subject:EvidenceElement[1] The subject evidence element for the resolution, i.e. the
    evidence element that negates, resolves or refutes other evidence elements
    Replace Figure 14.6 with the following: << diagram on p 92 of ptc/2012-06-04

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

Incorporate 11.6.4 Resolves (p68) in a coherent way into merged SACM metamodel

  • Key: SACM-121
  • Legacy Issue Number: 16813
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.6.4 Resolves (p68) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.6.3 Refutes (p67) in a coherent way into merged SACM metamodel

  • Key: SACM-120
  • Legacy Issue Number: 16812
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.6.3 Refutes (p67) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 12.2.2 ActivityProperty (abstract) (p76) in a coherent way into merged SACM metamodel

  • Key: SACM-129
  • Legacy Issue Number: 16821
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.2.2 ActivityProperty (abstract) (p76) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is an abstract class representing Evidence Assertions related to project Activity elements. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    changes to this element are anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 12.2.1 Activity (p75) in a coherent way into merged SACM metamodel

  • Key: SACM-128
  • Legacy Issue Number: 16820
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.2.1 Activity (p75) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Administrative Element in support of a collection of evidence
    items. Any connection to the SACM common classes is accomplished through the element's superclass.
    No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 12.1.5 RequiresPackage (p74) in a coherent way into merged SACM metamodel

  • Key: SACM-127
  • Legacy Issue Number: 16819
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.1.5 RequiresPackage (p74) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence container.
    In particular, this assertion allows to specify dependencies between evidence containers. Any connection to
    the SACM common classes is accomplished through the element's superclass. No other changes to this
    element are anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 12.2.3 Satisfies (p76) in a coherent way into merged SACM metamodel

  • Key: SACM-130
  • Legacy Issue Number: 16822
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.2.3 Satisfies (p76) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the administrative
    elements that describe evidence collection and evidence evaluation projects. Any connection to the SACM
    common classes is accomplished through the element's superclass. No other changes to this element are
    anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.5.5 Amplifies (p65) in a coherent way into merged SACM metamodel

  • Key: SACM-117
  • Legacy Issue Number: 16809
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.5.5 Amplifies (p65) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 9.2.1 FormalObject (abstract) (p33) in a coherent way into merged SACM metamodel

  • Key: SACM-63
  • Legacy Issue Number: 16752
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 9.2.1 FormalObject (abstract) (p33) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Delete entire section 12.2.1 FormalObject (abstract)
    Remove class FormalObject from Figure 12.2; rename class DomainObject to FormalObject (see resolution
    16734); change superclass of Object to FormalObject (see resolution 16753); change superclass of
    UnknownSubject to FormalObject (see resolution 16754).
    Add element ObjectifiedAssertion (after section 12.2.2 Object)
    ObjectifiedAssertion represents an objectified assertion, i.e. an assertion that implicitly
    defines an object that is used in another assertion.
    Superclass
    FormalObject
    Associations
    assertion:FormalAssertion Link to the FormalAssertion being objectified
    Semantics
    From the formal logic perspective, SACM distinguishes objects from assertions. As a
    consequence, in order to represent a formal assertion about other assertions the later must
    be objectified, i.e. represented as a FormalObject that refers to the objectification of the
    original assertion using the element ObjectifiedAssertion.
    At Figure 14.4 change class Object into FormalElement
    Change description of 'IsA' statement on page 81 into
    IsA statement represents a fundamental relation between one EvidenceElement and one
    FormalElement which defines the general concept for the subject EvidenceElement. The
    actual concept can be given by reference to an external formal vocabulary or ontology.
    The following statements are examples of IsA statements:
    • “This metric is a McCabe’s Cyclomatic Complexity Metric.”
    • “This report is a penetration testing report.”
    Superclass EvidenceInterpretation
    Associations
    • definition:FormalElement[1] The FormalElement that is the general concept of
    the subject of the relation.
    Constraints
    • The subject of the IsA relation shall not be its definition.
    Semantics
    The IsA element asserts a state of affairs that the EvidenceElement, identified as the
    subject element of the IsScopedBy element, has a general concept represented by the
    FormalElement that is identified as the definition of the IsA element. The FormalElement
    can be either a FormalObject or a FormalAssertion.
    This characteristic is verbalized as follows: “EvidenceElement is a FormalElement.”
    Change description of IsScopedBy (pages 82-83) into:
    IsScopedBy statement represents a relation between one EvidenceElement and one
    FormalElement that defines the scope of the subject EvidenceElement. The actual
    concept can be given by reference to an external formal vocabulary or ontology. The
    following statements are example of IsScopedBy: “This metric is scoped by the client
    subsystem.”
    Superclass
    EvidenceInterpretation
    Associations
    • scope:FormalElement[1] The FormalElement that is the scope of the subject of
    the relation.
    Constraints
    • The subject of the IsScopedBy relation shall not be its scope.
    Semantics
    “Scope” is defined as the area covered by a given activity or subject, which can be
    interpreted in either physical or logical sense. The IsScopedBy element asserts a state of
    affairs that the EvidenceElement, identified as the 'subject' of the IsScopedBy element, is
    delimited by the FormalElement that is identified as the 'scope' of the IsScopedBy
    element. The FormalElement may represent an individual concept, an abstract concept or
    an assertion.
    This characteristic is verbalized as follows: “EvidenceElement is scoped by
    FormalElement.”
    Change the rolename of the FormalAssertion association end of the IsCharacterizedBy
    statement on page 82 from:
    property:DomainAssertion[1] The DomainAssertion that is the property of the subject
    EvidenceElement.
    into
    assertion:DomainAssertion[1] The DomainAssertion that characterizes the subject
    EvidenceElement.
    Change text on page 82 from
    The IsCharacterizedBy element asserts a state of affairs that the EvidenceElement,
    identified as the element of the MeansThat element, is characterized by a proposition, in which the subject is bound to one of the role, and which is represented by the Object that
    is identified as the property of the IsCharacterizedBy element.
    into
    The IsCharacterizedBy statement asserts a state of affairs that the EvidenceElement,
    identified as the subject of the IsCharacterizedBy element, is characterized by an
    assertion, in which the subject is bound to one of the roles, and which is represented by
    the FormalAssertion that is identified as the 'assertion' property of the IsCharacterizedBy
    element.
    Change the text in the Semantics subsection of the MeansThat element, section 14.4.3,
    page 81 from:
    The MeansThat element asserts a state of affairs that the EvidenceElement, identified as
    the element of the MeansThat element, has meaning represented by the Object that is
    identified as the meaning of the MeansThat element. This characteristic is verbalized as
    follows: “EvidenceElement means that DomainAssertion.”
    into
    The MeansThat element asserts a state of affairs that the EvidenceElement, identified as
    the 'subject' of the MeansThat element, has meaning represented by the FormalAsserion
    that is identified as the' meaning' of the MeansThat element. This characteristic is
    verbalized as follows: “EvidenceElement means that FormalAssertion is true.”
    Change Figure 14.4 EvidenceInterpretation as follows: <<diagram on p 77 of ptc/2012-06-04

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

Incorporate 9.1.3 RoleBinding (p31) in a coherent way into merged SACM metamodel

  • Key: SACM-62
  • Legacy Issue Number: 16751
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 9.1.3 RoleBinding (p31) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Change superclass of the RoleBinding element (page 51) into 'SACM:UtilityElement'
    Change Figure 12.1 Formal Assertions Class Diagram

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

Incorporate 9.1.2 DomainClaim (p 31) in a coherent way into merged SACM metamodel

  • Key: SACM-61
  • Legacy Issue Number: 16750
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 9.1.2 DomainClaim (p 31) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Rename section 12.1.2. DomainClaim into ReferencedClaim
    Change text on page 51 from
    DomainClaim is an element of meaning which represents an informal proposition about
    the state of affairs in the domain about which the assurance case is developed.
    Superclass
    DomainAssertion
    Semantics
    DomainClaim is an element of meaning that states a generic proposition about the
    assurance case domain. DomainClaim is an informal element that represents claim as
    prose in a natural language (formal or informal), without identifying its structure.
    DomainClaim element can represent informal claims (claims not linked to any formal
    definition of its meaning, such as an ontology developed by some community of
    meaning) or unstructured claims (where the subjects are not identified).
    Usually claims state existence of a formally defined relationship between several
    individual domain objects and involve several subjects bound to specific roles. Assertion
    element can be used to capture this structure of a claim in a more formal way. In
    particular, Assertion element can link the proposition to an external vocabulary or
    ontology that defines the exact meaning of the proposition, as well as the exact subjects
    of the proposition.
    into
    ReferencedClaim is an element of meaning that represents an informal assertion about the
    state of affairs in the subject area about which the assurance case is developed.
    ReferencedClaim can be linked to a Claim element of the Argumentation part of the
    assurance case.
    Superclass
    FormalAssertion
    Associations claim:Argumentation::Claim [0..1] Claim element in the Argumentation part of the
    assurance case
    Semantics
    ReferencedClaim is an element of meaning that states an assertion about a subject area of
    the assurance case. ReferencedClaim represents the claim as prose in a selected natural
    language (formal or informal), without identifying its structure. ReferencedClaim
    element can represent informal claims (claims not linked to any formal definition of its
    meaning, such as an ontology developed by some community of meaning) or
    unstructured claims (where the subjects are not identified).
    Usually claims assert existence of a formally defined relationship between several
    individual subjects and involve several objects bound to specific roles. An Assertion
    element can be used to capture this structure of a claim in a more formal way. In
    particular, the Assertion element can link the proposition to an external vocabulary or
    ontology that defines the exact meaning of the proposition, as well as the exact subjects
    of the proposition.
    Change text on page 39 from
    DomainClaim subclass represents an informal assertion.
    into
    ReferencedClaim subclass represents an informal assertion.
    Rename element DomainClaim at Figure 12.1, page 50
    Change text on page 51 from
    For informal assurance cases, a DomainClaim element can be used, which only contains
    the verbalization of the claim in a natural language.
    into
    For semi-formal and informal assurance cases, a ReferencedClaim element can be used,
    which only contains the verbalization of the claim in a natural language.
    Change text on page 69 from
    The Evidence Relations Class Diagram focuses at the evidence relations between
    EvidenceItem, such as Exhibit and DomainAssertion, such as DomainClaim.
    into
    The Evidence Relations Class Diagram focuses at the evidence relations between
    EvidenceItem, such as Exhibit and Assertion or ReferencedClaim
    Change text on page 70 from
    The EvidenceItem object, such as an Exhibit or a Document that has evidentiary relations
    to a DomainAssertion object such as a DomainClaim.
    into
    The EvidenceItem object, such as an Exhibit or a Document that has evidentiary relations
    to a FormalAssertion object such as an Assertion or a ReferencedClaim.
    Change text on page 81 from
    Alternatively an informal DomainClaim can be used.
    into
    Alternatively an informal ReferencedClaim can be used.
    Change the entry in Annex A, page 108 from 'DomainClaim' into 'ReferencedClaim'
    Change text in Annex A, page 108 from
    based on Software Assurance Evidence Metamodel (10.1.2) [‘DomainClaim’] into
    based on Software Assurance Evidence Metamodel (10.1.2) [‘ReferencedClaim’]

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

Incorporate 9.1.1 Assertion (p30) in a coherent way into merged SACM metamodel

  • Key: SACM-60
  • Legacy Issue Number: 16749
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 9.1.1 Assertion (p30) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Change the description of the Assertion element, section 12.1.1, pages 50-51 into:
    An Assertion is a relationship involving one or more formal objects, taken as formal
    proposition that has a distinct, separate existence, a self-contained piece of information
    that can be referenced as a unit. Assertion is the key constituent of a conceptual model
    underlying the assurance case. Assertion represents an asserted fact about the subject area
    for which the assurance case is being developed.
    Superclass
    FormalAssertio
    Attributes
    • facctype:String Designation of the fact type
    Associations
    • role:RoleBinding[0..*] Set of role bindings that further describe which
    DomainObject are bound to the roles that are determined by the fact type.
    • definition:MOF::Element A link to an entry of an external SBVR vocabulary or
    an OWL ontology defining the fact type of the assertion.
    Semantics
    Assertion is an element of meaning that states existence of a relationship between several
    individual formal objects. In a formal assurance case, the nature of the relationship is
    specified through a reference to an external vocabulary, such as an SBVR vocabulary or
    an OWL ontology. SACM assumes that the community of interest for the assurance case
    will acquire or develop such vocabularies for the corresponding subject area. In a semiformal
    assurance case the nature of the relationship can be described informally through a
    'content' property. In this case the 'definition' property and the 'facttype' property shall not
    be used. However the references to the exact FormalObjects through RoleBinding
    elements can be still stated. The 'content' property of the FormalAssertion element
    provides the verbalization of the assertion, in the form of an expression of the assertion in a selected natural language. For informal assurance cases, a ReferencedClaim element
    can be used, which only contains the verbalization of the claim in a natural language.

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

Incorporate 9.2.3 UnknownSubject (p34) in a coherent way into merged SACM metamodel

  • Key: SACM-65
  • Legacy Issue Number: 16754
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 9.2.3 UnknownSubject (p34) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Rename section 12.2.3 UnknownSubject (page 54) into UnknownObject
    Change text on page 54 from
    UnknownSubject represents an unknown individual, existence of which is however is
    determined by the pattern of relationships in the fact model, and that is involved in
    assertions constituting the conceptual model underlying the assurance case.
    Superclass
    FormalObject
    Semantics
    UnknownSubject is an element of meaning. UnknownSubject shall be used in fact model
    underlying the assurance case to represent unknown subjects of assertions, in particular
    when more than one assertion refers to the same subject.
    into
    UnknownObject represents an unknown individual, existence of which is however is
    determined by the pattern of relationships in formal statements, and that is involved in
    assertions constituting the conceptual model underlying the assurance case.
    Superclass
    FormalObject
    Semantics
    UnknownObject is an element of meaning. UnknownObject shall be used in the
    conceptual model underlying the assurance case to represent unknown subjects of
    assertions, in particular when more than one assertion refers to the same subject. An
    UnknownObject is not linked to an external noun concept definition (as opposed to an
    Object element).
    Rename class UnknownSubject on Figure 12.2 into UnknownObject

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

Incorporate 9.2.2 Object (p33) in a coherent way into merged SACM metamodel

  • Key: SACM-64
  • Legacy Issue Number: 16753
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 9.2.2 Object (p33) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Add to definition of Object (pages 53-54):
    Attributes
    concept:String Designation of the noun concept
    Associations
    definition:MOF::Element A link to an entry in an external SBVR vocabulary or an
    OWL vocabulary defining the noun concept of the object.

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

Incorporate 8.1.12 IsReleasableTo (p28) in a coherent way into merged SACM metamodel

  • Key: SACM-59
  • Legacy Issue Number: 16748
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.12 IsReleasableTo (p28) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

Incorporate 8.1.11 HasSecurityClassification (p28) in a coherent way into merged SACM metamodel

  • Key: SACM-58
  • Legacy Issue Number: 16747
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.11 HasSecurityClassification (p28) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

Incorporate 8.1.10 HasVersion (p27) in a coherent way into merged SACM metamodel

  • Key: SACM-57
  • Legacy Issue Number: 16746
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.10 HasVersion (p27) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

Incorporate 8.1.9 IsExpressedInLanguage (p26) in a coherent way into merged SACM metamodel

  • Key: SACM-56
  • Legacy Issue Number: 16745
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.9 IsExpressedInLanguage (p26) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

Incorporate 9.2.4 CompositeSubject (p34) in a coherent way into merged SACM metamodel

  • Key: SACM-66
  • Legacy Issue Number: 16755
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 9.2.4 CompositeSubject (p34) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Rename section 12.2.4 CompositeSubject into CompositeObject (page 54)
    Change text 'CompositeSubject' into 'CompositeObject' in section 12.2.4
    Rename class CompositeSubject into CompositeObject on Figure 12.2
    change the rolename of the CompositeObject in containment association to
    FormalElement into 'composite' at Figure 12.1

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

Incorporate 8.1.6 HasMedia (p25) in a coherent way into merged SACM metamodel

  • Key: SACM-54
  • Legacy Issue Number: 16743
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.6 HasMedia (p25) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

Incorporate 8.1.8 IsBasedOn (p26) in a coherent way into merged SACM metamodel

  • Key: SACM-55
  • Legacy Issue Number: 16744
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.8 IsBasedOn (p26) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

SAEM: Page 16, section 8.2.2

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

    The ARM approach to the description of elements seems better: use an attribute called “content” in an abstract class to contain the “prose” description, and allow this attribute to be inherited by sub-classes.

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

    No Data Available

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

SAEM: Page 13, section 7.4, in table

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

    It is not clear why the EvidenceEvaluation relationship types “weakens” and “amplifies” are themselves between Evidence relations.

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

    Change text in section 14.5.3, page 84 from
    For example, one may assert that the evidence that support the claim that “Bob is married
    to Alice” weakens the claim that “Bob is single” (see weakens element). These
    dependencies help further evaluation of evidence.
    into
    For example, let's assume the following evidentiary relationships:
    Exhibit A supports claim "Bob is married to Alice"
    Exhibit A challenges claim "Bob is single"
    We can observe that the claim "Bob is married to Alice" conflicts with the claim "Bob is
    single"
    Let's further assume the following evidentiary relationship:
    Exhibit C supports claim Exhibit A is likely a forgery
    We can observe that
    The evidence assertion Exhibit C supports claim "Exhibit A is likely a forgery" weakens
    support given by the Exhibit A to the claim "Bob is married to Alice"
    at the same time we do not directly assert that
    Exhibit C challenges the claim "Bob is married to Alice"
    Evidence observations help capture dependencies between related claims and thus
    facilitate evaluation of evidence.
    Change text in section 14.5.4, page 85 from
    Weakens element asserts that one EvidenceRelation-1 element weakens another
    EvidenceRelation-2 element. This has a different meaning that the statement that any
    evidence supporting DomainAssertion-1 that is the assertion of EvidenceRelation-1,
    challenges the DomainAssertion-2 that is the assertion of the EvidenceRelation-2.
    Weakens relation may imply a conflict between DomainAssertion-1 and
    DomainAssertion-2. In that case evidence in support of DomainAssertion-1 is not
    relevant to DomainAssertion-2. For example, one may assert that the evidence that
    support the claim that “Bob is married to Alice” weakens the claim that “Bob is single.”
    Weakens dependencies help further evaluation of evidence.
    into
    Weakens element asserts that the subject EvidenceRelation weakens another
    EvidenceRelation2. This statement has a different meaning than a statement about
    existence of an evidence item that (directly) challenges the FormalAssertion that is
    involved in the EvidenceRelation2. Weakens relation may imply a conflict between the
    subject FormalAssertion that is involved in the subject EvidenceRelation and FornalAssertion2. In that case the evidence in support of the subject FormalAssertion is
    not relevant to FormalAssertion2.
    change text in the Semantics subsection from:
    The Weakens element asserts a state of affairs that the EvidenceRelation-1, identified as
    relation1 of the Weakens element, weakens EvidenceRelation-2 that is identified as
    relation2 of the Weakens element.
    into
    The Weakens element asserts a state of affairs that the EvidenceRelation-1, identified as
    the 'subject' of the Weakens element, weakens EvidenceRelation-2 that is identified as the
    'relation' of the Weakens element. The Weakens statement asserts a negative contribution
    made by one EvidenceEvaluation to another EvidenceEvaluation.
    Change text on page 85 from:
    This characteristic is verbalized as follows: “Evidentiary support to DomainAssertion-1
    weakens evidentiary support to DomainAssertion-2”
    into
    This characteristic is verbalized as follows: “Evidentiary support to the subject
    FormalAssertion weakens evidentiary support to FormalAssertion-2”, where "Evidentiary
    support to a FormalAssertion C1" is an objectified assertion that there is an evidence
    item E1 that supports the FormalAssertion C1.
    Change text section 14.5.5, page 85 from
    Amplifies element asserts that one EvidenceRelation-1 element amplifies another
    EvidenceRelation-2 element. This has a different meaning that the statement that any
    evidence supporting DomainAssertion-1 that is the assertion of EvidenceRelation-1,
    supports the DomainAssertion-2 that is the assertion of the EvidenceRelation-2.
    Amplifies relation may imply a coupling between DomainAssertion-1 and
    DomainAssertion-2. In that case evidence in support of DomainAssertion-1 may be
    relevant to DomainAssertion-2. For example, one may assert that the evidence that
    support the claim that “Bob is married to Alice” amplifies the claim that “Bob is not
    single.” Amplifies dependencies help further evaluation of evidence.
    into
    Amplifies element asserts that the subject EvidenceRelation amplifies another
    EvidenceRelation2. This statement has a different meaning than the statement about
    existence of an evidence item that (directly) supports the FormalAssertion that is
    involved in the EvidenceRelation2. Amplifies relation may imply a coupling between
    subject FormalAssertion and the FormalAssertion2. In that case evidence in support of
    the subject FormalAssertion may be relevant to the FormalAssertion2.
    Change text in the Semantics subsection from "The Amplifies statement represents a
    negative contribution made by one EvidenceEvaluation to another EvidenceEvaluation."
    into
    The Amplifies statement asserts a positive contribution made by one EvidenceEvaluation
    to another EvidenceEvaluation."
    Change text on page 86 from This characteristic is verbalized as follows: “Evidentiary support to DomainAssertion-1
    amplifies evidentiary support to DomainAssertion-2”
    into
    This element can be verbalized as follows: “Evidentiary support to the subject
    FormalAssertion amplifies evidentiary support to FormalAssertion-2”

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

SAEM: Page 19, section 8.2.8

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

    The use of a “content” attribute is suggested for the “stmt” attribute. See comment 5.

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

    All references are against document ptc/2012-04-04
    Change the description of the 'stmt' attribute for class FormalAssertion (used to be
    DomainAssertion but is being renamed as the result of the resolution to related issue
    16735), on page 39 from
    • stmt:String The statement that is the expression of the domain assertion
    (verbalization of the statement in a natural language).
    into
    • content:String The statement in a selected language that is the expression of the
    formal assertion (verbalization of the assertion in a natural language). Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
    DomainAssertion but is being renamed as the result of the resolution to related issue
    16735), Figure 10.1, page 35
    Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
    DomainAssertion but is being renamed as the result of the resolution to related issue
    16735), Figure 14.4, page 80
    Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
    DomainAssertion but is being renamed as the result of the resolution to related issue
    16735), Figure 12.1, page 50
    Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
    DomainAssertion but is being renamed as the result of the resolution to related issue
    16735), Figure 14.1, page 69
    Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
    DomainAssertion but is being renamed as the result of the resolution to related issue
    16735), Figure 14.5, page 83
    Rename attribute 'stmt' into 'content' in class FormalAssertion (used to be
    DomainAssertion but is being renamed as the result of the resolution to related issue
    16735), Figure 14.6, page 86
    Change text on page 51 from
    In a semi-formal assurance case the nature of the relationship can be described informally
    through a stmt property.
    into
    In a semi-formal assurance case the nature of the relationship can be described informally
    through a 'content' property.
    Change Reference schema for Domain Assertion on page 106 from
    Reference schema: stmt of Domain Assertion
    into
    Reference schema: content of Formal Assertion

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

Page 16, section 8.2.2 (2)

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

    To stipulate the structure of the id of an element is over-constraining. If the URL of the organisation is important to capture, then there should be a separate attribute for it; the name of the SAEM class is surely redundant. It should be sufficient to state that, whatever the identifiers used, they are to be globally unique, and let the implementers solve the problem how they will.

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

    Add to the semantics of ModelElement:
    id of the model element shall be unique in the corresponding package (AssuranceCase,
    Argumentation or EvidenceContainer). Integration of multiple packages into a larger
    package, for example, adding Argumentation and EvidenceContainer to an
    AssuranceCase shall not affect the uniqueness of ids of all the objects involved.
    Add to the semantics of AssuranceCase:
    AssuranceCase shall have a globally unique gid attribute.
    Constraints
    gid is a string that has the following structure: unique url of the organization that created the assurance case
    the text 'AssuranceCase'
    a unique number
    For each contained object of the assurance case the gid+id identifier is globally unique,
    i.e., no two elements of the same type produced by the same organization shall have the
    same number.
    Add to the semantics of EvidenceContainer:
    EvidenceContainer shall have a globally unique gid attribute.
    Constraints
    gid is a string that has the following structure:
    unique url of the organization that created the evidence container
    the text 'EvidenceContainer'
    the unique number
    For each contained object the gid+id identifier is globally unique, i.e., no two evidence
    elements of the same type produced by the same organization shall have the same
    number.

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

SAEM: Typographical errors

  • Key: SACM-38
  • Legacy Issue Number: 16713
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Page 1, section 1.2, 2nd paragraph:
    This sentence is representative of the systemic grammatical errors that pervade the document, which centre mainly around missing definite and indefinite articles. The sentence should perhaps read: “The level of confidence that a given software system is trustworthy is called Software Assurance (SwA) and the process that establishes the level of confidence is called SwA process.” (Italics indicate inserted words.)

    Page 20-21, sections 9.1 and 9.1.1:
    The paragraph stating “The most common form of an exhibit ...” is repeated in these two sections. In general, there is a considerable amount of repeated text in the document, usually between the descriptions and the semantics.

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

    The paragraphs, mentioned in the text of the issue have been removed. Several typos have been corrected in
    the process of providing resolutions to other issues.
    Disposition: Closed, no change

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

SAEM: Page 35, section 11

  • Key: SACM-37
  • Legacy Issue Number: 16711
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Rather than trying to enumerate all the possible properties that evidence could possess, it may be better to consider a extensible mechanism such as the TaggedValue class in ARM. This principle would simplify the model considerably if applied to all such properties, by the time Provenance, TimingProperty, CustodyProperty, EvidenceProperty and DocumentProperty sub-classes have been taken into account. Detailed enumerations such as these are bound to be incomplete; user defined values are more flexible.

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

    This has been already resolved through related issues 16730, 16731, 16736, 16773,
    16740, 16756, 16760 and 16845 to the extent consistent with the intent of the Evidence
    Metamodel to provide a structured an well-defined (interoperable) way of constructing
    and exchanging statements related to evidence.
    Disposition: Duplicate

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

SAEM: Page 24,section 9.1.4

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

    Since, as stated under Constraints, an exhibit shall not have more than one electronic source, then this could be made into an attribute of the Exhibit class rather than an association.

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

    The intent of the Evidence Metamodel is to provide more structured ways of constructing
    statements related to evidence. One of the goals is to facilitate normalized representation
    of such statements as well as the mapping of such statements to RDF triples. Therefore, a
    uniform mechanism was selected, which involves using an explicit association class
    technique, where the extra association class directly corresponds to a verb in the evidence
    statement. The above suggestion does not satisfy these objectives.
    Disposition: Closed, no change

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

SAEM: Page 21,section 9.1,figure 6

  • Key: SACM-33
  • Legacy Issue Number: 16707
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Assuming that a document has only one medium (which is likely, otherwise there would be two exhibits), then the model would be simplified by making “medium” an attribute of a Document.

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

    This issue was raised during the review of the Evidence metamodel by Integrate.
    Reject - current situation allows optionality (And is more fact oriented the current way).
    The modeling style of the Evidence metamodel uses MOF in a disciplined way which facilitates a more
    straightforward mapping to RDF triples and to SBVR statements. In particular, the modeling style of the
    Evidence Metamodel introduces explicit "attribute association classes" named with verbs or verb phrases
    when an attribute of an entities is modeled. Shortcutting this pattern using "natural modeling style" breaks
    this pattern and makes RDF mapping more complicated.
    Disposition: Closed, no change

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

SAEM: The class DocumentAttribute does not seem to be described in the standard

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

    The class DocumentAttribute does not seem to be described in the standard

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

    All references are against document ptc/2012-04-04
    remove class DocumentAttribute from EvidenceElements diagram (Figure 10.1, see
    resolution 16729 and related)
    move sections 14.3.1-14.3.8 from DocumentAttributes section 14.3 from chapter 14 to
    chapter 11 to the bottom of section 11.2 and delete the rest of section 14.3
    rename class DocumentAttribute into DocumentProperty (new section 11.2)
    delete entire Associations subsection from Document section.
    Change text of 1st para of section DocumentProperty into:
    "This class defines characteristics of documents. Other characteristics common to all
    Exhibits are defined using ExhibitProperty.".
    change superclass of DocumentProperty to ExhibitProperty (new section 11.2)
    add DocumentPropertyClass to EvidenceAssertions diagram (see resolution 16730)
    move classes HasVersion,
    IsExpressedInLanguage, IsReleaseableTo, HasSecurityClassification from class diagram
    Exhibits to class diagram DocumentProperties (new section 11.2)
    move sections 11.1.10, 11.1.9, 11.1.12, 11.1.11 from section 11.1 into the new section
    11.2 remove the ShortTitle attribute from the attribute subsection of the Document element
    (page 42, 11.1.2)
    rename class ExtendedDocumentAttribute into ExtendedDocumentProperty
    Change text in section ExtendedDocumentAttribute (introduced as part of resolution to
    16845 as follows:
    Change text "ExtendedDocumentAttribute" into "ExtendedDocumentProperty" (5
    occurences)
    Change superclass of ExtendedDocumentProperty (former ExtendedDocumentAttribute)
    to DocumentProperty
    Change Figure 14.3 Document Attributes Class Diagram as follows:
    Modifications to this diagram accumulate resolution 16845

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

SAEM: Page 21, section 9.1, figure 6

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

    The class “IsPartOf” is an example of an instance in the standard where a class is used to represent a relationship where a simple UML association would do. The concept is that an Exhibit can be part of other Exhibits. This is most naturally expressed as an “isPartOf” association that has Exhibit as its source and target. Introducing a class for this relationship clutters the model.

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

    This issue was raised during the review of the Evidence metamodel by Integrate.
    Reject - current situation is fact oriented (aligns with SBVR). The modeling style of the
    Evidence metamodel uses MOF in a disciplined way which facilitates a more straightforward mapping to
    RDF triples and to SBVR statements. In particular, the modeling style of the Evidence Metamodel
    introduces explicit "association classes" named with verbs or verb phrases when a relation between two
    entities is modeled. Shortcutting this pattern using "natural modeling style" breaks this pattern and makes
    RDF mapping more complicated.
    Disposition: Closed, no change

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

SAEM: Page 12, text under figure 3

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

    Can assertions not be deleted, if not revoked?

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

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

SAEM: Page 11, section 7.3, figure 2

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

    This state transition diagram could be simplified by amalgamating the two main states at either end of the “re-evaluated” transition. Note that the transitions “transferred”, “evaluated” and “revoked” have analogous behaviour on these two states. Similarly in Figure 3.

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

    see pages 36 - 37 of ptc/2012-06-04

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

SAEM: Page 33, section 10.2.2

  • Key: SACM-36
  • Legacy Issue Number: 16710
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    The description of Object starts with the class name FormalObject, which is probably a copying error.

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

    All references are against document ptc/2012-04-04
    Change text on page 53 from
    FormalObject represents a known individual that can be involved in assertions
    constituting the conceptual model underlying the assurance case.
    into
    Object element represents a known individual that can be involved in assertions
    constituting the conceptual model underlying the assurance case (formal statements).

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

SAEM: Page 33, section 10.2.1

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

    The phrase “an individual” without qualification usually refers to a person, which is not intended here. This should be stated as “an individual fact” or “an individual concept

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

    change 'individual' to 'object' in 12.2.3, page 54
    change 'individuals' to 'objects' in 12.2.4 page 54
    change 'individual' to 'object' in 12.2.1, page 53
    change 'individual' to 'object' in 12.2.2, page 53

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

Incorporate 11.4.1 EvidenceInterpretation (abstract) (p60) in a coherent way into merged SACM metamodel

  • Key: SACM-109
  • Legacy Issue Number: 16800
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.4.1 EvidenceInterpretation (abstract) (p60) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Change rolename of the EvidenceElement in section 14.4.1, page 81, from: element:EvidenceElement[1]
    into
    subject:EvidenceElement[1]
    Change rolename of EvidenceElement from 'element' into 'subject' on Figure 14.4
    Add class ProvidesContext to diagram 14.4
    Remove class ProvidesContext from Figure 14.7
    Add definition of ProvidesContext after section 14.4.5 IsScopedBy (at the end of section
    14.4) as follows:
    "14.4.6. ProvidesContext
    ProvidesContext element represents statements that assert that a certain evidence element
    provides a context for the interpretation of another evidence element.
    Superclass
    EvidenceInterpretation
    Associations
    subject:EvidenceElement[1] The subject of the ProvidesContext clause
    context:EvidenceElement[1] The element that is asserted to represent the context for the
    subject
    Semantics
    ProvidesContext element establishes a relationship between two evidence elements where
    the 'context' evidence element (usually an EvidenceGroup) provides a context for the
    'subject' evidence element (usually a FormalAssertion, or an EvidenceAssertion). A
    'context' is defined as the set of evidence elements (including evidence items, evidence
    assertions and even project elements) that are important for understanding of the 'subject'
    evidence element. The concept of a context is more informal than the related concept of
    'scope' (see 'IsScopedBy' assertion).
    "
    Delete class Supercedes
    Move class EvidenceGroup to EvidenceElements diagram
    Move section 14.7.1 EvidenceGroup from section 14.7 to chapter 10 Evidence Elements
    Delete section 14.7 Evaluation Context Class Diagram, pages 88-89
    Replace Figure 14.4 with the following: diagrams on p 88 of ptc/2012-06-04

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

Incorporate 11.5.2 Conflicts (p64) in a coherent way into merged SACM metamodel

  • Key: SACM-115
  • Legacy Issue Number: 16806
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.5.2 Conflicts (p64) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The resolution to this issue is provided by the related issue 16805
    Disposition: Merged

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

Incorporate 11.5.1 EvidenceObservation (abstract) (p64) in a coherent way into merged SACM metamodel

  • Key: SACM-114
  • Legacy Issue Number: 16805
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.5.1 EvidenceObservation (abstract) (p64) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Change rolenames from Conflicts (section 14.5.2, page 84) into
    subject: FormalAssertion[1] The subject DomainAssertion
    assertion: FormalAssertion[1] The object DomainAssertion
    Change rolenames for Contributes (section 14.5.3, page 85)
    subject: EvidenceRelation[1] The subject EvidenceRelation
    relation: EvidenceRelation[1] The object EvidenceRelation
    Change rolename 'assertion1' on Figure 14.5 into 'subject'
    Change rolename 'assertion2' on Figure 14.5 into assertion
    Change rolename 'relation1' on Figure 14.5 into 'subject'
    Change rolename 'relation2' on Figure 14.5 into 'relation'
    Replace Figure 14.5 with the following: <<diagram on p 90 of ptc/2012-06-04>>

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

Incorporate 11.3.6 CompletenessLevel (enumeration) (p59) in a coherent way into merged SACM metamodel

  • Key: SACM-106
  • Legacy Issue Number: 16797
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.6 CompletenessLevel (enumeration) (p59) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 11.3.5 Completeness (p58) in a coherent way into merged SACM metamodel

  • Key: SACM-105
  • Legacy Issue Number: 16796
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.5 Completeness (p58) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Completeness level are specified by a separate element <<Enumeration>>
    CompletenessLevel. Potential changes to these values are addressed by a separate issue 16797.
    Disposition: Closed, no change

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

Incorporate 11.3.8 ReliabilityLevel (enumeration) (p59) in a coherent way into merged SACM metamodel

  • Key: SACM-108
  • Legacy Issue Number: 16799
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.8 ReliabilityLevel (enumeration) (p59) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 11.3.7 Reliability (p59) in a coherent way into merged SACM metamodel

  • Key: SACM-107
  • Legacy Issue Number: 16798
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.7 Reliability (p59) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Reliability level are specified by a separate element <<Enumeration>> ReliabilityLevel.
    Potential changes to these values are addressed by a separate issue 16799.
    Disposition: Closed, no change

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

Incorporate 11.4.3 MeansThat (p61) in a coherent way into merged SACM metamodel

  • Key: SACM-111
  • Legacy Issue Number: 16802
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.4.3 MeansThat (p61) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. In
    particular, this assertion allows formal interpretation of evidence items. Any connection to the SACM
    common classes is accomplished through the element's superclass. No other changes to this element are
    anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.4.2 IsA (p61) in a coherent way into merged SACM metamodel

  • Key: SACM-110
  • Legacy Issue Number: 16801
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.4.2 IsA (p61) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. In
    particular, this assertion allows formal interpretation of evidence items. Any connection to the SACM
    common classes is accomplished through the element's superclass. No other changes to this element are
    anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.4.4 IsCharacterizedBy (p62) in a coherent way into merged SACM metamodel

  • Key: SACM-112
  • Legacy Issue Number: 16803
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.4.4 IsCharacterizedBy (p62) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. In
    particular, this assertion allows formal interpretation of evidence items. Any connection to the SACM
    common classes is accomplished through the element's superclass. No other changes to this element are
    anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.4.5 IsScopedBy (p62) in a coherent way into merged SACM metamodel

  • Key: SACM-113
  • Legacy Issue Number: 16804
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.4.5 IsScopedBy (p62) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of an evidence item. In
    particular, this assertion allows formal interpretation of evidence items. Any connection to the SACM
    common classes is accomplished through the element's superclass. No other changes to this element are
    anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.5.4 Weakens (p65) in a coherent way into merged SACM metamodel

  • Key: SACM-116
  • Legacy Issue Number: 16808
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.5.4 Weakens (p65) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.3.4 ConsistencyLevel (enumeration) (p58) in a coherent way into merged SACM metamodel

  • Key: SACM-104
  • Legacy Issue Number: 16795
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.4 ConsistencyLevel (enumeration) (p58) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 11.1.2 Supports (p50) in a coherent way into merged SACM metamodel

  • Key: SACM-88
  • Legacy Issue Number: 16778
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.1.2 Supports (p50) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.1.1 EvidenceRelation (abstract) (p50) in a coherent way into merged SACM metamodel

  • Key: SACM-87
  • Legacy Issue Number: 16777
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.1.1 EvidenceRelation (abstract) (p50) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Change rolename of the EvidenceItem element section 14.1.1, page 70 from:
    item:EvidenceItem[1] The EvidenceItem object, such as an Exhibit or a Document that
    has evidentiary relations to a DomainAssertion object such as a DomainClaim.
    into
    subject:EvidenceItem[1] The EvidenceItem object, such as an Exhibit or a Document that
    is the subject of an evidentiary relation to a FormalAssertion object such as a
    ReferencedClaim.
    Change text section 14.1 page 69 from:
    The Evidence Relations Class Diagram focuses at the evidence relations between
    EvidenceItem, such as Exhibit and DomainAssertion, such as DomainClaim.
    EvidenceRelation elements allow specifying exact statement of evidentiary support
    between EvidenceItem and DomainAssertion.
    into
    The Evidence Relations Class Diagram provides elements that represent statements of
    evidentiary support relations between an EvidenceItem, such as an Exhibit and a
    FormalAssertion.
    rename rolename of EvidenceItem from 'item' into 'subject' on Figure 14.1.
    Replace Figure 14.1 with the following: <<diagram on p 86 of ptc/2012-06-04 >>

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

Incorporate 10.4.8 CareOf (p46) in a coherent way into merged SACM metamodel

  • Key: SACM-84
  • Legacy Issue Number: 16774
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.8 CareOf (p46) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Custody property of an evidence
    item. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.4.7 CustodyProperty (abstract) (p46) in a coherent way into merged SACM metamodel

  • Key: SACM-83
  • Legacy Issue Number: 16773
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.7 CustodyProperty (abstract) (p46) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Add section Custody Class Diagram at the beginning of chapter 13 Evidence Properties, as section 13.1,
    renumber other sections of chapter 13 accordingly. Add text to the beginning of the new Custody section:
    "
    13.1 Custody Class Diagram
    The Custody class diagram represents various statements related to the Custody of an
    EvidenceElement. These statements describe the custodians of an evidence element, the
    locations associated with various events in the lifecycle of the evidence element, as well
    as the process by which the element was obtained.
    "
    move sections 13.4.7- 13.4.10 to section 13.1
    Add Figure Custody Class Diagram as follows: <<diagram on p 84 of ptc/2012-06-04

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

Incorporate 11.2.4 ReportingLevel (enumeration) (p53) in a coherent way into merged SACM metamodel

  • Key: SACM-92
  • Legacy Issue Number: 16783
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.4 ReportingLevel (enumeration) (p53) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 11.2.3 Reporting (p52) in a coherent way into merged SACM metamodel

  • Key: SACM-91
  • Legacy Issue Number: 16782
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.3 Reporting (p52) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Reporting level are specified by a separate element <<Enumeration>> ReportingLevel.
    Potential changes to these values are addressed by a separate issue 16783.
    Disposition: Closed, no change

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

Incorporate 10.4.6 IsGeneratedAt (p45) in a coherent way into merged SACM metamodel

  • Key: SACM-82
  • Legacy Issue Number: 16772
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.6 IsGeneratedAt (p45) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to custody events in the life cycle of a
    given evidence item. Any connection to the SACM common classes is accomplished through the element's
    superclass. No other changes to this element are anticipated according to the selected level of the
    integration.
    Disposition: Closed, no change

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

Incorporate 10.4.5 IsRevokedAt (p44) in a coherent way into merged SACM metamodel

  • Key: SACM-81
  • Legacy Issue Number: 16771
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.5 IsRevokedAt (p44) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to custody events in the life cycle of a
    given evidence item. Any connection to the SACM common classes is accomplished through the element's
    superclass. No other changes to this element are anticipated according to the selected level of the
    integration.
    Disposition: Closed, no change

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

Incorporate 11.2.1 Support (p51) in a coherent way into merged SACM metamodel

  • Key: SACM-90
  • Legacy Issue Number: 16780
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.1 Support (p51) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Support level are specified by a separate element <<Enumeration>> SupportLevel. Potential
    changes to these values are addressed by a separate issue 16781.
    Disposition: Closed, no change

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

Incorporate 11.1.3 Challenges (p50) in a coherent way into merged SACM metamodel

  • Key: SACM-89
  • Legacy Issue Number: 16779
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.1.3 Challenges (p50) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 10.4.4 IsTransferredTo (p43) in a coherent way into merged SACM metamodel

  • Key: SACM-80
  • Legacy Issue Number: 16770
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.4 IsTransferredTo (p43) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to custody events in the life cycle of a
    given evidence item. Any connection to the SACM common classes is accomplished through the element's
    superclass. No other changes to this element are anticipated according to the selected level of the
    integration.
    Disposition: Closed, no change

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

Incorporate 10.4.9 AtLocation (p47) in a coherent way into merged SACM metamodel

  • Key: SACM-85
  • Legacy Issue Number: 16775
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.9 AtLocation (p47) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Custody property of an evidence
    item. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.4.10 UsingProcess (p47) in a coherent way into merged SACM metamodel

  • Key: SACM-86
  • Legacy Issue Number: 16776
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.10 UsingProcess (p47) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Custody process of an evidence
    item. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Increased clarity needed

  • Key: SACM-5
  • Legacy Issue Number: 16294
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    While clarity needs improvement throughout, the following are specific instances:
    • An explanation is needed of how the two sets of provenance-related classes and event-related classes need to be clearly and cleanly related to each other and to other elements.
    • The terms “role” and “rolebinding” need clear explanations..
    • The word “role” appears to be used both casually and technically. Use it only in the latter way.
    • Term “subject claim” is unnecessary and potentially confusing ­ why bother users with it.
    • As introductory material, Figure 1 is unclear, for example “evidence observation” sounds like an observation done to obtain evidence.
    • Meaning of “revoked” is unclear as generally nothing should be destroyed. Something might be excluded from assurance case (and maybe later brought back).

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

    Chapter 12, page 49, replace sentence "So, an Assertion element represents a fact involving one or more
    Objects" with "So, an Assertion element represents a fact involving one or more Objects bound to specific roles
    associated with the fact type of the assertion. The concepts fact type, role, element is bound to a role are
    defined in SBVR. In particular, a fact type is defined as a concept that is the meaning of a verb phrase that
    involves one or more noun concepts and whose instances are all actualities. A role is defined as a noun
    concept that corresponds to things based on their playing a part, assuming a function or being used in some
    situation. Specifically, a fact type role characterizes its instances by their involvement in an actuality that is
    an instance of a given fact type."
    section 13.4.5 page 64, table entry for AtLocation replace word 'roles' with 'locations'
    section 14.6.3, replace 'plays an important role" with "is important"
    section 14.6.4. page 88, replace "plays an important role" into "is important"
    section 14.7.1. page 89 replace "and therefore can play a role of a named container" into "acting as a named
    container"
    section 15.2.7 Stakeholder, subsection semantics, add to the end: "The fact type "stakeholder has role with
    respect to evidence item" can be formally defined outside of the Evidence Metamodel and then referred to
    for the purpose of constructing formal statements related to stakeholders."
    13.4.5, page 64 replace text 'Revocation of an evidence element emphasizes that the evidence element is no
    longer admissible for supporting argument" into
    'Revocation of an evidence element means that the evidence element is no longer admissible for supporting
    argument while it is still available e.g. as an item in an evidence repository. A revoked element may still
    remain as the subject of assertions stating evidentiary support to some claims. Such relations may need to
    be evaluated and explicitly negated based on the revocation event.'
    Replace semantics subsection of the IsRevokedAt with:
    IsRevokedAt element represents a property of the subject EvidenceElement object. IsRevokedAt element
    represents the state of affairs that the subject has been revokes. IsRevokedAt element may be the subject of
    additional properties describing further details about the revocation event.

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

General mistaken cardinality issue

  • Key: SACM-2
  • Legacy Issue Number: 16282
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    Several specific instances of cardinality-related problems are identified in other issues. However, as these are potentially symptoms of a potentially more general problem, a general review should be made of cardinalities and limits placed only when inherent and essential

  • Reported: SACM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Significant model changes have been done during the FTF work, and cardinalities fixed. This issue
    therefore is closed.
    Disposition: Closed, no change

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

Difference between properties and attributes fuzzy and unneccessary

  • Key: SACM-1
  • Legacy Issue Number: 16278
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    The distinction between "property" and "attribute" is unclear and could be confusing; and it is unnecessary.

    An EvidenceProperty is defined to be "fundamental" and different kinds of properties are variously defined to be “a physical characteristic” “common”, “a single characteristic of the exhibit ,“ “provenance and timing characteristics “… Attributes are presumably otherwise ­ not fundamental. For example, “EvaluationAttribute is an abstract class that represents certain characteristics of various evidence elements that were asserted during the course of evaluation.”

    At one time, property was agreed to mean something inherent. “Fundamental” is even less clear than “inherent”.

    For example, physical measurements are always (or almost always) not inherent and can vary because of conditions and measurement error. Weight is not inherent, and how meaningful would it be to say it is fundamental? Provenance and [e.g. creation. revision] timing characteristics are often questionable and are they “fundamental”. The body of the evidence does not generally change if they are changed.

    The motivation for naming some things as a property and others as an attribute might on the surface appear to have some merit. In the end, however, this distinction turns out to be simply difficult and confusing. Any usefulness is questionable, and it is entirely unnecessary. It should be dropped and all such things called an “attribute”.

  • Reported: SACM 1.0b1 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    There is agreement to the suggested approach. Furthermore, this has been already
    resolved to the extent possible through related issues 16730, 16731, 16740, 16705, where
    most statement related to evidence are constructed using the elements that are subclasses
    of EvidenceProperty, with the only exception of EvidenceAttribute. This element is
    different, since it provides some measurable values related to the quality of the
    evidentiary support rendered by a certain Exhibit. There is also a common superclass
    called EvidenceAssertion. Editorial changes will further downplay the distinction
    between the 'fundamental' and 'contestable' assertions related to evidence and evidentiary
    support.
    Disposition: Closed, no change

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

Change name “Amplifies"

  • Key: SACM-8
  • Legacy Issue Number: 16297
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    "Amplifies" could easily be understood as "strengths". What is meant is "ExpoundsOn" (clearest) or "AmplifiesOn" (clearer). Alternately, possibly some other element already used to comment or explain could be used instead.

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

    Change text in section 14.5.5 page 85 from
    Amplifies element asserts that one EvidenceRelation-1 element amplifies another
    EvidenceRelation-2 element.
    into
    Amplifies element represents statements that asserts that one EvidenceRelation-1 element
    strengthens another EvidenceRelation-2 element.
    Change text in the Semantics section on page 86 from
    The Amplifies element asserts a state of affairs that the EvidenceRelation-1, identified as
    the relation1 of the Weakens element, amplifies EvidenceRelation-2 that is identified as
    the relation2 of the Amplifies element.
    into
    The Amplifies element asserts a state of affairs that the EvidenceRelation-1, identified as
    subject, strengthens EvidenceRelation-2 that is identified as the relation of the Amplifies
    element. The Amplifies statement represents a negative contribution made by one
    EvidenceEvaluation to another EvidenceEvaluation.

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

Eliminate or change name of “EffectiveTime"

  • Key: SACM-7
  • Legacy Issue Number: 16296
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    "EffectiveTime" is not an obvious term. This class might be best eliminated and its subclasses have TimingProperty as their superclass, or a more understandable name should be used.

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

    Change text of section 13.2.2, page 58, from
    EffectiveTime element is an abstract class that corresponds to effective time interval
    associated with the owner element. This element was added for readability purposes.
    into
    EffectiveTime element represents various compound statements that involve a certain
    time interval during which a certain proposition is asserted to be true (time-dependent
    assertions involving an "effective" time period).
    Change text of the semantics section on page 58 from:
    Semantics
    EffectiveTime element represents a property of the owner EvidenceElement object or
    EvidenceAttribute object. This element is an abstract class that establishes a relationship
    between the owner object and the detailed of the effective time interval of the owner
    object, defined by a particular concrete subclass of the TimingProperty element.
    into
    Semantics
    EffectiveTime element represents a statement about the subject EvidenceElement (an
    object that owns the instance of one of the concrete subclasses of this element). The
    EffectiveTime element specifies a time interval associated with the subject, during which
    the subject is asserted to be "effective". For example, in case of an EvidenceAssertion or
    a FormalAssertion, this element specifies a time interval at which the corresponding
    statement is asserted to be true. In case on am EvidenceItem this element specifies the
    relevant time context in which the element shall be considered.

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

Modify term “evidence collection project”

  • Key: SACM-4
  • Legacy Issue Number: 16290
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    Use of term “evidence collection project” is misleading as evidence is collected, generated, acquired, derived, evaluated, and it and information about it exchanged ­ and maybe other kinds of actions. A question also exists about whether it should be called a “project” as it is generally a crosscutting concern/effort within projects. Suggest, in order of preference, “included in interchange”, “involved in interchange” or “evidence-related efforts”. Emphasis on interchange is better where possible, but a mix of these might be needed.

  • Reported: SACM 1.0b1 — Sat, 28 May 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    page 9: replace "for evidence collection projects" with "for constructing and interchanging precise
    statements involved in evidence-related efforts"
    page 11: replace "evidence collection projects and exchange" with "evidence-related efforts and
    interchange"
    page 95: replace "to be performed during an evidence collection project (planning purposes), or has been
    performed during the project (tracking purposes)" into
    to be performed during an evidence-related (planning purposes), or has been performed during the effort
    (tracking purposes)
    page 96: replace "evidence collection project" with "evidence-related effort".
    Annex A: replace "evidence collection project" with "evidence-related effort"

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

A more generally available "citation" capability

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

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

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

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

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

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

ArgumentReasoning available for more relations

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

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

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

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

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

Definition for “Rationale” element missing

  • Key: SACM-9
  • Legacy Issue Number: 16298
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    A “Rationale” element appears in Figure 11.6 and is mentioned several times in text, but never defined. It either needs to be defined or the element from ARM that it essentially duplicates, ArgumentReasoning, be used instead.

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

    The resolution to this issue will be provided as part of the resolution to issue 16810
    Disposition: Merged

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

Improve wording (editorial)

  • Key: SACM-6
  • Legacy Issue Number: 16295
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    Generally replace “the assurance case” with “an assurance case” unless speaking of a particular one.

    Document needs to be worded throughout in ways that make it consistently clear that it is an interchange standard and not a repository standard.

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

    Systematically replace text "the assurance case" with "an assurance case"

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

Incorporate 10.2.1 TimingProperty (abstract) (p37) in a coherent way into merged SACM metamodel

  • Key: SACM-71
  • Legacy Issue Number: 16760
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.2.1 TimingProperty (abstract) (p37) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Remove class EvidenceProperty from Timing class diagram Figure 13.2
    Remove class EvaluationAttribute from Timing class diagram Figure 13.2
    Change Figure 13.2 Timing Class Diagram as follows: << diagram on p 82 of ptc/2012-06-04>>

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

Incorporate 10.1.4 OwnedBy (p36) in a coherent way into merged SACM metamodel

  • Key: SACM-70
  • Legacy Issue Number: 16759
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.1.4 OwnedBy (p36) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is useful leaf element that allows constructing meaningful statements about evidence. The only
    concern was related to the potential overlap with Custody statement elements, especially CareOf. However
    this distinction is already addressed in the semantic descriptions of the Evidence Metamodel specification.
    Disposition: Closed, no change

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

Incorporate 10.4.3 IsCreatedAt (p42) in a coherent way into merged SACM metamodel

  • Key: SACM-79
  • Legacy Issue Number: 16769
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.3 IsCreatedAt (p42) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to custody events in the life cycle of a
    given evidence item. Any connection to the SACM common classes is accomplished through the element's
    superclass. No other changes to this element are anticipated according to the selected level of the
    integration.
    Disposition: Closed, no change

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

Incorporate 10.4.2 IsAcquiredAt (p41) in a coherent way into merged SACM metamodel

  • Key: SACM-78
  • Legacy Issue Number: 16767
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.2 IsAcquiredAt (p41) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to custody events in the life cycle of a
    given evidence item. Any connection to the SACM common classes is accomplished through the element's
    superclass. No other changes to this element are anticipated according to the selected level of the
    integration.
    Disposition: Closed, no change

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

Incorporate 10.1.3 ApprovedBy (p36) in a coherent way into merged SACM metamodel

  • Key: SACM-69
  • Legacy Issue Number: 16758
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.1.3 ApprovedBy (p36) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Provenance property of an
    evidence item. Any connection to the SACM common classes is accomplished through the element's
    superclass. No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.1.2 CreatedBy (p35) in a coherent way into merged SACM metamodel

  • Key: SACM-68
  • Legacy Issue Number: 16757
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.1.2 CreatedBy (p35) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Provenance property of an
    evidence item. Any connection to the SACM common classes is accomplished through the element's
    superclass. No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.2.4 EndTime (p38) in a coherent way into merged SACM metamodel

  • Key: SACM-74
  • Legacy Issue Number: 16763
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.2.4 EndTime (p38) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Timing property of an evidence
    item. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.2.3 StartTime (p38) in a coherent way into merged SACM metamodel

  • Key: SACM-73
  • Legacy Issue Number: 16762
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.2.3 StartTime (p38) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Timing property of an evidence
    item. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.4.1 EvidenceEvent (abstract) (p40) in a coherent way into merged SACM metamodel

  • Key: SACM-77
  • Legacy Issue Number: 16766
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.4.1 EvidenceEvent (abstract) (p40) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    SACM specification duplicates the definition of the class EvidenceEvent (in section 10.1.9 for the class
    diagram EvidenceElements and then again in section 13.4 for the class diagram EvidenceEvents). This
    issue is a duplicate of issue 16736
    See related issues 16773, 16736
    Disposition: Merge

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

Incorporate 10.2.2 EffectiveTime (abstract) (p38) in a coherent way into merged SACM metamodel

  • Key: SACM-72
  • Legacy Issue Number: 16761
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.2.2 EffectiveTime (abstract) (p38) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Timing property of an evidence
    item. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.1.1 Provenance (abstract) (p35) in a coherent way into merged SACM metamodel

  • Key: SACM-67
  • Legacy Issue Number: 16756
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.1.1 Provenance (abstract) (p35) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Remove class 'EvidenceProperty' from Figure 13.1
    Delete class EvaluationAttribute from Figure 13.1
    Change Figure 13.1 Provenance Class Diagram as follows: ,, diagram on p 81 of ptc/2012-06-04>>

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

Incorporate 10.2.5 AtTime (p39) in a coherent way into merged SACM metamodel

  • Key: SACM-75
  • Legacy Issue Number: 16764
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.2.5 AtTime (p39) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a Timing property of an evidence
    item. Any connection to the SACM common classes is accomplished through the element's superclass. No
    other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 10.3.1 Description (p40) in a coherent way into merged SACM metamodel

  • Key: SACM-76
  • Legacy Issue Number: 16765
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 10.3.1 Description (p40) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Remove entire section titled "Descriptions Class Diagram".
    Remove Descriptions class diagram from the model.

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

ARM: Page 21, section 8.3.1

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

    : In the Industrial Press example, the attribute toBeSupported=”True” should be present in element 9, C2.3. This is reflected by the presence of a diamond in the GSN portrayal on page 23, Figure 3.

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

    Replace the content of B.1 with the following
    <?xml version="1.0" encoding="ASCII"?>
    <SACM:Argumentation xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SACM="SACM" xmi:id="0">
    <containsReasoningElement xsi:type="SACM:Claim" xmi:id="1" identifier="C1" description=""
    content="C/S logic is fault free"/>
    <containsArgumentElement xsi:type="SACM:ArgumentReasoning" xmi:id="2" identifier="RC1.1"
    content="Argument by omission of all identified software hazards" describes="5 6"/>
    <containsArgumentElement xsi:type="SACM:ArgumentReasoning" xmi:id="3" identifier="RC1.2"
    content="Argument by satisfaction of all C/S safety requirements" describes="7 8 9"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" xmi:id="4" identifier="IRC1.1"
    description="Identified software hazards"/>
    <containsArgumentElement xsi:type="SACM:Claim" xmi:id="5" identifier="C1.1" description=""
    content="Unintended opening of press (after PoNR) can only occur as a result of component failure"/>
    <containsArgumentElement xsi:type="SACM:Claim" xmi:id="6" identifier="C1.2" description=""
    content="Unintended closing of press can only occur as a result of component failure"/>
    <containsArgumentElement xsi:type="SACM:Claim" xmi:id="7" identifier="C2.1" content="Press
    controls being 'jammed on' will cause press to halt"/>
    <containsArgumentElement xsi:type="SACM:Claim" xmi:id="8" identifier="C2.2" content="Release of
    controls prior to press passing physical PoNR will cause press operation to abort"/>
    <containsArgumentElement xsi:type="SACM:Claim" xmi:id="9" identifier="C2.3" description=""
    content="C/S fails safe (halts on) and annunciates (by sounding Klaxon) all component failures"
    toBeSupported=”TRUE”/>
    <containsArgumentElement xsi:type="SACM:Claim" xmi:id="12" identifier="C2.1.1" content="Failure 1
    of PLC state machine includes BUTTON_IN remaining true"/>
    <containsArgumentElement xsi:type="SACM:Claim" xmi:id="13" identifier="C2.2.1" content="Abort
    transition of PLC state machine includes BUTTON_IN going false"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" xmi:id="10" identifier="S1.1"
    content="Fault tree analysis cutsets for event 'Hand trapped in press due to command error'"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" xmi:id="11" identifier="S1.2"
    content="Hazard directed test results"/> <containsArgumentElement xsi:type="SACM:InformationElement" xmi:id="14" identifier="S2.1"
    description="" content="black box testing"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" xmi:id="15" identifier="S2.2.1"
    content="C/S state machine"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" xmi:id="16" identifier="C1.1.1"
    description="" source="5" TARGET="1"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" xmi:id="17" identifier="C1.1.2"
    source="6" TARGET="1"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" xmi:id="18" identifier="C1.2.1"
    source="7" TARGET="1"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" xmi:id="19" identifier="C1.2.2"
    source="8" TARGET="1"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" xmi:id="20" identifier="C1.2.3"
    source="9" TARGET="1"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" xmi:id="21" identifier="CIRC1.1"
    source="4" TARGET="2"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedEvidence" xmi:id="22" identifier="S1.1"
    source="10" TARGET="5 6"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedEvidence" xmi:id="23" identifier="S1.2"
    source="11" TARGET="5 6"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedEvidence" xmi:id="24" identifier="SC2.1"
    source="14" TARGET="7"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedEvidence" xmi:id="25" identifier="SC2.1.1"
    source="15" TARGET="12"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedEvidence" xmi:id="26" identifier="SC2.2.1"
    source="15" TARGET="13"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" xmi:id="27" identifier="DI C2.1"
    source="12" TARGET="7"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" xmi:id="28" identifier="DI C2.2"
    source="13" TARGET="8"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" xmi:id="29" identifier="AR29"
    source="2" TARGET="16 17"/>
    </SACM:Argumentation>
    Replace the content of B.2 with the following
    <?xml version="1.0" encoding="ASCII"?>
    <SACM:Argumentation xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SACM="SACM" identifier="BSC11">
    <containsArgumentElement xsi:type="SACM:Claim" identifier="Bluetooth secure" content="A bluetooth
    enabled network provides adequate security"/> <containsArgumentElement xsi:type="SACM:Claim" identifier="Availability" content="A bluetooth enabled
    network is adequately available [1] Section 1 para 3"/>
    <containsArgumentElement xsi:type="SACM:Claim" identifier="Access" description="" content="A
    bluetooth enabled network provides adequate control for access to services and data [1] Section 1 para 3"/>
    <containsArgumentElement xsi:type="SACM:Claim" identifier="Confidentiality" content="A bluetooth
    enabled network provides adequate levels of confidentiality [1] Setion 1 para 3"/>
    <containsArgumentElement xsi:type="SACM:Claim" identifier="Integrity" content="A bluetooth enabled
    network provides adequate levels of integrity [1] Section 1 para 3"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" identifier="Context: security policy and
    scenario for use" content="Definitions are required of the intented security policy and the scenario of use for
    the system, including what is regarded as 'adequate'"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" identifier="References" content="[1]
    Bluetooth security white paper 19/4/02"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" identifier="Definition: Availability"
    content="The system is capable of providing requested services to authorised users, in an
    acceptable/defined time"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" identifier="Definition: Access"
    content="Only users permitted by the defined security policy have access to services and data"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" identifier="Define: Confidentiality"
    content="Unauthorised persons cannot intercept and understand information to which they are not
    entitled"/>
    <containsArgumentElement xsi:type="SACM:InformationElement" identifier="Define: Integrity"
    description="" content="Services and data are provided to authorised users as intended and without
    corruption"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" identifier="AC1" source="References"
    target="Bluetooth secure"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" identifier="AC2" source="Context:
    security policy and scenario for use" target="Bluetooth secure"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" identifier="AC3" source="Definition:
    Availability" target="Availability"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" identifier="AC4" source="Definition:
    Access " target="Access"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" identifier="AC5"
    source="Define:Confidentiality" target="Confidentiality"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedContext" identifier="AC6" source="Define
    :Integrity" target="Integrity"/>
    <containsAssertedRelationship xsi:type="SACM:AssertedInference" identifier="AI1" source="Integrity
    Confidentiality Access Availability" target="Bluetooth secure"/>
    <containsArgumentElement xsi:type="SACM:ArgumentReasoning" identifier="Argue over vulnerabilities"
    description="" content="Argue for each security requirement identified in the security white paper"
    describes="AI1"/>
    </SACM:Argument>

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

Hierarchical Collections of Artifacts or Other Items

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

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

    In addition, non-hierarchical structures also have uses

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

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

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

Meaning of HasDependencyOn

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

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

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

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

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

Change name of “Originator”

  • Key: SACM-11
  • Legacy Issue Number: 16311
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    “Originator” is used for not only creating entity(ies), but also Approver and owner and therefore is an inappropriate class name. One possibility is “Actor”.

  • Reported: SACM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Change text in section 15.4, page 100 from
    The Originators Class Diagram defines several elements that represent sources of
    evidence. These elements are subclasses of Object element, so their formal meaning can
    be further defined through a reference to a formal vocabulary or ontology developed by
    the corresponding community of interest.
    into
    The Stakeholders Class Diagram defines several elements that represent People and
    Organizations as they are involved in various statements related to evidence.
    Change section 15.4.1 into the following:
    15.4.1 Stakeholder (abstract)
    Stakeholder is an abstract class that represents a Person or Organization as they
    participate in the statements related to evidence.
    Superclass
    ProjectElement
    Semantics
    The Evidence Metamodel indirectly defines several roles in which Stakeholders are
    involved in evidence statements, such as Provenance statements and Custody statements. These roles include the "source" of an evidence item or an evidence assertion, the
    "supervisor" of an evidence assertion, the "owner" of an evidence item, the 'executor' of
    an evidence event and the "custodian" of an evidence item. This vocabulary facilitates
    exchange of structured statements related to evidence. Additional roles related to the
    affiliation of a Stakeholder in some Organization can be defined by the corresponding
    community of interest. These roles can be used in HasRoleIn statements and exchanged
    informally, as the value of the "role" attribute". On the other hand, formal statements
    related to stakeholders and their roles can be represented using the mechanism of Formal
    Statements.
    Change superclass of Person to 'Stakeholder'
    Change superclass of Organization to 'Stakeholder'
    Section 13.1.2, page 56 change "Originator" to "Stakeholder" (6 occurrences)
    Section 13.1.3 page 56 change "Originator" to "Stakeholder" (6 occurrences)
    Section 13.1.4 page 56-57 change "Originator" to "Stakeholder" (6 occurrences)
    Section 13.4.2 page 62 change "Originator" to "Stakeholder" (4 occurrences)
    Section 13.4.3 page 63 change "Originator" to "Stakeholder" (3 occurrences)
    Section 13.4.4 page 64 change "Originator" to "Stakeholder" (3 occurrences)
    Section 13.4.5 page 65 change "Originator" to "Stakeholder" (3 occurrences)
    Section 13.4.6 page 66 change "Originator" to "Stakeholder" (3 occurrences)
    Section 15.1.2 page 92 change "Originator" to "Stakeholder" (2 occurrences, change the
    role name to 'stakeholder')
    Section 15.1.2 page 93 change "Originator" to "Stakeholder" (1 occurrences)
    Section 15.4.3 page 101 change "Originator" to "Stakeholder" (1 occurrences)
    Change 'Originator' to 'Stakeholder' in section 1.5 of Annex A, page 125
    Change 'Originator' to 'Stakeholder' in section 1.6 of Annex A, page 127
    Rename class Originator to Stakeholder
    Replace Figure 13.1 with the following: figure on page 39 of ptc/2012-06-04 rename rolename 'curator' to 'custodian' (as it is a more general term) in section 13.4.8,
    page 66
    Changes to Figure 13.4 (Custody Properties are described as part of the related
    resolutions 16773 and 16766)
    Change association of the CareOf element 13.4.8, page 66 into
    custodian:Person[1]
    Custodian of the evidence element
    Change occurrences of the text 'curator' to 'custodian' page 14
    Change occurrences of the text 'curator' to 'custodian' in section 13.4.2 IsAcquiredAt
    Change occurrences of the text 'curator' to 'custodian' in section 13.4.3 IsCreatedAt
    Change occurrences of the text 'curator' to 'custodian' in section 13.4.4 IsTransferredTo
    Change occurrences of the text 'curator' to 'custodian' in section 13.4.5 IsRevokedAt
    Change occurrences of the text 'curator' to 'custodian' in section 13.4.6 IsGeneratedAt
    Change occurrences of the text 'curator' to 'custodian' in section 13.4.7 CareOf
    Replace Figure 15.1 and Figure 15.4 (described in the resolutions 16815 and 16816)
    Replace the text 'source' to 'stakeholder' in table on page 15.

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

ARM: Page 16, section 8.2.9

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

    “A Claim that is intentionally declared without any supporting evidence or reasoning (in the recorded Argument) ...”: It is clear how evidence supports a claim (through the AssertedEvidence link). It is less clear how reasoning supports a Claim; the reasoning itself is represented in the “content” attribute of an ArgumentReasoning element, which can be associated with an AssertedInference, which in turn may have the Claim as its target; but this an indirect association.

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

    In section 9.2.9 (Claim Class)
    a) delete first sentence, and replace by "Claims are used to record
    the propositions of any structured Argumentation"
    b) delete the content under the Semantics Sub heading, and replace
    with:
    "
    The core of any argument is a series of claims (premises) that are
    asserted to provide sufficient reasoning to support a (higher-level)
    claim (a conclusion).
    A Claim that is intentionally declared without any supporting
    evidence or argumentation can be declared as being assumed to be
    true. It is an assumption. However, it should be noted that a
    Claim that is not 'assumed' (i.e. assumed = false) is not being
    declared as false.
    A Claim that is intentionally declared as requiring further evidence
    or argumentation can be denoted by setting toBeSupported to be true.
    "

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

ARM: Page 12, Figure 2, Page 15, section 8.2.6 and page 16, section 8.2.9: In Figure 2

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

    Page 12, Figure 2, Page 15, section 8.2.6 and page 16, section 8.2.9: In Figure 2, the attributes “toBeSupported” and “assumed” appear in the same class (Claim), but in the subsequent sections “toBeSupported” appears in ReasoningElement (a super-class of Claim). It seems that these two attributes are related: nothing should be both “assumed” and “to be supported”. This suggests that either:

    a. The “toBeSupported” attribute should be removed on the grounds that any Claim that is not assumed should have support, and if it doesn’t, then it is yet to be supported; or

    b. A single attribute should be used to represent three states: assumed, supported or not-
    yet-supported (alternatively: assumed, needs-no-support and needs-support); or

    c. An invariant should be present to state the constraining relationship between the two attributes described above.
    Note that “toBeSupported” could be construed as a process issue, and therefore better treated as a TaggedValue to make the model less prescriptive.

    Note also that the “toBeSupported” attribute should be constrained to be false in the EvidenceAssertion class, as well as, possibly, the “assumed” attribute

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

    This issue to be resolved by a constraint on the Claim class. See resolution for 17347
    Disposition: Merged

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

ARM Typographical errors

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

    Page 10, section 7.4: “a set of practical modelling approach that”
    Page 15, section 8.2.6, Semantics: “When building an argument it is may be useful”
    Page 17, section 8.2.11: “the asserted inference that connect one or more Claims”
    Page 18, section 8.2.14, Semantics: “This relationship between this claim” – suggest “The relationship”

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

    a) in section 7.4, 2nd para, 2nd sentence, change "approach that
    allows" to "approaches that allow"
    b) in section 9.2.6, sub heading "Semantics", 2nd paragraph, 2nd
    sentence, change "it is may be useful" to "it may be useful"
    c) in section 9.2.11, first sentence, change "that connect one or
    more" to "that connects one or more"
    d) in section 9.2.14, sub heading "Semantics", delete first sentence
    and replace with "Where evidence (cited by InformationItems) exists
    that helps to establish the truth of a Claim in the argument, this
    relationship between the Claim and the evidence can be asserted by
    an AssertedEvidence association."

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

ARM: Page 21, sections 8.3.1 and 8.3.2

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

    There is an inconsistency between these two examples in the way that AssertedRelationships are represented. In the Bluetooth example, the AssertedInference “AI1” is permitted multiple targets, documenting the fact that a single inference connects multiple entities. In the Industrial Press example, however, a similar single interference is represented by multiple AssertedInference elements each with a single target. It is possible that both ways are necessary, because one may wish to associate different ArgumentReasoning elements to different parts of the AssertedRelationship; if this is the case, then is should be made clear.

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

    Updated examples should be provided to reflect the current model. Merged with 16695
    Resolution:
    No further action
    Disposition: Merged

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

InformationAssertion’s and Informational Contents

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

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

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

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

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

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

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

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

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

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

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

SAEM: Page 6, section 7.1

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

    : This comment relates to the sentence “Evidence arguments are reused as opposed to subject domain claims and arguments, which are specific to each domain.” The term “subject claim” has been defined, but not the term “subject domain claim”. Suggest removing the word “domain” in this context.

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

    All references are against document ptc/2012-04-04
    Change text on page 9 from
    In the simplest form, evidence consists of a collection of documents that provide
    evidentiary support to a set of claims. These claims are called subject claims, as the are
    made by an argument related to some selected subject area. We will differentiate subject
    claims from evidence claims, which are claims about the evidence items that help
    establish the exact nature of the evidentiary support they provide to subject claims in a
    crea, comprehensive and defensible way. Evidence arguments are reused as opposed to
    subject domain claims and arguments, which are specific to each subject domain. The
    evidence vocabulary describes claims made about evidence. Evidence vocabulary is
    reused in every argument for various diverse domains.
    into In the simplest form, evidence consists of a collection of documents or records that
    provide evidentiary support to a set of claims. These claims are called subject claims, as
    they are made by an argument related to some selected subject area. We will differentiate
    subject claims from evidence claims, which are the assertions about the evidence items
    that help establish the exact nature of the evidentiary support they provide to the subject
    claims in a clear, comprehensive and defensible way. Evidence claims can be reused as
    opposed to subject claims and arguments, which are specific to each subject area for
    which the assurance case is developed. Thus the SACM Evidence Metamodel defines the
    evidence vocabulary that is used over and over again to make assertions about evidence.
    Evidence vocabulary is reused in every argument for various diverse subject areas.

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

Link to Actual Artifact Represented by Model Element

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

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

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

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

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

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

Confidence as an Assertion

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

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

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

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

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

1..2.14. Need to record modification events and who modified

  • Key: SACM-12
  • Legacy Issue Number: 16312
  • Status: closed  
  • Source: MITRE ( Mr. Samuel Redwine)
  • Summary:

    Modification events need to be record and who modified. No “ModifiedBy” or “RevisedBy” is defined. Is “CreatedBy” supposed to also function to also mean “modified by”? This seems unwise. Likewise a derivedby would seem to be needed if something was derived from multiple sources. What about a copying event?

  • Reported: SACM 1.0b1 — Sun, 5 Jun 2011 04:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    diasgrams in ptc/2012-06-04

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

Incorporate 12.2.5 IsAssociatedWith (p77) in a coherent way into merged SACM metamodel

  • Key: SACM-132
  • Legacy Issue Number: 16824
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.2.5 IsAssociatedWith (p77) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    Discussion:
    This is a leaf class representing a useful Evidence Assertion related to the administrative elements that
    describe evidence collection and evidence evaluation projects. Any connection to the SACM common
    classes is accomplished through the element's superclass. No other changes to this element are anticipated
    according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 12.2.4 RequiresMethod (p77) in a coherent way into merged SACM metamodel

  • Key: SACM-131
  • Legacy Issue Number: 16823
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 12.2.4 RequiresMethod (p77) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The superclass of this element is changed to ProjectProperty due to renaming from AdministrativeProperty
    (see resolution 16818). Otherwise, this is a useful leaf class representing a statement related to managing
    and evaluating evidence in evidence collection projects. No change is required.
    Disposition: Closed, no change

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

Incorporate 11.2.10 Relevance (p55) in a coherent way into merged SACM metamodel

  • Key: SACM-98
  • Legacy Issue Number: 16789
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.10 Relevance (p55) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Reporting level are specified by a separate element <<Enumeration>> Level. Potential
    changes to these values are addressed by a separate issue 16790.
    Disposition: Closed, no change

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

Incorporate 11.2.9 Significance (p55) in a coherent way into merged SACM metamodel

  • Key: SACM-97
  • Legacy Issue Number: 16788
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.9 Significance (p55) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Reporting level are specified by a separate element <<Enumeration>> Level. Potential
    changes to these values are addressed by a separate issue 16790.
    Disposition: Closed, no change

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

Incorporate 11.2.7 Confidence (p54) in a coherent way into merged SACM metamodel

  • Key: SACM-95
  • Legacy Issue Number: 16786
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.7 Confidence (p54) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Confidence level are specified by a separate element <<Enumeration>> ConfidenceLevel.
    Potential changes to these values are addressed by a separate issue 16787.
    Disposition: Closed, no change

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

Incorporate 11.2.6 AccuracyLevel (enumeration) (p53) in a coherent way into merged SACM metamodel

  • Key: SACM-94
  • Legacy Issue Number: 16785
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.6 AccuracyLevel (enumeration) (p53) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 11.3.1 Originality (p57) in a coherent way into merged SACM metamodel

  • Key: SACM-101
  • Legacy Issue Number: 16792
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.1 Originality (p57) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Originality level are specified by a separate element <<Enumeration>> OriginalityLevel.
    Potential changes to these values are addressed by a separate issue 16793.
    Disposition: Closed, no change

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

Incorporate 11.2.12 Strength (p56) in a coherent way into merged SACM metamodel

  • Key: SACM-100
  • Legacy Issue Number: 16791
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.12 Strength (p56) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Unlike similar evidence attributes, the values of this element
    do not use any enumeration classes, but rather are defined as an integer in the range of 0..100
    Any connection to the SACM common classes is accomplished through the element's superclass. No other
    changes to this element are anticipated according to the selected level of the integration.
    Disposition: Closed, no change

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

Incorporate 11.2.5 Accuracy (p53) in a coherent way into merged SACM metamodel

  • Key: SACM-93
  • Legacy Issue Number: 16784
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.5 Accuracy (p53) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Accuracy level are specified by a separate element <<Enumeration>> AccuracyLevel.
    Potential changes to these values are addressed by a separate issue 16785.
    Disposition: Closed, no change

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

Incorporate 11.3.3 Consistency (p58) in a coherent way into merged SACM metamodel

  • Key: SACM-103
  • Legacy Issue Number: 16794
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.3 Consistency (p58) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to evaluation of the justification
    support provided by a certain evidence item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other changes to this element are anticipated according
    to the selected level of the integration.
    The values of Consistency level are specified by a separate element <<Enumeration>> ConsistencyLevel.
    Potential changes to these values are addressed by a separate issue 16795.
    Disposition: Closed, no change

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

Incorporate 11.3.2 OriginalityLevel (enumeration) (p57) in a coherent way into merged SACM metamodel

  • Key: SACM-102
  • Legacy Issue Number: 16793
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.3.2 OriginalityLevel (enumeration) (p57) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 11.2.8 ConfidenceLevel (enumeration) (p54) in a coherent way into merged SACM metamodel

  • Key: SACM-96
  • Legacy Issue Number: 16787
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.8 ConfidenceLevel (enumeration) (p54) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 11.2.11 Level (enumeration) (p55) in a coherent way into merged SACM metamodel

  • Key: SACM-99
  • Legacy Issue Number: 16790
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 11.2.11 Level (enumeration) (p55) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    The common resolution is provided under issue 16845.
    Disposition: Merged

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

Incorporate 7.2.8 DomainAssertion (abstract) (p19) in a coherent way into merged SACM metamodel

  • Key: SACM-46
  • Legacy Issue Number: 16735
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.8 DomainAssertion (abstract) (p19) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    rename section 10.1.8 DomainAssertion (abstract) into FormalAssertion (abstract), page 38
    rename element DomainAssertion on class diagram EvidenceElements into FormalAssertion and change
    Figure 0.1; rename Figure 0.1 into 10.1
    change text on page 39 from
    DomainAssertion is an element of meaning that represents a certain proposition.
    FormalAssertion subclass, introduced in Section 9.1, “Formal Assertions Class
    Diagram,” uses elements of fact model and a formal reference to an SBVR vocabulary to
    represent precise meaning of the assertion. DomainClaim subclass represents an informal
    assertion.
    into
    FormalAssertion is an element of meaning that represents a certain proposition. The
    Assertion element, introduced in Section 9.1, “Formal Assertions Class Diagram,” uses
    the elements of formal sentences and a formal reference to an external SBVR vocabulary
    to represent the precise meaning of the assertion. ReferencedClaim element represents an
    informal assertion/claim.
    Change text on page 43 from
    DomainAssertion and DomainObject on the other hand are representations of some
    meaning rather than of an expression of a meaning (direct or indirect). DomainObject
    may refer to some physical objects as its extent but it may not correspond to any physical
    object whatsoever.
    into
    FormalAssertion and FormalObject on the other hand are representations of some
    meaning rather than an expression of a meaning (direct or indirect). FormalObject may
    refer to some physical objects as its extent but it may not correspond to any physical
    object whatsoever.
    Rename element DomainAssertion into FormalAssertion on Figure 12.1, page 50
    Change superclass of DomainAssertion into FormalElement.
    Change superclass of Assertion into FormalAssertion, page 50
    Change sentence page 51 from
    The stmt property of the DomainAssertion element provides the verbalization of the fact,
    which is the expression of the fact in a natural language.
    into
    The 'content' property of the FormalAssertion element provides the verbalization of the
    assertion, which is the expression of the assertion in the selected natural language.
    Change superclass of DomainClaim into FormalAssertion, page 51 (Note: the DomainClaim element is
    further renamed into ReferencedClaim as the result of the resolution to 16750).
    Change text "DomainAssertion" into "FormalAssertion" , page 69 (2 occurrences)
    Rename element DomainAssertion into FormalAssertion on Figure 14.1, page 69
    Change text "DomainAssertion" into "FormalAssertion" , page 70 (13 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 71 (4 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 72 (4 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 73 (4 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 76 (2 occurrences)
    Rename element DomainAssertion into FormalAssertion on Figure 14.4, page 80
    Change text "DomainAssertion" into "FormalAssertion" , page 81 (1 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 82 (7 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 83 (1 occurrences) Rename element DomainAssertion into FormalAssertion on Figure 14.5 page 83 Change text "DomainAssertion" into "FormalAssertion" , page 85 (16 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 84 (8 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 86 (6 occurrences)
    Rename element DomainAssertion into FormalAssertion on Figure 14.6, page 86
    Change text "DomainAssertion" into "FormalAssertion" , page 87 (6 occurrences)
    Change text "DomainAssertion" into "FormalAssertion" , page 88 (8 occurrences)
    Change Figure 12.1 FormalAssertions Class Diagram as follows: <<diagram on p 62 of ptc/2012-06-04) Modifications to this diagram accumulate all related resolutions

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

Incorporate 7.2.7 DomainObject (abstract) (p19) in a coherent way into merged SACM metamodel

  • Key: SACM-45
  • Legacy Issue Number: 16734
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.7 DomainObject (abstract) (p19) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Change text "DomainObject" into "FormalObject" in header of table at page 15. (1 occurence)
    Rename element DomainObject into FormalObject at diagram Evidence Elements (page 35)
    Change text "DomainObject" into "FormalObject" in section 10.1.7 page 38. (6 occurences)
    Change superclass of FormalObject to "FormalElement" (page 38)
    Change text "DomainObject" into "FormalObject" in section 10.1.8 page 38. (1 occurence)
    Change text "DomainObject" into "FormalObject" in section 11.1.2 page 43. (2 occurences)
    Change text "DomainObject" into "FormalObject" in section 12.1.1 page 50. (1 occurence)
    Rename element DomainObject into FormalObject at diagram Formal Objects (page 50)
    Change text "DomainObject" into "FormalObject" in section 12.1.1 page 51. (1 occurence)
    Rename element DomainObject into FormalObject at diagram Formal Objects (page 53)
    Change text "DomainObject" into "FormalObject" in associations for RoleBinding section 12.1.3 page 52.
    (2 occurences)
    Change sentence (page 52) from:
    From the formal logic perspective, SACM separates DomainObject from
    DomainAssertion. As a consequence, this limits the possibility to represent assertions
    about assertions.
    into
    From the formal logic perspective, SACM distinguishes objects from assertions. As a
    consequence, in order to represent a formal assertion about other assertions the later must
    be objectified, i.e. represented as a FormalObject that refers to the original assertion using
    the element ObjectifiedAssertion.
    Rename chapter 12 title from "Fact Model" into "Formal Statements"
    Change first sentence from the introduction to chapter 12, on page 49 from: The Facts Model defines Evidence Metamodel elements for representing the elements of
    meaning involved in interpretation and evaluation of evidence, and specifically, required
    for precisely representing assertions and claims. These fine-grained evidence elements
    represent individual assertions based on some pre-defined conceptual model.
    into
    Formal Statements provide the mechanism for representing the elements of meaning
    involved in the processes of interpretation and evaluation of evidence, and specifically,
    that are required for precisely representing assertions and claims.
    Change sentence from the introduction to chapter 12, on page 49 from:
    The two fundamental classes of the fact model are Object and Assertion. An Object is an
    object of significance, about which information needs to be known or held. Usually an
    Object corresponds to an Exhibit. Exhibit element emphasized the physical object (an
    SBVR thing element) while an Object emphasized the associated element of meaning. An
    Assertion is a relationship taken as an element of claim that has a distinct, separate
    existence, a self-contained piece of information that can be referenced as a unit. In the
    scope of SBVR, such units of information are called facts, hence the name fact model.
    into
    The two fundamental classes of the Formal Statements are FormalObject and
    FormalAssertion. A FormalObject is an object of significance, about which information
    needs to be known or held. Usually a FormalObject corresponds to an Exhibit where the
    Exhibit element emphasizes the physical object (an instance of the SBVR 'Thing'
    concept) while a FormalObject emphasizes the associated element of meaning. (an
    instance of the SBVR 'Meaning' concept). A FormalAssertion is a relationship between
    evidence elements taken as a new assertion/claim that has a distinct, separate existence; a
    self-contained piece of information that can be referenced as a unit. In the scope of
    SBVR, such units of information are called facts.
    change last part of the paragraph section 12, on page 49 from:
    So, an Assertion element represents a fact involving one or more Objects. A RoleBinding
    element represents an association, linkage, or connection between Objects within the fact
    that describes their role within the fact. RoleBinding represents some semantic
    association between entities of evidence information.
    Fact model elements correspond to some external ontology or vocabulary. Therefore in
    the SACM Evidence Metamodel, the superclasses of Object and Assertion are called
    DomainObject and DomainAssertion respectedly as these elements are part of the
    conceptual model of the Domain for which the assurance case is being developed.
    The SACM Facts package is aligned with the OMG SBVR specification, in particular
    Object can be linked to SBVR IndividualConcept and Assertion can be linked to SBVR
    fact.
    This alignment is important since the Evidence Metamodel can be viewed as a standard
    vocabulary related to descriptions of evidence. SBVR rules can be written using this
    vocabulary to formally describe further properties of evidence information. Such
    vocabulary is presented in Appendix 1.
    The SACM Evidence Metamodel is also aligned with the RDF. Object and Assertion can
    be represented as RDF resources, and RoleBinding - as RDF triples.
    into So, a FormalAssertion element represents an assertion involving one or more
    FormalObjects. A RoleBinding element represents an association, linkage, or connection
    between the FormalObjects that describes their role within the assertion.
    Formal Statements are based on some pre-defined conceptual model related to the area
    for which the assurance case is developed. Such conceptual model can be formally
    represented as an external ontology or vocabulary. In particular the SACM Evidence
    Metamodel allows linking an Object element to an SBVR IndividualConcept or SBVR
    noun concept element and the Assertion element to SBVR fact type element
    The Object element is aligned with the SBVR IndividualConcept or the SBVR noun
    concept while the Assertion element is aligned with the SBVR fact. type. Further, the
    entire SACM Evidence Metamodel is aligned with the OMG SBVR specification, in such
    a way that it describes a standard vocabulary related to descriptions of evidence. SBVR
    rules can be written using this vocabulary to formally describe further properties of
    evidence. The full SBVR vocabulary for evidence is presented as a non-normative Annex
    A.
    Change the first sentence of section 12.1 on page 49 from
    The FormalAssertions class diagram focuses at the Assertion as the key element of the
    fact model underlying the Assurance Case.
    into
    The FormalAssertions class diagram focuses at the Assertion as the key element of the
    formal statements underlying the Assurance Case.
    Rename the word "Fact Model" into "Formal Statements" on Figure 10.1 on page 33.
    Change "Fact Model" into "Formal Statements" in the list of Evidence Metamodel parts on page 33:
    Change paragraph on page 33 from
    The Exhibits part defines the coarse-grained evidence, provided in the form of
    documents and sometimes other exhibits. The Exhibits part also defines the properties of
    exhibits and documents. The Fact Model part defines the fine-grained assertions,
    provided in the form of individual propositions. These propositions use an external
    vocabulary of the domain for which an argument is being provided. The Fact Model part
    defines a subset of an SBVR fact model in the form of atomic formulations based on fact
    types with role bindings to individual concepts. SBVR is not used directly because of
    subtle semantic differences between fact models in linguistic models (SBVR), conceptual
    models and “candidate fact models” involved in evidence collection and evaluation. Fact
    Model elements are used to build the conceptual model underlying the entire assurance
    case. Properties part defines provenance and timing of the evidence items and
    evaluations. Evidence Evaluation part provides means to establish exact nature of the
    evidentiary support that document confer on the domain assertions. The Administration
    part defines a Project element which organizes individual evidence items and evaluations
    into a unit of exchange. The Administrative part also provides several means for
    managing evidence collections projects.
    into
    The Exhibits part defines the key evidence elements in the form of documents and other
    exhibits. The Exhibits part also defines the statements that describe the properties of
    exhibits and documents. The Formal Statements part defines the fine-grained elements
    of meaning involved in the interpretation of evidence and claims, in the form of individual asserted propositions. These propositions use an external vocabulary of the
    domain for which the assurance case is being developed. The Formal Statements part
    defines a subset of an SBVR fact model in the form of atomic formulations based on fact
    types with role bindings to individual concepts. SBVR is not used directly because of
    subtle semantic differences between fact models in linguistic models (SBVR), conceptual
    models and “asserted propositions” involved in evidence collection and evaluation.
    Formal Statement elements are used to build the conceptual model underlying the entire
    assurance case. Properties part defines statements related to custody, provenance and
    timing of the evidence items and their evaluations. Evidence Evaluation part defines
    statements that describe the exact nature of the evidentiary support that a document or
    other exhibit may confer on the assurance case claims. The Administration part defines
    the Evidence Container element which organizes individual evidence items and their
    evaluations into a unit of exchange. The Administrative part also defines statements
    related to managing evidence collection projects.
    Change text on page 53 from
    FormalObject is an element of meaning. FormalObject shall be used in fact model
    underlying the assurance case to represent subjects of assertions, in particular when more
    than one assertion refers to the same subject.
    into
    FormalObject is an element of meaning. FormalObject shall be used in formal statements
    related to the assurance case to represent subjects of assertions, in particular when more
    than one assertion refers to the same subject.
    Change text "fact model" into "formal statements" on page 54 (4 occurrences)
    Change the definition of the "Assertion in Annex A, page 109, from
    A proposition that represents segments of the fact model related to the situation for which
    the body of evidence is collected
    into
    A proposition that is related to the area for which the assurance case is developed
    Change description of Assertion in Annex A, page 110 from
    A formal assertion is a proposition that describes a state of affairs for which the evidence
    is collected. This proposition uses the vocabulary that is imported from the semantic
    community that is involved in the subject field within which the evidence is collected.
    Formal assertions for evidence collection represent (alleged) facts as part of the fact
    model corresponding to the body of evidence. Fact model is an SBVR term.
    into
    A formal assertion is a proposition that describes a state of affairs for which the assurance
    case is developed. This proposition uses the vocabulary that is imported from the
    semantic community involved in the area within which the evidence is collected. Formal
    assertions for evidence collection represent the asserted facts as part of the fact model
    corresponding to the body of evidence. Fact model is an SBVR term.
    Move section 12.2 Formal Objects in front of section 12.1 Formal Assertions.
    Change Figure 12.2 Formal Objects Class Diagram as follows: <<diagram on p 60 of ptc/2012-06-04>> Modifications to this diagram accumulate resolutions to related issues.

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

Incorporate 7.2.4 EvaluationAttribute (abstract) (p18) in a coherent way into merged SACM metamodel

  • Key: SACM-42
  • Legacy Issue Number: 16731
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.4 EvaluationAttribute (abstract) (p18) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Remove section 10.1.4. EvaluationAttribute (Abstract), page 37
    Change sentences (page 37):
    "EvidenceProperty is owned by various Element as appropriate. EvidenceProperty
    represents fundamental properties of the EvidenceElement, as opposed to
    EvaluationAttribute, which represent assertions that potentially can be disputed."
    into
    "EvidenceProperty represents an assertion about a certain fundamental properties of an
    EvidenceElement. Such properties are independent of the particular assurance case, for
    example, the media of a document, the current custodian of the document, or the author
    of a statement. EvidenceProperty is owned by the subject EvidenceElement."
    Remove word EvaluationAttribute from sentence in section 10.1.1 Element (abstract),
    page 35
    Remove word EvaluationAttribute from sentence in section 14.2.7 Confindence, page 74
    Remove word EvaluationAttribute from sentence in section 10.1.8 DomainAssertion,
    page 38
    Remove word EvaluationAttribute from sentence in section 10.1.10 EvidenceEvaluation,
    page 39
    Remove element EvaluationAttribute from class diagram EvidenceElements.
    Remove element EvaluationAttribute from class diagram Provenance. Also remove
    ownership from EvaluationAttribute to Provenance (now achieved through a new
    ownership association from class EvidenceElement). Remove element EvaluationAttribute from class diagram Timing.
    The changes to the diagrams are presented in the related resolution 16729, 16760, 16756

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

Incorporate 7.2.3 EvidenceProperty (abstract) (p17) in a coherent way into merged SACM metamodel

  • Key: SACM-41
  • Legacy Issue Number: 16730
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.3 EvidenceProperty (abstract) (p17) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Change superclass of EvidenceProperty to 'EvidenceAssertion'
    Change description of the EvidenceProperty element from
    EvidenceProperty is an abstract class that represents various parts of the primary
    evidence elements.
    into
    EvidenceProperty represents various statements related to the fundamental properties of
    evidence elements.
    Change the semantics subsection of EvidenceProperty from EvidenceProperty is owned by various Element as appropriate. EvidenceProperty
    represents fundamental properties of the EvidenceElement, as opposed to
    EvaluationAttribute, which represent assertions that potentially can be disputed.
    EvidenceProperty involves one or more subjects, specified either as attributes or the
    associations of the EvidenceProperty element. Each EvidenceProperty represents a
    relationship between the Element that owns it and its subject.
    into
    EvidenceProperty is owned by subject Evidence Element. EvidenceProperty is a
    statement that represents fundamental properties of the EvidenceElement.
    EvidenceProperty involves one or more objects, specified either as attributes or the
    associations of the EvidenceProperty element. Each EvidenceProperty represents a
    relationship between the subject Evidence Element that owns it and the corresponding
    objects.
    Add new section 10.2 EvidenceAssertion Class Diagram
    Add description of EvidenceAssertion section 10.2.1 as follows:
    10.2.1. EvidenceAssertion (abstract)
    EvidenceAssertion represents various statements about the evidence items, such as
    documents and exhibits, and their relations to the subject area claims.
    Evidence Assertions are defined within the Evidence Metamodel and include the
    following categories:
    Statements related to various essential properties of Evidence Items
    Properties of Documents as they are related to the quality of the evidentiary support that
    may be offered by these documents, such as Primary or secondary, original or derived,
    Consistency, Completeness, Accuracy.
    Statements related to the Custody, Provenance and Timing of Evidence Elements
    Attributes of the evidentiary support, such as Direct or indirect support, Relevance,
    Confidence, Strength, Significance.
    Interpretation of Evidence: what an evidence item "Is", what it "means."
    Nature of the evidentiary support: Supports, Challenges.
    Observations and Resolutions.
    Standard of Proof to which the evidence is evaluated.
    Superclass
    EvidenceElement
    Semantics
    EvidenceAssertion is an abstract class that represents various assertions related to
    evidence elements defined in the Evidence Metamodel. More detailed semantics is
    provided by the concrete subclasses of EvidenceAssertions.
    move section 10.1.3 EvidenceProperty to section 10.2
    move section 10.1.10 EvidenceEvaluation to section 10.2.
    Add Figure EvidenceAssertions class diagram to section 10.2 as follows: Note: This Figure accumulates related resolutions 16730, 16736, 16773, 16737, 16740, 16705, 16756,
    16760

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

Incorporate 7.2.6 Meaning (abstract) (p18) in a coherent way into merged SACM metamodel

  • Key: SACM-44
  • Legacy Issue Number: 16733
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.6 Meaning (abstract) (p18) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Change text on page 13 into:
    The key concept of evidence is a Document that provides evidentiary support to some Subject claim.
    Document is collected during the course of Evidence collection process. Usually a Document is interpreted
    as a description of a certain state of affairs involving several objects in the subject area (for which certain
    claims are being made). Subject claims are assertions related to the state of affairs in the subject area.
    Evidence evaluation (as opposed to Evidence collection) involves certain specific Claims about Evidence,
    in particular, Evidence Relation describes the nature of the evidentiary support between a Document and a
    Subject Claim, or the interpretation of a Document as a meaning. Evidence Relation involves certain
    attributes that qualify relations between Documents and Subject Claims, or Documents and meanings.
    Evidence Observations describe conflicts between evidence relations. Evidence Resolutions record
    judgments that resolve conflicts in evidence relations. Note, that Documents and Subject Claims simply
    exist. A Document becomes Evidence only insofar as it is claimed to provide evidentiary support to a
    certain Subject Claim.
    remove Figure 6.1
    remove the following text on page 12, before the Figure 6.1: "Relationships between the key elements of
    evidence metamodel are illustrated in Figure 6.1"
    add note to element Meaning on page 105
    Note: Meaning is represented by SACM Formal Element
    Rename element Meaning to FormalElement on diagram Evidence Elements.
    Change section 10.1.6 Meaning , page 38, from:
    10.1.6 Meaning (abstract)
    Meaning is an abstract class that represents any elements of meaning that are associated
    with objects presented as evidence or otherwise involved in the evidence collection.
    Superclass
    EvidenceItem
    Semantics
    Meaning is an element of meaning that represents a certain individual concept, a noun
    concept, verb phrases and claims. Two subclasses of Meaning are DomainObject,
    representing noun concepts, and DomainAssertion, representing verb concepts and
    claims.
    into 10.1.6 FormalElement (abstract)
    FormalElement is an abstract class that represents any elements of meaning that are
    associated with objects presented as evidence or otherwise involved in the evidence
    collection.
    Superclass
    EvidenceItem
    Semantics
    FormalElement is an element of meaning that represents a certain individual concept, a
    noun concept, verb phrases and propositions. Two subclasses of FormalElement are
    FormalObject, representing noun concepts, and FormalAssertion, representing verb
    concepts and propositions.
    Change sentence on page 80 from:
    EvidenceInterpretation is an abstract class that represents a relation between one
    EvidenceElement and one Meaning element.
    into
    EvidenceInterpretation is an abstract class that represents a relation between one
    EvidenceElement and one FormalElement.
    Change sentence on page 81 from:
    EvidenceInterpretation is a unit of information generated during evidence evaluation. It
    represents a relationship between an EvidenceItem and a Meaning object that is asserted
    during the evidence evaluation.
    into
    EvidenceInterpretation is a unit of information generated during evidence evaluation. It
    represents a relationship between an EvidenceItem and a FormalElement object that is
    asserted during the evidence evaluation.
    Change sentence on page 37 from
    EvidenceItem represents objects that are collected as evidence. The two subclasses of
    EvidenceItem are Exhibit, representing physical objects presented as evidence, and
    Meaning, which represents associated elements of meaning, such as concepts and claims.
    into
    EvidenceItem represents objects that are collected as evidence. The two subclasses of
    EvidenceItem are Exhibit, representing physical objects presented as evidence, and
    FormalElement, which represents associated elements of meaning, such as concepts and
    propositions/claims.
    Diagram modification related to this resolution are presented at the related resolution 16729

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

Incorporate 7.2.5 EvidenceItem (abstract) (p18) in a coherent way into merged SACM metamodel

  • Key: SACM-43
  • Legacy Issue Number: 16732
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.5 EvidenceItem (abstract) (p18) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    No change is required.
    Disposition: Closed, no change

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

Incorporate 7.2.9 EvidenceEvent (abstract) (p20) in a coherent way into merged SACM metamodel

  • Key: SACM-47
  • Legacy Issue Number: 16736
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.9 EvidenceEvent (abstract) (p20) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    move section 13.4 EvidenceEvent as the second section 13.2 in chapter 13 (after Custody,
    see resolution 16773).
    Change description of EvidenceEvents class diagram (section 13.4, page 60) from
    The EvidenceEvents Class Diagram focuses at the Events that determine the lifecycle of
    the evidence element, as well as the custody properties of the evidence element.
    EvidenceEvents allow storing the entire Chain of Custody of an evidence element.
    EvidenceEvents set the context for the time stamps and custody properties.
    EvidenceEvents are properties of owner object.
    into
    The EvidenceEvents Class Diagram describes evidence statements related to the Events
    that determine the lifecycle of an evidence element.. EvidenceEvents set the context for
    additional timing, provenance and custody properties associated with each event of the
    subject evidence element. Therefore EvidenceEvents allow representing the entire Chain
    of Custody of the subject evidence element. EvidenceEvents statements are owned by the
    subject evidence element.
    Change the text describing the EvidenceEvent (section 13.4.1, page 61) into the
    following: EvidenceEvent represents statements related to the events in the lifecycle of an
    EvidenceItem. The lifecycle of an EvidenceItem is determined by several events, such as
    Creation, Acquisition or Derivation of an EvidenceItem, Transfer of an EvidenceItem,
    Evaluation of an EvidenceItem and Revocation of EvidenceItem. An EvidenceEvent
    statement describes a certain characteristic of the subject EvidenceItem. More complex
    Event statements can be constructed using the EvidenceEvent element by adding some
    properties that describe the detail of the event, such as the Provenance, Timing, and
    Custody. The entire chain of custody of an evidence item can be established by analyzing
    the EvidenceEvents of the item. Concrete evidence events are defined as subclasses of the
    EvidenceEvent element.
    Superclass
    EvidenceProperty
    Semantics
    EvidenceEvent represents statements related to the lifecycle events of the subject
    EvidenceItem. Further detail of the event are provided by the EvidenceProperty elements
    owned by the EvidenceEvent. The set of EvidenceEvent owned by an EvidenceItem
    establishes the chain of custody for the EvidenceItem.
    The EvidenceEvent element is an abstract class that establishes a relationship between the
    subject evidence item and the particular event description with its associated
    characteristics, defined by a particular concrete subclass of the EvidenceEvent element
    and its owned properties, such as CustodyProperty, Provenance, and TimingProperty.
    move sections 13.4.1-13.4.6 to section 13.2 EvidenceEvent
    remove class EvidenceProperty, CustodyProperty, CareOf, AtLocation, UsingProcess,
    Person, Organization and CollectionMethod from class diagram EvidenceEvent (and
    move them to new class diagram Custody, see resolution 16773).
    Change Figure 13.4 EvidenceEvent Class Diagram as follows: ,, figure on p 64 of ptc/2012-06-04

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

Incorporate 7.2.2 EvidenceElement (abstract) (p16) in a coherent way into merged SACM metamodel

  • Key: SACM-40
  • Legacy Issue Number: 16729
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.2 EvidenceElement (abstract) (p16) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Change superclass of EvidenceElement, section 10.1.2, page 36 from Element to ModelElement.
    Remove entire subsection Associations (page 36) as follows:
    "
    Attributes
    Associations
    • id:String Globally unique identifier of an SACM Evidence Metamodel evidence
    element.
    "
    Add the following to the Associations subsection (page 36):
    custody:CustodyProperty[0..*] Custody properties of the EvidenceElement
    Delete the following from the Associations subsection (page 36):
    description:Description[0..*] Description of the EvidenceElement (prose)
    Delete the entire constraints subsection (page 36)
    "Constraints
    • id is a string that has the following structure:
    • url of the organization that created the evidence element the name of the Evidence
    Metamodel class of the evidence element the unique number
    id is globally unique, i.e., no two evidence elements of the same type produced by the
    same organization shall have the same number.
    "
    show title attribute in document class on diagram EvidenceElement.
    Rename Figure 0.1 into 10.1 and Change Figure 10.1 as follows: Note: the changes to the diagram accumulate several related resolutions: 16729, 16730,
    16731, 16732, 16736, 16766, 16737, 16740, 16705, 16733.

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

Incorporate 7.2.1 Element (abstract) (p16) in a coherent way into merged SACM metamodel

  • Key: SACM-39
  • Legacy Issue Number: 16728
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.1 Element (abstract) (p16) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    delete the section 10.1.1. Element (abstract).
    Change the description of the EvidenceElement (section 10.1.2, page 35, from:
    EvidenceElement is an abstract class that represents the primary elements of the Evidence
    Metamodel.
    into:
    EvidenceElement class is the root element of the SACM Evidence Metamodel. All other
    classes in the SACM Evidence Metamodel extend EvidenceElement. The main subclass
    of the Element is EvidenceItem, which defines the primary elements of the Evidence
    Metamodel. Other elements represent various secondary elements and dependent parts of
    other evidence elements. The following elements are direct subclasses of
    EvidenceElement: EvidenceItem, EvidenceAssertion, and ProjectElement.
    Change the 1st sentence of the semantics section into following:
    EvidenceElement class is an abstract class that represents any element of the SACM
    Evidence Metamodel. Every class of the SACM Evidence Metamodel extends
    EvidenceElement directly or indirectly (through other classes).

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

Incorporate 8.1.1 Exhibit (p 21) in a coherent way into merged SACM metamodel

  • Key: SACM-49
  • Legacy Issue Number: 16738
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.1 Exhibit (p 21) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other change is anticipated.
    Disposition: Closed, no change

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

Incorporate 7.2.10 EvidenceEvaluation (abstract) (p20) in a coherent way into merged SACM metamodel

  • Key: SACM-48
  • Legacy Issue Number: 16737
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 7.2.10 EvidenceEvaluation (abstract) (p20) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    Change superclass of EvidenceEvaluation from Element to EvidenceAssertion
    Change the text in chapter 14, page 69 from
    Evaluation of Evidence includes the activities of making certain assertions about
    evidence items and their relation to domain claims.
    Evidence Assertions are defined within the Evidence Metamodel and include the
    following categories:
    Quality Attributes of Documents, such as Primary or secondary, Document: original or
    derived, Consistency, Completeness, Accuracy.
    Quality Attributes of Evidentiary Support, such as Direct or indirect, Relevance,
    Confidence, Strength, Significance.
    Interpretation of Evidence: what an evidence item "Is", what is "means."
    Nature of Evidentiary support: Supports, Challenges.
    Observations and Resolutions.
    Standard of Proof to which evidence is evaluated.
    Into
    Evaluation of Evidence involves making certain assertions about the evidence items and
    their relations to the subject area claims.
    Evidence Assertions are defined within the Evidence Metamodel and include the
    following categories:
    Properties of Documents as they are related to the quality of the evidentiary support that
    may be offered by these documents, such as Primary or secondary document, original or
    derived document, Consistency, Completeness and Accuracy of the document. These
    properties are independent on the assurance case for which the evidence is collected. Attributes of the evidentiary support, such as Direct or indirect support, Relevance,
    Confidence, Strength, and Significance.
    Interpretation of Evidence: what an evidence item "Is", what it "means."
    Nature of the evidentiary support: Supports, Challenges.
    Observations and Resolutions.
    Standard of Proof to which the evidence is evaluated.
    Change Figure 14.2 EvidenceAttributes <<figure on p 66 of ptc/2012-06-04

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

Incorporate 8.1.5 IsPartOf (p25) in a coherent way into merged SACM metamodel

  • Key: SACM-53
  • Legacy Issue Number: 16742
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.5 IsPartOf (p25) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Statement related to a property of an evidence item.
    Any connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

Incorporate 8.1.4 HasElectronicSource (p24) in a coherent way into merged SACM metamodel

  • Key: SACM-52
  • Legacy Issue Number: 16741
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.4 HasElectronicSource (p24) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Assertion related to a property of a evidence item. Any
    connection to the SACM common classes is accomplished through the element's superclass. No other
    change is anticipated.
    Disposition: Closed, no change

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

Incorporate 8.1.3 Exhibit Property (p23) in a coherent way into merged SACM metamodel

  • Key: SACM-51
  • Legacy Issue Number: 16740
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.3 Exhibit Property (p23) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    All references are against document ptc/2012-04-04
    change superclass of element IsBasedOn from DocumentProperty to ExhibitProperty (page 46)
    change rolename of ExhibitProperty from 'exhibitProperty' to 'property' (page 42)
    Rename class diagram Exhibits (Figure 11.1) into ExhibitProperties Class Diagram
    rename Figure 11.1 to ExhibitProperties class diagram
    rename chapter 11 to Exhibit Properties
    rename section 11.1 to ExhibitProperties Class Diagram
    move section 11.1.1 Exhibit and 11.1.2 Document from section 11.1 to section 10.1
    move the introductory text to Exhibits to the description of EvidenceItem.
    see also related resolution 16705.
    Change Figure 11.1 as follows: <<figure on p 67 of ptc/2012-06-04

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

Incorporate 8.1.2 Document (p22) in a coherent way into merged SACM metamodel

  • Key: SACM-50
  • Legacy Issue Number: 16739
  • Status: closed  
  • Source: Adelard LLP ( Luke Emmet)
  • Summary:

    Incorporate 8.1.2 Document (p22) in a coherent way into merged SACM metamodel

  • Reported: SACM 1.0b1 — Tue, 29 Nov 2011 05:00 GMT
  • Disposition: Resolved — SACM 1.0b2
  • Disposition Summary:

    This is a leaf class representing a useful Evidence Item. Any connection to the SACM common classes is
    accomplished through the element's superclass. No other change is anticipated.
    Disposition: Closed, no change

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