right now the Name of a model element can not be a multi-string... which it should be
There is no reason to have both LangString and ExpressionLangString, given the constraint on ExpressionLangString that the expression and the content cannot both have values. If you insist on having both, have a common base class that includes only the 'lang' attribute - then LangString can have the content field and ExpressionLangString can have the 'expression' field.
There is no reason to have both LangString and ExpressionLangString, given the constraint on ExpressionLangString that the expression and the content cannot both have values. If you insist on having both, have a common base class that includes only the 'lang' attribute - then LangString can have the content field and ExpressionLangString can have the 'expression' field.
Generally: This document is replete with grammatical errors. Has someone run a grammar checker on it?
Specifically:
In addition, the 'Attributes' section for 'ExpressionLangString' states:
"expression:Terminology::ExpressionElement[1] (composition) – a reference"
The field is either a reference or a composition - but not both. Pick one.
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.
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.
The original proposal of an informative uml profile needs to be made normative and covered by a compliance point.
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.
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.
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.
Some how Figure 8.1 was relabeled with the same label as Figure 7.2
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.
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.
Correct content of emof and uml profile files
Pulled intended content out of html encoded material.
mistakenly created
This issue is extraneous and should be closed
This issue was accidentally created and should be removed.
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.
Graphical layout formats out of scope of SACM standard
The requested functionality is out of scope of the SACM work.
To allow for more consistent and direct use of SACM concepts in tools and other environments, a SACM UML profile is needed.
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.
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.
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.
For SACM 2.3 the list of companies involved, their respective copyrights, and a sentence about the scope of SACM 2.3 is needed.
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.
Section 6.1 is referring to the wrong version of SACM.
Referring to wrong version of SACM
Update to refer to 2.1.
Typo in 11.7 ArguementAsset (abstract) first line of section.
Typo in text of 11.7
Replace "bsse" with "base".
Typo first line of OCL, there is an extra space.
Typo in OCL
Typo first line of OCL, there is an extra space in the word AssuranceCasePackage.
In Section 3.1 Normative References, 3 of the references have been updated and the new versions should be cited.
Section 3.1 Normative References
3 of the references have been updated and the new versions should be cited.
Resolution: Shown in pdf, described below.
Replace:
ISO/IEC 15026-1:2013 Systems and software engineering - Systems and software assurance - Part 1: Concepts and vocabulary, 2013. <https://www.iso.org/iso/catalogue_detail.htm?csnumber=62526>
With:
ISO/IEC 15026-1:2019 Systems and software engineering - Systems and software assurance - Part 1: Concepts and vocabulary, 2019. <https://www.iso.org/standard/73567.html>
Replace:
OMG UML 2.5 Infrastructure Specification formal/15-03-01. <https://www.omg.org/spec/UML/>
With:
OMG UML 2.5.1 Infrastructure Specification formal/17-12-05. <https://www.omg.org/spec/UML/>
Replace:
OMG Meta-Object Facility (MOF) version 2.5 formal/2015-06-05. <https://www.omg.org/spec/MOF/>
With:
OMG Meta-Object Facility (MOF) version 2.5.1 formal/19-10-01. <https://www.omg.org/spec/MOF/>
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.
ID for graphical elements - should be name not ID
The figures mistakenly labelled with ID are revised to use name.
The "dot" in SACM 2.1's graphical notations is too small for tool implementation
Graphical Notation Dot too small to work in tools.
Increase "dot" size and update Figures.
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.
Remove duplicate text
Typo - phrase accidentally repeated.
Missing "or counter argument" after "counter evidence" in 11.11 Semantics, last line of page.
Missing words in 11.11
Insert missing “or counter argument" after "counter evidence" in 11.11.
Missing line break before "needsSupport" in Enumeration Litterals of 11.8.
Missing line break in 11.8
Add line break before "needsSupport" to separate terms.
In “Enumeration Litterals” of 11.8
“Litterals” mis-spelled.
Typo in text of 11.8
“Litterals” mis-spelled.
In 11.9 Semantics, misspelling – “with in” should be “within”
Typo in 11.9
Replace “with in” with “within”
Wrong package name used in second sentence of 9.3.
Wrong package name used in second sentence of 9.3.
Need to correct package name
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.
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
Section 3.2 Non-normative References, 1 of the references have been updated and there is one new reference to add.
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.
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.
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.
The relationship and use of bindings and interfaces are not well described for packages.
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.
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.
Confusing use of the term property
On pages 19 and 30, change the word “property” to “feature”.
Definition of 11.5 ArgumentPackageBinding is unclear. More details needed to make it understandable and the constraints need enhancement to convey model details.
Definition is unclear
Revised to expand description and fixed label in constraints as well as added constrain language.
Need to revise this section to reflect the new version.
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.
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.
Defer for further discussion
Exchangeable graphic notations are an interesting addition to the SACM exchange standard for assurance cases but need more discussion.
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!
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.
The description and semantics of AssertedContext are confusing in their discussion of interpretation and scoping.
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.
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.
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.
JS18 - http -> https throughout for omg.org (all URIs)
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.
JS19 - Why MOF 2.0, and not 2.5.1? If no technical reason, update to 2.5.1.
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.
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?
PNG images
new figures were generated for previous png figures - will be attached to the new report and used in the updated specification.
JS16 - Filename for SACM21-31/!!.14 - A2B.pdf - I assume this should be 11.14… that’s going to wreak havoc with some filesystems.
JIRA file names for files included in Report
Passed on to Mariano for resolution - no change in specification or issue resolution materials.
JS15 - SACM21-1 through 13 were unnecessary to add to archive and muddied the waters. One for Mariano?
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.
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.
showing changes from different issue
removed edit notations from a different issue from 11.11-deletion pdf
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.
multiplicity change missing figures
included figures in pdf of changes
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.
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.
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]
Date or date in 12.11
resolve difference
JS7 – In 8.6 ModelElement (abstract), under Associations, need a newline between implementationConstraint and description.
missing newline
added newline to address comment
JS6 – In 8.2 SACMElement (abstract), under Attributes, isCitation and isAbstract do not match multiplicity in Figure 8.1
multiplicity in figure and text do not match
figure is correct - fix text
JS5 - In 6.2 Acknowledgements, there is an extra trailing bullet.
fix trailing bullet
line after bulleted list has an empty bullet - removed.
JS4 - In 3.2 Non-normative References, SPMS is at 1.2, update doc number to formal/17-11-01.
updating SPMS version reference
In 3.2 Non-normative References, SPMS reference updated.
JS3 - Typo on pdf pg 10: Issues: hhttp in URI -> https
hhttp to https
typo in url and need to move to https
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).
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.
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.
Arguement-Argument
Correct spelling now shown in the track changes and clean specifications - see RB2-Arguement-Argument.pdf
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.
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.
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.
To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.
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.
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.
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.
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.
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.
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.
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.
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.
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.
There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.
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.
Need to add internationalization of the languages used so that elements can be described using multiple languages
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.
In packages (e.g. ArgumentPackage, TerminologyPackage), atomic references are too complicated.
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.
There is currently no direct mechanism to support internationalization in SACM content.
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.
In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.
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.
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.
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.
Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.
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.
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?]
A and B are mistakenly swapped in the specification text
Need to revise labels in section 11.14 to correctly describe the functionality.
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.
Whether for that
The observation is correct - replacing "That" with "Whether" in Section 11.13
The section title "Literals" is misspelled.
Mistakenly opened issue on spelling mistake.
This is correct in specification - was looking at wrong version.
Terminology misspelled as "Termonology" in Section 2.5
Again was looking at the wrong version of the SACM file
The term is correctly spelled - no change needed.
Mistake in element name – remove “Model” from ArtifactModel::ArtifactPackage
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
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.
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.
There is no discussion of the terminology model’s role in SACM.
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.
The Artifact title is misleading label for this portion of the scope description, this section is actually is about Evidence.
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.
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.
Duplicative request for removal of constraint from 11.11
Addressed in ballot 3.
The multiplicity of +target should be 1 (target:ArgumentAsset[1]).
In 11.13 the +target should have multiplicity of 1
Update text, diagrams, and emof model.
The constraint statement in 11.11 is unnecessary since there is no longer an assumed nor a toBeSupported attribute in the standard
remove unnecessary constraint statement in 11.11
There is no longer an assumed nor a toBeSupported attribute in the standard, can remove the constraint.
Shouldn't have a compliance point for the Concrete Syntax as part of this revision.
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.
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]
Date or date in 12.9
aligned text
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]
Date or date in 12.7
align spelling
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.
address discrepancy between text and figure
Figure is correct - made text change
JS1 - Confirm URI on title page: http://www.omg.org/spec/SACM/190235/emof.xml
http -> https
change url on title page
The specification relates to ArtifactPackage, but the description of the package describes it as ArgumentPackage.
Element name mistake in 12.2
In section 12.2 ArtifactPackage the element is mistakenly named ArgumentPackage - should be ArtifactPackage - correct in model.
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.
Fixed within a day of being reported
This broken link was fixed within a few days of being reported.
The association `value` is shown as LangString[1..*], but the semantics describe it as a list of ExpressionLangString, not LangString.
ExpressionLangString should be LangString
Correct element name and change criteria from "must" to "should"
The link "http://www.goalstructuringnotation.info/sacm-examples
Structured" leads to a "Site Unavailable" page.
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.
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).
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.
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.
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
The word contained is spelled as"containined"
Mistakenly opened issue on spelling mistake.
Word correctly spelled - was looking at the wrong version of SACM.
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.
deferred
Use “artifact” instead of “artefact” is needed to make incorporation of SACM into The Open Group standards more practical.
deferred
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.
deferred
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.
deferred
In Argumentation package, AssertedRelationship should directly express if it is a counter relationship.
deferred
There is currently no direct mechanism to support internationalization in SACM content.
deferred
In packages (e.g. ArgumentPackage, TerminologyPackage), atomic references are too complicated.
deferred
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.
deferred
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.
deferred
To support multiple stakeholder views and purposes a mechanism for associating SACMElements is needed.
deferred
Need to add internationalization of the languages used so that elements can be described using multiple languages
deferred
There are unnecessary differences between the Assurance Case, Terminology, Argument, and Artifact package definitions, interfaces, and bindings.
deferred
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.
deferred
In making support for the Terminology Package optional a compliance point for those that want to support the Terminology Package was mistakenly left out.
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.
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.
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
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”.
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.
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.
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.
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.
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.
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."
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.
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
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.
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.
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.
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”.
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.
We are missing an SBVR vocabulary for ARM (authors view - this is work someone else
to do, maybe close/postpone)
Addressed by harmonization to create SACM 2.0.
We are no longer using SBVR.
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.
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.
Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel
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).
There is no support for patterning, which is found to be useful current practice.
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.
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)
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.
combined standard should include a vocabulary for talking about standards of proof
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).
The SBVR vocabulary for evidence in Annex A is missing several definitions.
Addressed by harmonization to create SACM 2.0.
SACM 2.0 is no longer using the SBVR approach.
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
Spurious associations removed
These spurious associations have been removed and are no longer present in SACM.
The superclass of ArgumentElement is shown as ModelElement in the text but as ArgumentationElement in figure 9.1 on page 27.
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.
Issue: No approach to allowing Structured Expression of Claims within ARM
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.
No method of handling confidence in the ARM
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).
Integration Issue: Inconsistent approaches to handling counter argument and evidence. Both standards have evaluation mechanisms (e.g. refuting, rebutting mechanisms)
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.
Integration Issue: Inconsistent terminology
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.
Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel
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.
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.
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.
Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...
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.
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.
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.
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
Typo has been removed
This spurious typo has been removed and is no longer present in SACM.
All associations need to be labeled with a verb
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.
combined standard should include a vocabulary for talking about standards of proof
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.
Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...
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.
There is no support for patterning, which is found to be useful current practice.
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.
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.
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.
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)
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.
Issue: No approach to allowing Structured Expression of Claims within ARM
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.
No method of handling confidence in the ARM
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.
Integration Issue: Inconsistent approaches to handling counter argument and evidence. Both standards have evaluation mechanisms (e.g. refuting, rebutting mechanisms)
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.
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.
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.
Integration Issue: Overlapping scope
Remove duplicate
Delete Section 9.1.9 EvidenceAssertion from the Argumentation section.
Rename all occurrences of Assertion in the Evidence section to EAssertion.
Integration Issue: Inconsistent terminology
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.
Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel
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.
Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel
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.
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.
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.
One may want to state the context in which an AssertedRelationship holds. At present, the invariants on AssertedContext disallow this.
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).
: 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”.
*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))
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.
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?
Various evidence properties and attributes represent 'statements' about evidence. Specification needs to be systematically edited to introduce this language.
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.
The SBVR vocabulary for evidence in Annex A is missing several definitions.
Deferred as still valid for SACM
This issue is being deferred to a future RTF due to the lack of time.
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.
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.
We are missing an SBVR vocabulary for ARM (authors view - this is work someone else
to do, maybe close/postpone)
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.
In Section 12.3.1 "facctype" should be "facttype"
facttype" is correct in the formal version
facttype" is correct in the formal version – mistake was in ptc-12-06-06.pdf version
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”
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”
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.
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.
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.
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.
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?
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”.
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.
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.
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.
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).
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"
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>
Class ProvidesContext Figure 14.3 already inherits the 'subject' association from the EvidenceInterpretation element.
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>>
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.
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>>
Integration issue: introductory text should cover SAEM introductory material
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)
we need a common route to support instance packaging. Proposal is to use “Assurance
repository” as the main packaging element.
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.
Using the term 'Argument' as the container for the "Claims-Argument-Evidence" aspect of ARM is confusing as people expect to see Claim first.
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.
Some of the evidence evaluation attributes were allowed to be applied to exhibit, rather than the relation between exhibit and evidence assertion
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
Lack of agreement in the attribute types for some of the evidence evaluation subtypes - e.g. confidence 0..100 as integer
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.
"
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.
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.
exchanged model instances should indicate which compliance points have been satisfied
This is achieved by observing the top element. See related resolution 16855.
Disposition: Closed, no change
The detailed enumerated attributes in SAEM need a corresponding location in SACM.
Choosing to use these could be defined using a seperate compliance point.
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.
If AssertedRelationships are genuinely Assertions then they should be subtypes of Assertion
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
No AssuranceCase Element in either ARM or SAEM - necessary for a Structured Assurance Case Metamodel
This issue has been resolved due to resolutions of related issues 16855.
Disposition: Merged
Metamodel packaging should broadly align with ARM/SAEM elements. Will support
understandability
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
Combined specification should have routes and guidance broadly corresponding
to ARM and SAEM, and supports ease of adoption for ARM.
This resolution has been merged with 16857.
Disposition: Merged
counter evidence and challenge should be better modelled by a polarity attribute on the relation (AB comment)
No Data Available
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.
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>>
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.
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>>
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.
This issue is related to a now obsolete intermediate model of ARM and is not longer
applicable.
Disposition: Closed, no change
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?
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
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.
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"
Need to clarify usage of “nature of dependency” to indicate this is not for evidential or argumentation relations
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
(a missing issue) to motivate link groups
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
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
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>>
The frontispiece sections (introduction, background, scope etc) needs to be edited to
reflect integration. Suggest to break an issue for each sections.
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".
Integration Issue: Combined scope needs to include original scopes, and any emergent scope
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
Integration issue: An overall goal is to integrate the ARM and SAEM specifications into SACM in a coherent way.
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
Incorporate 12.5.1 EvidenceRequest (p82) in a coherent way into merged SACM metamodel
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
Incorporate 12.4.4 HasRoleIn (p81) in a coherent way into merged SACM metamodel
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
Incorporate 12.3.2 Service (p79) in a coherent way into merged SACM metamodel
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
Incorporate 12.3.1 CollectionMethod (abstract) (p78) in a coherent way into merged SACM metamodel
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
Incorporate 12.4.1 Originator (abstract) (p80) in a coherent way into merged SACM metamodel
No Data Available
Incorporate 12.3.4 Tool (p79) in a coherent way into merged SACM metamodel
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
Incorporate 12.2.6 DependsOn (p77) in a coherent way into merged SACM metamodel
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
Incorporate 12.4.3 Organization (p81) in a coherent way into merged SACM metamodel
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
Incorporate 12.4.2 Person (p80) in a coherent way into merged SACM metamodel
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
Incorporate 12.3.3 Method (p79) in a coherent way into merged SACM metamodel
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
Incorporate 12.1.3 StandardOfProof (enumeration) (p73) in a coherent way into merged SACM metamodel
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)".
Incorporate 12.1.2 Package (p72) in a coherent way into merged SACM metamodel
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
Incorporate 12.1.1 AdministrativeElement (abstract) (p71) in a coherent way into merged SACM metamodel
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.
Incorporate 11.7.1 EvidenceGroup (p69) in a coherent way into merged SACM metamodel
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
Incorporate 12.1.4 AdministrativeProperty (abstract) (p74) in a coherent way into merged SACM metamodel
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:
Incorporate 11.6.2 Negates (p67) in a coherent way into merged SACM metamodel
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
Incorporate 11.6.1 EvidenceResolution (abstract) (p66) in a coherent way into merged SACM metamodel
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
Incorporate 11.6.4 Resolves (p68) in a coherent way into merged SACM metamodel
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
Incorporate 11.6.3 Refutes (p67) in a coherent way into merged SACM metamodel
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
Incorporate 12.2.2 ActivityProperty (abstract) (p76) in a coherent way into merged SACM metamodel
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
Incorporate 12.2.1 Activity (p75) in a coherent way into merged SACM metamodel
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
Incorporate 12.1.5 RequiresPackage (p74) in a coherent way into merged SACM metamodel
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
Incorporate 12.2.3 Satisfies (p76) in a coherent way into merged SACM metamodel
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
Incorporate 11.5.5 Amplifies (p65) in a coherent way into merged SACM metamodel
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
Incorporate 9.2.1 FormalObject (abstract) (p33) in a coherent way into merged SACM metamodel
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
Incorporate 9.1.3 RoleBinding (p31) in a coherent way into merged SACM metamodel
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
Incorporate 9.1.2 DomainClaim (p 31) in a coherent way into merged SACM metamodel
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’]
Incorporate 9.1.1 Assertion (p30) in a coherent way into merged SACM metamodel
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.
Incorporate 9.2.3 UnknownSubject (p34) in a coherent way into merged SACM metamodel
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
Incorporate 9.2.2 Object (p33) in a coherent way into merged SACM metamodel
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.
Incorporate 8.1.12 IsReleasableTo (p28) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.11 HasSecurityClassification (p28) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.10 HasVersion (p27) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.9 IsExpressedInLanguage (p26) in a coherent way into merged SACM metamodel
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
Incorporate 9.2.4 CompositeSubject (p34) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.6 HasMedia (p25) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.8 IsBasedOn (p26) in a coherent way into merged SACM metamodel
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
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.
No Data Available
It is not clear why the EvidenceEvaluation relationship types “weakens” and “amplifies” are themselves between Evidence relations.
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”
The use of a “content” attribute is suggested for the “stmt” attribute. See comment 5.
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
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.
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.
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.
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
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.
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
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.
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
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.
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
The class DocumentAttribute does not seem to be described in the standard
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
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.
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
Can assertions not be deleted, if not revoked?
The common resolution is provided under issue 16845.
Disposition: Merged
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.
see pages 36 - 37 of ptc/2012-06-04
The description of Object starts with the class name FormalObject, which is probably a copying error.
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).
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
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
Incorporate 11.4.1 EvidenceInterpretation (abstract) (p60) in a coherent way into merged SACM metamodel
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
Incorporate 11.5.2 Conflicts (p64) in a coherent way into merged SACM metamodel
The resolution to this issue is provided by the related issue 16805
Disposition: Merged
Incorporate 11.5.1 EvidenceObservation (abstract) (p64) in a coherent way into merged SACM metamodel
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>>
Incorporate 11.3.6 CompletenessLevel (enumeration) (p59) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 11.3.5 Completeness (p58) in a coherent way into merged SACM metamodel
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
Incorporate 11.3.8 ReliabilityLevel (enumeration) (p59) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 11.3.7 Reliability (p59) in a coherent way into merged SACM metamodel
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
Incorporate 11.4.3 MeansThat (p61) in a coherent way into merged SACM metamodel
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
Incorporate 11.4.2 IsA (p61) in a coherent way into merged SACM metamodel
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
Incorporate 11.4.4 IsCharacterizedBy (p62) in a coherent way into merged SACM metamodel
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
Incorporate 11.4.5 IsScopedBy (p62) in a coherent way into merged SACM metamodel
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
Incorporate 11.5.4 Weakens (p65) in a coherent way into merged SACM metamodel
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
Incorporate 11.3.4 ConsistencyLevel (enumeration) (p58) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 11.1.2 Supports (p50) in a coherent way into merged SACM metamodel
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
Incorporate 11.1.1 EvidenceRelation (abstract) (p50) in a coherent way into merged SACM metamodel
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 >>
Incorporate 10.4.8 CareOf (p46) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.7 CustodyProperty (abstract) (p46) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.4 ReportingLevel (enumeration) (p53) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 11.2.3 Reporting (p52) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.6 IsGeneratedAt (p45) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.5 IsRevokedAt (p44) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.1 Support (p51) in a coherent way into merged SACM metamodel
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
Incorporate 11.1.3 Challenges (p50) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.4 IsTransferredTo (p43) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.9 AtLocation (p47) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.10 UsingProcess (p47) in a coherent way into merged SACM metamodel
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
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).
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.
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
Significant model changes have been done during the FTF work, and cardinalities fixed. This issue
therefore is closed.
Disposition: Closed, no change
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”.
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
"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.
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.
"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.
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.
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.
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"
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.
The resolution to this issue will be provided as part of the resolution to issue 16810
Disposition: Merged
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.
Systematically replace text "the assurance case" with "an assurance case"
Incorporate 10.2.1 TimingProperty (abstract) (p37) in a coherent way into merged SACM metamodel
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>>
Incorporate 10.1.4 OwnedBy (p36) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.3 IsCreatedAt (p42) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.2 IsAcquiredAt (p41) in a coherent way into merged SACM metamodel
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
Incorporate 10.1.3 ApprovedBy (p36) in a coherent way into merged SACM metamodel
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
Incorporate 10.1.2 CreatedBy (p35) in a coherent way into merged SACM metamodel
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
Incorporate 10.2.4 EndTime (p38) in a coherent way into merged SACM metamodel
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
Incorporate 10.2.3 StartTime (p38) in a coherent way into merged SACM metamodel
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
Incorporate 10.4.1 EvidenceEvent (abstract) (p40) in a coherent way into merged SACM metamodel
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
Incorporate 10.2.2 EffectiveTime (abstract) (p38) in a coherent way into merged SACM metamodel
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
Incorporate 10.1.1 Provenance (abstract) (p35) in a coherent way into merged SACM metamodel
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>>
Incorporate 10.2.5 AtTime (p39) in a coherent way into merged SACM metamodel
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
Incorporate 10.3.1 Description (p40) in a coherent way into merged SACM metamodel
Remove entire section titled "Descriptions Class Diagram".
Remove Descriptions class diagram from the model.
: 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.
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>
“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”.
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.
“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.
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.
"
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
This issue to be resolved by a constraint on the Claim class. See resolution for 17347
Disposition: Merged
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”
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."
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.
Updated examples should be provided to reflect the current model. Merged with 16695
Resolution:
No further action
Disposition: Merged
: 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.
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.
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?
diasgrams in ptc/2012-06-04
Incorporate 12.2.5 IsAssociatedWith (p77) in a coherent way into merged SACM metamodel
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
Incorporate 12.2.4 RequiresMethod (p77) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.10 Relevance (p55) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.9 Significance (p55) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.7 Confidence (p54) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.6 AccuracyLevel (enumeration) (p53) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 11.3.1 Originality (p57) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.12 Strength (p56) in a coherent way into merged SACM metamodel
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
Incorporate 11.2.5 Accuracy (p53) in a coherent way into merged SACM metamodel
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
Incorporate 11.3.3 Consistency (p58) in a coherent way into merged SACM metamodel
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
Incorporate 11.3.2 OriginalityLevel (enumeration) (p57) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 11.2.8 ConfidenceLevel (enumeration) (p54) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 11.2.11 Level (enumeration) (p55) in a coherent way into merged SACM metamodel
The common resolution is provided under issue 16845.
Disposition: Merged
Incorporate 7.2.8 DomainAssertion (abstract) (p19) in a coherent way into merged SACM metamodel
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
Incorporate 7.2.7 DomainObject (abstract) (p19) in a coherent way into merged SACM metamodel
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.
Incorporate 7.2.4 EvaluationAttribute (abstract) (p18) in a coherent way into merged SACM metamodel
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
Incorporate 7.2.3 EvidenceProperty (abstract) (p17) in a coherent way into merged SACM metamodel
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
Incorporate 7.2.6 Meaning (abstract) (p18) in a coherent way into merged SACM metamodel
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
Incorporate 7.2.5 EvidenceItem (abstract) (p18) in a coherent way into merged SACM metamodel
No change is required.
Disposition: Closed, no change
Incorporate 7.2.9 EvidenceEvent (abstract) (p20) in a coherent way into merged SACM metamodel
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
Incorporate 7.2.2 EvidenceElement (abstract) (p16) in a coherent way into merged SACM metamodel
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.
Incorporate 7.2.1 Element (abstract) (p16) in a coherent way into merged SACM metamodel
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).
Incorporate 8.1.1 Exhibit (p 21) in a coherent way into merged SACM metamodel
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
Incorporate 7.2.10 EvidenceEvaluation (abstract) (p20) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.5 IsPartOf (p25) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.4 HasElectronicSource (p24) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.3 Exhibit Property (p23) in a coherent way into merged SACM metamodel
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
Incorporate 8.1.2 Document (p22) in a coherent way into merged SACM metamodel
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