Issues for Mailing list of the Structured Assurance Case Metamodel (SACM) FTF as joint FTF for ARM and SAEM

To comment on any of these issues, send email to sacm-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 16278: Difference between properties and attributes fuzzy and unneccessary (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Enhancement
Severity: Significant
Summary:

The distinction between "property" and "attribute" is unclear and could be confusing; and it is unnecessary.


An EvidenceProperty is defined to be "fundamental" and different kinds of properties are variously defined to be “a physical characteristic” “common”, “a single characteristic of the exhibit ,“ “provenance and timing characteristics “… Attributes are presumably otherwise  not fundamental. For example, “EvaluationAttribute is an abstract class that represents certain characteristics of various evidence elements that were asserted during the course of evaluation.”


At one time, property was agreed to mean something inherent. “Fundamental” is even less clear than “inherent”.


For example, physical measurements are always (or almost always) not inherent and can vary because of conditions and measurement error. Weight is not inherent, and how meaningful would it be to say it is fundamental? Provenance and [e.g. creation. revision] timing characteristics are often questionable and are they “fundamental”.  The body of the evidence does not generally change if they are changed.

The motivation for naming some things as a property and others as an attribute might on the surface appear to have some merit. In the end, however, this distinction turns out to be simply difficult and confusing. Any usefulness is questionable, and it is entirely unnecessary. It should be dropped and all such things called an “attribute”.

Resolution: 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
Revised Text:
Actions taken:
May 26, 2011: received issue
September 13, 2012: closed issue

Issue 16282: General mistaken cardinality issue (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Clarification
Severity: Minor
Summary:

Several specific instances of cardinality-related problems are identified in other issues. However, as these are potentially symptoms of a potentially more general problem, a general review should be made of cardinalities and limits placed only when inherent and essential

Resolution: Significant model changes have been done during the FTF work, and cardinalities fixed. This issue therefore is closed. Disposition: Closed, no change
Revised Text:
Actions taken:
May 26, 2011: received issue
September 13, 2012: closed issue

Issue 16288: A more generally available "citation" capability (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Critical
Summary:

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

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

Resolution: Add the following to attributes subsection of 11.1.2 Document, page 43: citation:String The full citation of the document (bibliographical reference)
Revised Text:
Actions taken:
May 27, 2011: received issue
September 13, 2012: closed issue

Discussion:

add "citation:String" attribute to SACM Evidence Metamodel Document element

Issue 16290: Modify term “evidence collection project” (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Clarification
Severity: Minor
Summary:

Use of term “evidence collection project” is misleading as evidence is collected, generated, acquired, derived, evaluated, and it and information about it exchanged  and maybe other kinds of actions. A question also exists about whether it should be called a “project” as it is generally a crosscutting concern/effort within projects. Suggest, in order of preference, “included in interchange”, “involved in interchange” or “evidence-related efforts”. Emphasis on interchange is better where possible, but a mix of these might be needed.

Resolution: 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"
Revised Text:
Actions taken:
May 28, 2011: received issue
September 13, 2012: closed issue

Discussion:

Related resolutions 16840 (editorial changes)

Issue 16294: Increased clarity needed (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Clarification
Severity: Significant
Summary:

While clarity needs improvement throughout, the following are specific instances:
•       An explanation is needed of how the two sets of provenance-related classes and event-related classes need to be clearly and cleanly related to each other and to other elements. 
•       The terms “role” and “rolebinding” need clear explanations..
•       The word “role” appears to be used both casually and technically. Use it only in the latter way.
•       Term “subject claim” is unnecessary and potentially confusing  why bother users with it. 
•       As introductory material, Figure 1 is unclear, for example “evidence observation” sounds like an observation done to obtain evidence. 
•       Meaning of “revoked” is unclear as generally nothing should be destroyed. Something might be excluded from assurance case (and maybe later brought back).

Resolution: 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.
Revised Text:
Actions taken:
May 30, 2011: received issue
September 13, 2012: closed issue

Discussion:

1) Provenance and events have been made uniform and the corresponding explanations provided; no
change
2) Explain role and rolebinding using the SBVR definitions
3) Remove casual uses of the word 'role'
4) the term is defined, and is used to contrast the more technical evidence claims from the claims related to
the subject area of the assurance case; no change
5) figure 1 has changed; no change
6) Explain revocation (section 13.2.6)

Issue 16295: Improve wording (editorial) (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Clarification
Severity: Significant
Summary:

Generally replace “the assurance case” with “an assurance case” unless speaking of a particular one.

Document needs to be worded throughout in ways that make it consistently clear that it is an interchange standard and not a repository standard.

Resolution: Systematically replace text "the assurance case" with "an assurance case"
Revised Text:
Actions taken:
May 30, 2011: received issue
September 13, 2012: closed issue

Issue 16296: Eliminate or change name of “EffectiveTime" (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Clarification
Severity: Significant
Summary:

"EffectiveTime" is not an obvious term. This class might be best eliminated and its subclasses have TimingProperty as their superclass, or a more understandable name should be used.

Resolution: 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.
Revised Text:
Actions taken:
May 30, 2011: received issue
September 13, 2012: closed issue

Discussion:

There is a related issue 16761 that addressed the metamodel structure, where decision was made to keep the
element EffectiveTime. Since this issue was not in the tracker at the time, the decision to keep the element
was made in isolation. There is indeed little value in having this element, except for the fact that it better
arranges the StartTime and EndTime as the related endpoints of a time inverval. To be consistent we will
keep the element, and clarify the text.

Issue 16297: Change name “Amplifies" (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

"Amplifies" could easily be understood as "strengths". What is meant is "ExpoundsOn" (clearest) or "AmplifiesOn" (clearer). Alternately, possibly some other element already used to comment or explain could be used instead.

Resolution: 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.
Revised Text:
Actions taken:
May 30, 2011: received issue
September 13, 2012: closed issue

Issue 16298: Definition for “Rationale” element missing (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Clarification
Severity: Critical
Summary:

A “Rationale” element appears in Figure 11.6 and is mentioned several times in text, but never defined. It either needs to be defined or the element from ARM that it essentially duplicates, ArgumentReasoning, be used instead.

Resolution: The resolution to this issue will be provided as part of the resolution to issue 16810 Disposition: Merged
Revised Text:
Actions taken:
May 30, 2011: received issue
September 13, 2012: closed issue

Issue 16299: ArgumentReasoning available for more relations (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: This issue is resolved as part of the accumulated model improvement, esp. resolution 17347. The updated Argumnetation Metamodel includes element AssertedChallenge. Also the Evidence Metamodel includes a related element Challenges. Disposition: Closed, not change
Revised Text:
Actions taken:
May 30, 2011: received issue
September 13, 2012: closed issue

Issue 16311: Change name of “Originator” (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

“Originator” is used for not only creating entity(ies), but also Approver and owner and therefore is an inappropriate class name.  One possibility is “Actor”.

Resolution: 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.
Revised Text:
Actions taken:
June 5, 2011: received issue
September 13, 2012: closed issue

Discussion:

Related resolutions are 16830, 16815
The term 'Actor' is not quite suitable, because of the completely wrong general connotation.
The OMG Business Motivation Metamodel (BMM) has a related element 'Influencer', however it's
definition is too specific: something that has the capability of producing an effect without apparent exertion of tangible force or direct exercise of command, and often without
deliberate effort or intent".
On the other hand, the suggested change is to change the 'Originator (which has the
connotation of an 'author'), to include anything from 'author', to movers and shakers, in
addition to an 'influencer'.
An alternative term is 'contributor', according to American Heritage Dictionary is defined
as follows:
a person or thing that contributes something, in particular
• a person who writes articles for a magazine or newspaper.
• a person who donates money to a cause.
• a causal factor in the existence or occurrence of something : stress is a major contributor
to most diseases.
Rename to 'Stakeholder'.
According to American Heritage dictionary, a 'stakeholder is defined as a person with an interest or concern
in something, esp. a business.
According to the Wikipedia, a 'Stakeholder' may refer to:
Stakeholder (corporate), a person, group, organization, member or system who affects or can be affected by
an organization's actions
Project stakeholder, a person, group or organization with an interest in a project
The term 'stakeholder' is aligned with the ISO/IEC 42010 Architecture Description (and
with Zachman framework): ISO/IEC "system stakeholder: An individual, team, or
organization (or classes thereof) with interests in, or concerns relative to, a system."
This way, several roles of a stakeholder are indirectly defined in the Evidence
Metamodel, through the Provenance and Custody statements (creator, approver, owner,
custodian, etc.). Other roles related to the affiliation of the stakeholder in some
organization can be user-defined through the HasRoleIn statement.

Issue 16312: 1..2.14. Need to record modification events and who modified (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

Modification events need to be record and who modified. No “ModifiedBy” or “RevisedBy” is defined. Is “CreatedBy” supposed to also function to also mean “modified by”? This seems unwise. Likewise a derivedby would seem to be needed if something was derived from multiple sources. What about a copying event?

Resolution: diasgrams in ptc/2012-06-04
Revised Text:
Actions taken:
June 5, 2011: received issue
September 13, 2012: closed issue

Discussion:

Summary of changes:
add new event isModifiedBy
add new provenance clause PerformedBy
allow EvidenceEvent on any EvidenceElement;
add constraints to some of the events that they are not applicable to assertions (e.g.
isAcquiredAt, isTransferredTo); but CustodyProperty only owned by EvidenceEvent
Related resolutions: 16736 (EvidenceEvent), 16773 (Custody Property), 16699 (state
transition diagrams), 16700 ( lifecycle) EvidenceEvent is an abstract class that represents any event related to the lifecycle of
evidence element. Concrete evidence events are defined as subclasses of the
EvidenceEvent element.
into (these edits supersede the changes to this paragraph made in resolution 16736):
EvidenceEvent represents statements related to the events in the lifecycle of an evidence
element. The lifecycle of an evidence element is determined by several events, such as
Creation, Acquisition or Derivation of the evidence element; Transfer of the evidence
element; Modification of the evidence element; Evaluation of the evidence element; and
Revocation of the evidence element. Semantics of concrete evidence events is defined for
the subclasses of the EvidenceEvent element. An EvidenceEvent statement describes a
certain characteristic of the subject evidence element. More complex Event statements
can be constructed by adding further Timing, Provenance and Custody clauses to
EvidenceEvents of the subject evidence element. In particular, the mechanism of
EvidenceEvents allows making statements about the time-dependent characteristics of the
subject evidence element, since each EvidenceEvent can be the subject of its own timing
clause. The entire chain of custody of an evidence element can be established by
analyzing the EvidenceEvents of the element. On the other hand, Timing, Provenance
and Custody clauses for the subject evidence element itself (EvidenceProperty object that
are directly owned by the EvidenceElement object) state essential characteristics of the
EvidenceElement that do not change over time. ,
Statements about evidence elements can be revoked and updated statements can be made.
The ModifiedBy event statement can be used to provide the record of the modification
events.
Add section IsModifiedBy at the bottom of section 13.4 as follows:
IsModifiedBy
IsModifiedBy is an Evidence Event that describes a modification of an evidence element
throughout its lifecycle. Modification event emphasizes changes to the original exhibit or
changes in the meaning of the FormalAssertion or EvidenceAssertion, or changes to the
ProjectElement. The IsModifiedBy element can be the subject of additional Timing,
Provenance and Custody clauses.
Superclass
EvidenceEvent
Semantics
IsModifiedBy element represents a unique modification event throughout its lifecycle of
the subject EvidenceElement object. IsModifiedBy element represents the state of affairs
that the owner object is modified. IsModifiedBy may include additional clauses that
provide further details about the modification event. In particular, an Annontation clause
can be used to describe the nature of the modification.
Clause Meaning Verbalization
AtTime Time of the modification Element is modified at time
EffectiveTime N/A
CreatedBy N/A
PerformedBy The stakeholder who Element is modified by ApprovedBy The stakeholder who
approved the modification
Modification of element is
approved by stakeholder
OwnedBy N/A
CareOf N/A
AtLocation The location at which the
modification is performed
Element is modified at
location
UsingProcess The reference to a method
by which the evidence
element is modified
Element is modified using
method
remove associations from EvidenceItem, page 37:
Associations
• event:EvidenceEvent [0..*] Chain of custody, represented as set of events with
time stamps that determined the lifecycle of the evidence item.
add to associations of EvidenceElement, page 36, as follows:
event:EvidenceEvent[0..*] Event properties, describing the set of events with timing
clauses determined by the lifecycle of the EvidenceElement
Replace Figure 13.4 EvidenceEvent Class Diagram as follows (see also resolution to
issues 16736 and 16773):
Add clause IsModifiedBy to table on page 15 as follows:
IsModifiedBy At location, By stakeholder (person), At time, Owned by organization,
Approved by supervisor By stakeholder, Approved by supervisor, At time, Owned
by organization By stakeholder, Approved by supervisor, At time, Owned by
organization
Add PerformedBy section to 13.1 as follows:
PerformedBy
PerformedBy element represents the provenance clause that states the stakeholder who
executes an evidence event. The clause can refer to a person or an organization,
collectively referred to as a Stakeholder.
Superclass Provenance
Associations
• executor:Stakeholder[1] The executor of the subject event.
Semantics
PerformedBy element represents a clause of an evidence statement related to the subject
EvidenceElement. PerformedBy element represents the state of affairs that the subject
event was executed by the particular stakeholder, defined by Stakeholder object.
Executor of an evidence event can be a person or an organization.
The characteristic of PerformedBy is expressed by a sentential form “Event is performed
by executor.”
Replace Figure 3.1 with the following:
Modify semantics of clauses for IsAcquiredAt event from:
CreatedBy The originator of the acquisition Element is acquired by originator
into
CreatedBy N/A
PerformedBy The stakeholder who acquired the evidence element Element is acquired
by stakeholder
Modify semantics of clauses for IsCreatedAt event from:
CreatedBy The source of the EvidenceElement Element is created by originator
into
CreatedBy N/A
PerformedBy The source of the EvidenceElement Element is created by stakeholder
Modify semantics of clauses for IsGeneratedAt event from:
CreatedBy The executor of the generation of the evidence element Element is
generated by originator into
CreatedBy N/A
PerformedBy The stakeholder who generated the evidence element Element is
generated by stakeholder
Modify semantics of clauses for IsTransferredTo event from:
CreatedBy The source of the transfer (the previous curator of the evidence element)
Element is transferred by originator
into
CreatedBy N/A
PerformedBy The stakeholder who transferred the evidence element
Element is transferred by originator
Modify semantics of clauses for IsRevokedAt event from:
CreatedBy The executor of the revocation Element is revoked by originator
into
CreatedBy N/A
PerformedBy The stakeholder who revoked the evidence element Element is
revoked by stakeholder

Issue 16508: Confidence as an Assertion (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: Authors response: Although every property can be considered to be asserted, SACM focus is on argument structuring elements. Therefore no change made. Decision: This is not how represented in ARM or SAEM - REJECT Disposition: Closed, no change
Revised Text:
Actions taken:
August 25, 2011: received issue
September 13, 2012: closed issue

Issue 16512: Meaning of HasDependencyOn (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

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

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

Discussion:

Re enumerations: Out of scope – such enumerations did not exist in ARM/SAEM. “derives from” and
“subsumes” were suggested. This can be revisted in long term maintenance. Re Values for
natureofdependency: we are not constraining these Re: HasDependencyOn inheriting from AssertedLinks:
No action, out of scope for the Argumentation Metamodel.
The Evidence Metamodel has IsBasedOn element as a subclass of ExhibitProperty, as well as DependsOn
as a subclass of ProjectProperties. Clarifications to semantics will be made to suggest the use of
TaggedValue to add nature of dependency. However it is outside of the scope of SACM to standardize on
an enumeration of possible/useful dependencies.

Issue 16513: Hierarchical Collections of Artifacts or Other Items (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

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

In addition, non-hierarchical structures also have uses

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

Issue 16515: Link to Actual Artifact Represented by Model Element (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

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

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

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

Issue 16516: Linking to Portions of an Artifact if this is what is Represented by a Model Element (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:

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

Resolution: If you need to reference a portioned item, you need an artifact. Can use tagged values and annotation to include other referencing information No further action planned The relationship between the artefact and the EvidenceAssertion is made clear by the association. REJECT. The SACM Evidence Metamodel provides more detailed solution. Disposition: Closed, no change
Revised Text:
Actions taken:
August 25, 2011: received issue
September 13, 2012: closed issue

Issue 16520: InformationAssertion’s and Informational Contents (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Minor
Summary:

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

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

Issue 16691: ARM: Page 12, Figure 2, Page 15, section 8.2.6 and page 16, section 8.2.9: In Figure 2 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Page 12, Figure 2, Page 15, section 8.2.6 and page 16, section 8.2.9: In Figure 2, the attributes “toBeSupported” and “assumed” appear in the same class (Claim), but in the subsequent sections “toBeSupported” appears in ReasoningElement (a super-class of Claim). It seems that these two attributes are related: nothing should be both “assumed” and “to be supported”. This suggests that either:

a. The “toBeSupported” attribute should be removed on the grounds that any Claim that is not assumed should have support, and if it doesn’t, then it is yet to be supported; or

b. A single attribute should be used to represent three states: assumed, supported or not-
yet-supported (alternatively: assumed, needs-no-support and needs-support); or

c. An invariant should be present to state the constraining relationship between the two attributes described above.
Note that “toBeSupported” could be construed as a process issue, and therefore better treated as a TaggedValue to make the model less prescriptive. 

Note also that the “toBeSupported” attribute should be constrained to be false in the EvidenceAssertion class, as well as, possibly, the “assumed” attribute

Resolution: This issue to be resolved by a constraint on the Claim class. See resolution for 17347 Disposition: Merged
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16692: ARM: Page 16, section 8.2.9 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

“A Claim that is intentionally declared without any supporting evidence or reasoning (in the recorded Argument) ...”: It is clear how evidence supports a claim (through the AssertedEvidence link). It is less clear how reasoning supports a Claim; the reasoning itself is represented in the “content” attribute of an ArgumentReasoning element, which can be associated with an AssertedInference, which in turn may have the Claim as its target; but this an indirect association.

Resolution: 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. "
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16695: ARM: Page 21, section 8.3.1 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

: In the Industrial Press example, the attribute toBeSupported=”True” should be present in element 9, C2.3. This is reflected by the presence of a diamond in the GSN portrayal on page 23, Figure 3.

Resolution: 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>
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Discussion:

The examples should be updated to reflect the current model

Issue 16696: ARM: Page 21, sections 8.3.1 and 8.3.2 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is an inconsistency between these two examples in the way that AssertedRelationships are represented. In the Bluetooth example, the AssertedInference “AI1” is permitted multiple targets, documenting the fact that a single inference connects multiple entities. In the Industrial Press example, however, a similar single interference is represented by multiple AssertedInference elements each with a single target. It is possible that both ways are necessary, because one may wish to associate different ArgumentReasoning elements to different parts of the AssertedRelationship; if this is the case, then is should be made clear.

Resolution: Updated examples should be provided to reflect the current model. Merged with 16695 Resolution: No further action Disposition: Merged
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16697: ARM Typographical errors (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Page 10, section 7.4: “a set of practical modelling approach that”
Page 15, section 8.2.6, Semantics: “When building an argument it is may be useful”
Page 17, section 8.2.11: “the asserted inference that connect one or more Claims”
Page 18, section 8.2.14, Semantics: “This relationship between this claim” – suggest “The relationship”

Resolution: 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."
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16698: SAEM: Page 6, section 7.1 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

: This comment relates to the sentence “Evidence arguments are reused as opposed to subject domain claims and arguments, which are specific to each domain.” The term “subject claim” has been defined, but not the term “subject domain claim”. Suggest removing the word “domain” in this context.

Resolution: 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.
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Discussion:

This issue is related to issue 16735

Issue 16699: SAEM: Page 11, section 7.3, figure 2 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

This state transition diagram could be simplified by amalgamating the two main states at either end of the “re-evaluated” transition. Note that the transitions “transferred”, “evaluated” and “revoked” have analogous behaviour on these two states. Similarly in Figure 3.

Resolution: see pages 36 - 37 of ptc/2012-06-04
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16700: SAEM: Page 12, text under figure 3 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Can assertions not be deleted, if not revoked?

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16701: SAEM: Page 13, section 7.4, in table (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is not clear why the EvidenceEvaluation relationship types “weakens” and “amplifies” are themselves between Evidence relations.

Resolution: 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”
Revised Text:
Actions taken:
November 18, 2011: recived issue
September 13, 2012: closed issue

Discussion:

add example to illustrate the difference between challenges and weakens:

Issue 16702: SAEM: Page 16, section 8.2.2 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The ARM approach to the description of elements seems better: use an attribute called “content” in an abstract class to contain the “prose” description, and allow this attribute to be inherited by sub-classes.

Resolution:
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Discussion:

This has been achieved to the possible extent through changes to the FormalAssertions
(resolutions 16733, 16734, 16735, 16710, 16698, 16704, 16749, 16750, 16752 and
SACM FTF


16753). Other places provide formal statements as well as more structured statements
related to evidence than possible to achieve through a mere 'content' attribute.
Disposition: Duplicate

Issue 16703: Page 16, section 8.2.2 (2) (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

To stipulate the structure of the id of an element is over-constraining. If the URL of the organisation is important to capture, then there should be a separate attribute for it; the name of the SAEM class is surely redundant. It should be sufficient to state that, whatever the identifiers used, they are to be globally unique, and let the implementers solve the problem how they will.

Resolution: 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.
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Discussion:

The Evidence Metamodel uses the mechanism of globally unique ids for all identifiable
elements. It prescribes the structure of the global id. On the other hand, the
Argumentation Metamodel uses a weaker scheme, where the id of an identifiable element
is required to be unique inside the model.
The integrated SACM will use prescribed globally unique ids for the top "administration"
objects that are the units of exchange and that own other elements. Each identifiable
element will be required to have a "locally" unique id (unique within the given unit of
exchange).
As the result, the global referencing scheme may involve gid+id combination, while a
local scheme may use id component.
Related resolutions are 16836 (SACM top level integration) and 17347 (accumulated
changes to the Argumentation Metamodel).

Issue 16704: SAEM: Page 19, section 8.2.8 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The use of a “content” attribute is suggested for the “stmt” attribute. See comment 5.

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Discussion:

This issue is related to issue 16735
rename attribute stmt to content

Issue 16705: SAEM: The class DocumentAttribute does not seem to be described in the standard (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The class DocumentAttribute does not seem to be described in the standard

Resolution: 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
Revised Text: figure on p 44 of ptc/2012-06-04
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Discussion:

Related resolution 16740.
Here is the summary of the proposed changes:
Eliminate DocumentAttribute class. Use DocumentProperty as subclass of
ExhibitProperty to share common "property'" association. More specifically:
remove class DocumentAttribute from EvidenceElements diagram
rename class DocumentAttribute into DocumentProperty
change superclass of DocumentProperty to ExhibitProperty
add DocumentPropertyClass to EvidenceAssertions diagram
move classes HasVersion,
IsExpressedInLanguage, IsReleaseableTo, HasSecurityClassification from class diagram
Exhibits to class diagram DocumentProperties
move DocumentAttributes section 14.3 from chapter 14 to chapter 11 as section 11.2
remove the ShortTitle attribute

Issue 16706: SAEM: Page 21, section 9.1, figure 6 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The class “IsPartOf” is an example of an instance in the standard where a class is used to represent a relationship where a simple UML association would do. The concept is that an Exhibit can be part of other Exhibits. This is most naturally expressed as an “isPartOf” association that has Exhibit as its source and target. Introducing a class for this relationship clutters the model.

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16707: SAEM: Page 21,section 9.1,figure 6 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Assuming that a document has only one medium (which is likely, otherwise there would be two exhibits), then the model would be simplified by making “medium” an attribute of a Document.

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: recived issue
September 13, 2012: closed issue

Issue 16708: SAEM: Page 24,section 9.1.4 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Since, as stated under Constraints, an exhibit shall not have more than one electronic source, then this could be made into an attribute of the Exhibit class rather than an association.

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16709: SAEM: Page 33, section 10.2.1 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The phrase “an individual” without qualification usually refers to a person, which is not intended here. This should be stated as “an individual fact” or “an individual concept

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Discussion:

The usage of the term "individual" has been reviewed and the ambiguous places have been identified.
There are indeed only few places, where an individual means "person", few places where the term is already used as a part of larger phrases (as suggested above). In the remaining 4 places the term 'individual'
refers to an 'object' (an 'instance' as opposed to a 'type' or a metamodel element).

Issue 16710: SAEM: Page 33, section 10.2.2 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The description of Object starts with the class name FormalObject, which is probably a copying error.

Resolution: 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).
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16711: SAEM: Page 35, section 11 (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Rather than trying to enumerate all the possible properties that evidence could possess, it may be better to consider a extensible mechanism such as the TaggedValue class in ARM. This principle would simplify the model considerably if applied to all such properties, by the time Provenance, TimingProperty, CustodyProperty, EvidenceProperty and DocumentProperty sub-classes have been taken into account. Detailed enumerations such as these are bound to be incomplete; user defined values are more flexible.

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16713: SAEM: Typographical errors (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Page 1, section 1.2, 2nd paragraph:
This sentence is representative of the systemic grammatical errors that pervade the document, which centre mainly around missing definite and indefinite articles. The sentence should perhaps read: “The level of confidence that a given software system is trustworthy is called Software Assurance (SwA) and the process that establishes the level of confidence is called SwA process.” (Italics indicate inserted words.)

Page 20-21, sections 9.1 and 9.1.1:
The paragraph stating “The most common form of an exhibit ...” is repeated in these two sections. In general, there is a considerable amount of repeated text in the document, usually between the descriptions and the semantics.

Resolution: 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
Revised Text:
Actions taken:
November 18, 2011: received issue
September 13, 2012: closed issue

Issue 16728: Incorporate 7.2.1 Element (abstract) (p16) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.1 Element (abstract) (p16)	 in a coherent way into merged SACM metamodel

Resolution: 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).
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Related resolutions to this issue are issues 16836 (top level integration), 16703 (id), and 17347
(accumulated model changes to the Argumentation Metamodel). In Ballot 7 this issue was disposed as
'merged' with 16836. However it is more transparent to list the editing changes related to the 'Element' and
'EvidenceElement' elements in a separate issue.
The previous resolution to this issue will be removed from Ballot 7.

Issue 16729: Incorporate 7.2.2 EvidenceElement (abstract) (p16) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.2 EvidenceElement (abstract) (p16)	 in a coherent way into merged SACM metamodel

Resolution: 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.
Revised Text: figure oin p 48 of ptc/2012-06-04
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Summary of the proposed changes:
change superclass to ModelElement; remove id attribute (and move to ModelElement as the result of the
resolution to 16728, 16836 and 16703) ;
add association to Custody;
delete the description association (now provided through the ModelElement superclass in a more uniform
way). delete id constraints
Cleanup the EvidenceElements diagram to focus to the few key elements of the Evidence Metamodel.

Issue 16730: Incorporate 7.2.3 EvidenceProperty (abstract) (p17) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.3 EvidenceProperty (abstract) (p17)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text: figure oin p 51 of ptc/2012-06-04
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Here is the summary of the proposed changes:
Cleanup EvidenceElements class Diagram (see related resolution 16729, 16731, 16736, 16737, 16740,
16705).
change superclass of EvidenceProperty to EvidenceAssertion
change semantics text
add diagram EvidenceAssertions to chapter 10 Evidence Elements (section 10.2 EvidenceAssertions class
diagram)
section 10.2 to contain descriptions of the following classes:
EvidenceAssertion
EvidenceProperty
EvidenceEvaluation
move section 10.1.3 EvidenceProperty to section 10.2
move section 10.1.10 EvidenceEvaluation to section 10.2.
Note:
section 10.1.4 EvaluationAttribute is deleted as the result of resolution 16731.
section 10.1.7 DomainObject is moved to chapter Formal Statement as the result of the
resolution 16734.
section 10.1.8 DomainAssertion is moved to chapter Formal Statement as the result of the
resolution 16735.
section 10.1.9. EvidenceEvent is move to chapter EvidenceProperties as the result of the
resolution 16736.

Issue 16731: Incorporate 7.2.4 EvaluationAttribute (abstract) (p18) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.4 EvaluationAttribute (abstract) (p18)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

The EvaluationAttribute abstract class is a common superclass for EvidenceAttribute. and
DocumentAttribute. The suggested resolution is to remove this class.
Firstly, the commonality between the current subclasses is rather superficial: the corresponding statements
are used as supplementary clauses but in different contexts. EvidenceAttribute provides supplementary
clause for an EvidenceEvaluation (a relation between two EvidenceElements), while DocumentAttribute
describes a fundamental property of a Document. The commonality is "by construction": both elements are
owned by the subject EvidenceElement. There is little value in having a common superclass.
Related issues are: 16730 (EvidenceProperty), 16737 (EvidenceEvaluation), 16739 (Document), 16740
(ExhibitProperty). Resolutions to these issues introduce related changes to the EvidenceMetamodel
superclasses and further clarify the difference between EvidenceProperties and EvidenceAttributes.

Issue 16732: Incorporate 7.2.5 EvidenceItem (abstract) (p18) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.5 EvidenceItem (abstract) (p18)	 in a coherent way into merged SACM metamodel

Resolution: No change is required. Disposition: Closed, no change
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16733: Incorporate 7.2.6 Meaning (abstract) (p18) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.6 Meaning (abstract) (p18)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Rename to FormalElement
Related resolutions are 16734, 16710, 16735, 16698, 16704, 16749, 16750, 16752, 16753, 16754, 16755

Issue 16734: Incorporate 7.2.7 DomainObject (abstract) (p19) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.7 DomainObject (abstract) (p19)	 in a coherent way into merged SACM metamodel

Resolution: 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.
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

rename to FormalObject (note that also we are deleting the abstract class FormalObject,
as per resolution to 16752).
Also as part of this resolution, rename "Fact Model" into "Formal Statements"
systematically throughout the Evidence Metamodel text. Although the term "Fact Model"
is used in SBVR, in the world of assurance cases formal statements are used to represent
claims, which are the propositions that are asserted, rather than assumed as true.
Related resolutions are 16733, 16710, 16735, 16698, 16704, 16749, 16750, 16752, 16753,
16754, 16755.

Issue 16735: Incorporate 7.2.8 DomainAssertion (abstract) (p19) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.8 DomainAssertion (abstract) (p19)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

rename to FormalAssertion
Related resolutions are 16733, 16734, 16710, 16698, 16704, 16749, 16750, 16752, 16753,
16754, 16755

Issue 16736: Incorporate 7.2.9 EvidenceEvent (abstract) (p20) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.9 EvidenceEvent (abstract) (p20)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

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). Two
issues have been raises one for each location, and this is the main resolution to EvidenceEvent, issue 16773
is disposed as merged with the current issue.
Related issues 16773, 16766
remove class from diagram EvidenceElements and move to EvidenceEvents
add to diagram EvidenceAssertions
change superclass to EvidenceProperty
change diagram to show EvidenceItem owns EvidenceEvents
remove ownership to Custody (now through EvidenceElement)
add class EvidenceItem to show ownership of EvidenceEvent

Issue 16737: Incorporate 7.2.10 EvidenceEvaluation (abstract) (p20) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	7.2.10 EvidenceEvaluation (abstract) (p20)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

remove from diagram EvidenceElements
add to diagram EvidenceAssertions
change superclass to EvidenceAssertion
modify diagram EvidenceAttributes to show class EvidenceEvaluation and ownership to
EvidenceAttributes
move section from section 10 to section 14

Issue 16738: Incorporate 8.1.1 Exhibit (p 21) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.1 Exhibit (p 21)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16739: Incorporate 8.1.2 Document (p22) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.2 Document (p22)	 in a coherent way into merged SACM metamodel

Issue 16740: Incorporate 8.1.3 Exhibit Property (p23) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.3 Exhibit Property (p23)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

change superclass for class isBasedOn, from DocumentProperty to ExhibitProperty
remove class DocumentProperty
remove classes HasVersion, IsExpressedInLanguage, IsReleaseableTo,
HasSecurityClassification from class diagram ExhibitProperties
add ExhibitProperty to EvidenceAssertions
change rolename to property

Issue 16741: Incorporate 8.1.4 HasElectronicSource (p24) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.4 HasElectronicSource (p24)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16742: Incorporate 8.1.5 IsPartOf (p25) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.5 IsPartOf (p25)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16743: Incorporate 8.1.6 HasMedia (p25) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.6 HasMedia (p25)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16744: Incorporate 8.1.8 IsBasedOn (p26) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.8 IsBasedOn (p26)	 in a coherent way into merged SACM metamodel

Issue 16745: Incorporate 8.1.9 IsExpressedInLanguage (p26) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.9 IsExpressedInLanguage (p26)	 in a coherent way into merged SACM metamodel

Issue 16746: Incorporate 8.1.10 HasVersion (p27) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.10 HasVersion (p27)	 in a coherent way into merged SACM metamodel

Issue 16747: Incorporate 8.1.11 HasSecurityClassification (p28) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.11 HasSecurityClassification (p28)	 in a coherent way into merged SACM metamodel

Issue 16748: Incorporate 8.1.12 IsReleasableTo (p28) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	8.1.12 IsReleasableTo (p28)	 in a coherent way into merged SACM metamodel

Issue 16749: Incorporate 9.1.1 Assertion (p30) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	9.1.1 Assertion (p30)	 in a coherent way into merged SACM metamodel

Resolution: 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.
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

change url attribute to an explicit association to MOF::Element (suggested by Pete
Rivett)
Related resolutions are 16733, 16734, 16710, 16698, 16704, 16750, 16752, 16753, 16754,
16755

Issue 16750: Incorporate 9.1.2 DomainClaim (p 31) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	9.1.2 DomainClaim (p 31)	 in a coherent way into merged SACM metamodel

Resolution: 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’]
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

add association to ARM::Claim with rolename 'claim'
Related resolutions are 16733, 16734, 16710, 16698, 16704, 16749, 16752, 16753, 16754,
16755

Issue 16751: Incorporate 9.1.3 RoleBinding (p31) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	9.1.3 RoleBinding (p31)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

change superclass to SACM:UtilityElement
Note: the UtilityElement is a proposed common superclass, introduced as the result of
resolution to issue 16836
Other Related resolutions are 16733, 16734, 16710, 16698, 16704, 16749, 16750, 16752,
16753, 16754, 16755

Issue 16752: Incorporate 9.2.1 FormalObject (abstract) (p33) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	9.2.1 FormalObject (abstract) (p33)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

delete FormalObject
rename DomainObject to FormalObject
change superclass of Object to FormalObject
add element ObjectifiedAssertion
in EvidenceInterpretation diagram change Object to FormalElement
change rolename property to assertion (in IsCharacterizedBy)
Related resolutions are 16733, 16734, 16710, 16698, 16704, 16749, 16750, 16753, 16754,
16755

Issue 16753: Incorporate 9.2.2 Object (p33) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	9.2.2 Object (p33)	 in a coherent way into merged SACM metamodel

Resolution: 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.
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

change url attribute to an explicit association to MOF::Element (suggested by Pete
Rivett)
related resolution: 16752, other Related resolutions are 16733, 16734, 16710, 16698, 16704,
16749, 16750, 16753, 16754, 16755

Issue 16754: Incorporate 9.2.3 UnknownSubject (p34) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	9.2.3 UnknownSubject (p34)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

rename UnknownSubject to UnknownObject (since the term 'subject' is a rolename of a
particular assertion and not a suitable name of a stand-alone Evidence Metamodel
element).
change superclass of UnknownObject to FormalObject
related resolution: 16752 other Related resolutions are 16733, 16734, 16710, 16698, 16704,
16749, 16750, 16753, 16754, 16755

Issue 16755: Incorporate 9.2.4 CompositeSubject (p34) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	9.2.4 CompositeSubject (p34)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Rename CompositeSubject to CompositeObject (since the term 'subject' is a rolename of a
particular assertion and not a suitable name of a stand-alone Evidence Metamodel
element).
change rolename set to composite
change superclass of CompositeObject to FormalObject
related resolution 16752; other Related resolutions are 16733, 16734, 16710, 16698, 16704,
16749, 16750, 16753, 16754, 16755

Issue 16756: Incorporate 10.1.1 Provenance (abstract) (p35) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.1.1 Provenance (abstract) (p35)	 in a coherent way into merged SACM metamodel

Resolution: 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>>
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

remove class EvidenceProperty from diagram Provenance
add class Provenance to EvidenceAssertions diagram
delete class EvaluationAttribute from Provenance diagram (now ownership of Provenance is done in a
uniform way from EvidenceElement, see resolution 16730)

Issue 16757: Incorporate 10.1.2 CreatedBy (p35) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.1.2 CreatedBy (p35)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16758: Incorporate 10.1.3 ApprovedBy (p36) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.1.3 ApprovedBy (p36)	 in a coherent way into merged SACM metamodel

Issue 16759: Incorporate 10.1.4 OwnedBy (p36) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.1.4 OwnedBy (p36)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16760: Incorporate 10.2.1 TimingProperty (abstract) (p37) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.2.1 TimingProperty (abstract) (p37)	 in a coherent way into merged SACM metamodel

Resolution: 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>>
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

remove class EvidenceProperty from Timing diagram
add TimingProperty to EvidenceAssertions
remove class EvaluationAttribute from Timing diagram (now ownership from evidence element in a
uniform way, see resolution 16730)

Issue 16761: Incorporate 10.2.2 EffectiveTime (abstract) (p38) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.2.2 EffectiveTime (abstract) (p38)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16762: Incorporate 10.2.3 StartTime (p38) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.2.3 StartTime (p38)	 in a coherent way into merged SACM metamodel

Issue 16763: Incorporate 10.2.4 EndTime (p38) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.2.4 EndTime (p38)	 in a coherent way into merged SACM metamodel

Issue 16764: Incorporate 10.2.5 AtTime (p39) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.2.5 AtTime (p39)	 in a coherent way into merged SACM metamodel

Issue 16765: Incorporate 10.3.1 Description (p40) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.3.1 Description (p40)	 in a coherent way into merged SACM metamodel

Resolution: Remove entire section titled "Descriptions Class Diagram". Remove Descriptions class diagram from the model.
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

This is a common element for both Argumentation and Evidence parts of the Structured Assurance Case
Metamodel. This role will be represented by the Annotation element owned by the common
ModelElement. This mechanism will allow annotations/descriptions to all elements of the Evidence
Metamodel. Therefore, Description element is removed.
Additional resolutions related to the introduction of the common elements are provided as part of the
resolution to issue 16836.

Issue 16766: Incorporate 10.4.1 EvidenceEvent (abstract) (p40) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.1 EvidenceEvent (abstract) (p40)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16767: Incorporate 10.4.2 IsAcquiredAt (p41) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.2 IsAcquiredAt (p41)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16769: Incorporate 10.4.3 IsCreatedAt (p42) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.3 IsCreatedAt (p42)	 in a coherent way into merged SACM metamodel

Issue 16770: Incorporate 10.4.4 IsTransferredTo (p43) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.4 IsTransferredTo (p43)	 in a coherent way into merged SACM metamodel

Issue 16771: Incorporate 10.4.5 IsRevokedAt (p44) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.5 IsRevokedAt (p44)	 in a coherent way into merged SACM metamodel

Issue 16772: Incorporate 10.4.6 IsGeneratedAt (p45) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.6 IsGeneratedAt (p45)	 in a coherent way into merged SACM metamodel

Issue 16773: Incorporate 10.4.7 CustodyProperty (abstract) (p46) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.7 CustodyProperty (abstract) (p46)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

add diagram Custody
move CustodyProperty from EvidenceEvents to Custody
add CustodyProperty to EvidenceAssertions
change superclass to EvidenceProperty
Related issues 16736, 16766

Issue 16774: Incorporate 10.4.8 CareOf (p46) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.8 CareOf (p46)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16775: Incorporate 10.4.9 AtLocation (p47) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.9 AtLocation (p47)	 in a coherent way into merged SACM metamodel

Issue 16776: Incorporate 10.4.10 UsingProcess (p47) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	10.4.10 UsingProcess (p47)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16777: Incorporate 11.1.1 EvidenceRelation (abstract) (p50) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.1.1 EvidenceRelation (abstract) (p50)	 in a coherent way into merged SACM metamodel

Resolution: 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 >>
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

change rolename from 'item' to 'subject'
change diagram

Issue 16778: Incorporate 11.1.2 Supports (p50) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.1.2 Supports (p50)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16779: Incorporate 11.1.3 Challenges (p50) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.1.3 Challenges (p50)	 in a coherent way into merged SACM metamodel

Issue 16780: Incorporate 11.2.1 Support (p51) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.1 Support (p51)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16782: Incorporate 11.2.3 Reporting (p52) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.3 Reporting (p52)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16783: Incorporate 11.2.4 ReportingLevel (enumeration) (p53) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.4 ReportingLevel (enumeration) (p53)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16784: Incorporate 11.2.5 Accuracy (p53) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.5 Accuracy (p53)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16785: Incorporate 11.2.6 AccuracyLevel (enumeration) (p53) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.6 AccuracyLevel (enumeration) (p53)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16786: Incorporate 11.2.7 Confidence (p54) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.7 Confidence (p54)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16787: Incorporate 11.2.8 ConfidenceLevel (enumeration) (p54) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.8 ConfidenceLevel (enumeration) (p54)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16788: Incorporate 11.2.9 Significance (p55) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature:
Severity:
Summary:

Incorporate	11.2.9 Significance (p55)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16789: Incorporate 11.2.10 Relevance (p55) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.10 Relevance (p55)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16790: Incorporate 11.2.11 Level (enumeration) (p55) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.11 Level (enumeration) (p55)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16791: Incorporate 11.2.12 Strength (p56) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.2.12 Strength (p56)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16792: Incorporate 11.3.1 Originality (p57) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.1 Originality (p57)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16793: Incorporate 11.3.2 OriginalityLevel (enumeration) (p57) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.2 OriginalityLevel (enumeration) (p57)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16794: Incorporate 11.3.3 Consistency (p58) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.3 Consistency (p58)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16795: Incorporate 11.3.4 ConsistencyLevel (enumeration) (p58) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.4 ConsistencyLevel (enumeration) (p58)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16796: Incorporate 11.3.5 Completeness (p58) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.5 Completeness (p58)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16797: Incorporate 11.3.6 CompletenessLevel (enumeration) (p59) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.6 CompletenessLevel (enumeration) (p59)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16798: Incorporate 11.3.7 Reliability (p59) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.7 Reliability (p59)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16799: Incorporate 11.3.8 ReliabilityLevel (enumeration) (p59) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.3.8 ReliabilityLevel (enumeration) (p59)	 in a coherent way into merged SACM metamodel

Resolution: The common resolution is provided under issue 16845. Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16800: Incorporate 11.4.1 EvidenceInterpretation (abstract) (p60) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.4.1 EvidenceInterpretation (abstract) (p60)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

change rolename from 'element' to 'subject'
move class ProvidesContext to EvidenceInterpretation diagram
change superclass to EvidenceInterpretation
remove class ProvidesContext from EvaluationContext
delete class Supercedes
delete EvaluationContext diagram

Issue 16801: Incorporate 11.4.2 IsA (p61) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.4.2 IsA (p61)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16802: Incorporate 11.4.3 MeansThat (p61) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.4.3 MeansThat (p61)	 in a coherent way into merged SACM metamodel

Issue 16803: Incorporate 11.4.4 IsCharacterizedBy (p62) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.4.4 IsCharacterizedBy (p62)	 in a coherent way into merged SACM metamodel

Issue 16804: Incorporate 11.4.5 IsScopedBy (p62) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.4.5 IsScopedBy (p62)	 in a coherent way into merged SACM metamodel

Issue 16805: Incorporate 11.5.1 EvidenceObservation (abstract) (p64) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.5.1 EvidenceObservation (abstract) (p64)	 in a coherent way into merged SACM metamodel

Resolution: 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>>
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Class 'Conflicts' change rolename 'assertion1' to 'subject'
change rolename 'assertion2' to 'assertion'
Class 'Contributes' change rolename 'relation1' to 'subject'
change rolename 'relation2' to 'relation

Issue 16806: Incorporate 11.5.2 Conflicts (p64) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.5.2 Conflicts (p64)	 in a coherent way into merged SACM metamodel

Resolution: The resolution to this issue is provided by the related issue 16805 Disposition: Merged
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16808: Incorporate 11.5.4 Weakens (p65) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.5.4 Weakens (p65)	 in a coherent way into merged SACM metamodel

Issue 16809: Incorporate 11.5.5 Amplifies (p65) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.5.5 Amplifies (p65)	 in a coherent way into merged SACM metamodel

Issue 16810: Incorporate 11.6.1 EvidenceResolution (abstract) (p66) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.6.1 EvidenceResolution (abstract) (p66)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

remove EvidenceGroup from EvidenceResolution diagram,
replace with EvidenceElement with rolename 'subject'
remove Rationale element

Issue 16811: Incorporate 11.6.2 Negates (p67) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.6.2 Negates (p67)	 in a coherent way into merged SACM metamodel

Issue 16812: Incorporate 11.6.3 Refutes (p67) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.6.3 Refutes (p67)	 in a coherent way into merged SACM metamodel

Issue 16813: Incorporate 11.6.4 Resolves (p68) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.6.4 Resolves (p68)	 in a coherent way into merged SACM metamodel

Issue 16814: Incorporate 11.7.1 EvidenceGroup (p69) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	11.7.1 EvidenceGroup (p69)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16815: Incorporate 12.1.1 AdministrativeElement (abstract) (p71) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.1.1 AdministrativeElement (abstract) (p71)	 in a coherent way into merged SACM metamodel

Resolution: 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.
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Summary of changes:
rename to ProjectElement
change superclass to EvidenceElement
remove id attribute (now gets it through EvidenceElement and ModelElement)
add element to EvidenceElements
make this element a superclass for Originator
make this element superclass for CollectionMethod
Simplify diagram ProjectActivities: create diagram ProjectElements with Activity, ProjectObjective and
EvidenceRequest showing superclass to ProjectElement; add CollectionMethod and Stakeholder elements;
rearrange element descriptions (part of the content goes into another diagram ProjectProperties, see related
resolution 16818)
Related resolutions: 16818 (AdministrativeProperty), 16830 (Originator), 16311
(Originator), 16816 (EvidenceContainer) 16836 (SACM Common elements).

Issue 16816: Incorporate 12.1.2 Package (p72) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.1.2 Package (p72)	 in a coherent way into merged SACM metamodel

Resolution: Change text page 91 from Administration package defines key framework elements that determine patterns for constructing representations of evidence information. into This chapter describes the elements of the SACM Evidence Metamodel that are involved in managing evidence, exchanging units of evidence and related concerns. The elements described in this chapter organize instances on Evidence Metamodel, which can be referred to as an Evidence Model. In particular, this chapter defines the root object of Evidence Models - the EvidenceContainer. This element contains other objects in an evidence project and constitutes a unit of exchange using the Evidence Metamodel as the protocol. Rename section 15.1.2 Package into 15.1.2. EvidenceContainer Change text pages 92-93 from Package element is the root element that owns EvidenceItem, EvidenceEvaluation elements, as well as other auxiliary elements related to the processes of evidence identification, collection, interpretation, evaluation, and management. Superclass AdministrativeElement Attributes • consistency:ConsistencyLevel Globally unique identifier of a SACM evidence element. • version:String version of the package. • criteria:StandardOfProof Standard of Proof used for evaluation of evidence. • completeness:CompletenessLevel Level of completeness of the evidence package. Association • :requiresPackage[0..*] List of other evidence packages that are required by this package. • item:EvidenceItem[0..*] List of evidence items. • evaluation:EvidenceEvaluation[0..*] List of evaluations. • method:CollectionMethod[0..*] List of evidence collections methods, including tools. • originator:Originator[0..*] List of personnel and organizations involves in evidence collection project. • request:Request[0..*] List of evidence collection requests. • activity:Activity[0..*] List of project activities. • objective:ProjectObjective[0..*] List of project objectives. Constraints • Package shall not be the object of the requiresPackage relation owned by the Package, either directly or indirectly through requiresPackage of other Packages. • Any Package that is the object of the requiresPackage relation shall be available for exchange. • [Completeness of the package with respect to required packages] Any Element that is referenced by any of the Element that defined in the package (i.e., that are members of the lists item, evaluation, method, originator, request, activity, and objective of the Package) shall be also defined in the Package or in one of the Package that are referred to as objects of the requiresPackage relation either directly or indirectly. An Element is referenced if it is an object of an EvidenceProperty or an EvidenceEvaluation. • EvidenceProperty, EvidenceEvaluation, EvidenceRequest, EvidenceAction, ProjectObjective elements shall not be referenced across packages. Semantics Package element is the root element of an Evidence Model. A single Package is a unit of exchange. All Element defined in Package are exchanged together as part of the Package. Elements that are referenced shall be either present in the Package or in one of the Package that is specified as required for the Package. The Evidence Metamodel does not require completeness of the closure of all required packages. into EvidenceContainer element is the root object of the SACM Evidence Metamodel instances. This object owns EvidenceItem, and EvidenceEvaluation elements, as well as other ProjectElement related to the processes of evidence identification, collection, interpretation, evaluation, and management. Superclass EvidenceElement Attributes • name:String name of the EvidenceContainer. • gid:String Globally unique identifier of the EvidenceContainer. • version:String version of the EvidenceContainer. Association • item:EvidenceItem[0..*] List of evidence items. • evaluation:EvidenceEvaluation[0..*] List of evaluations. • element:ProjectElement[0..*] List project elements (objectives, activities, requests, methods, stakeholders). • property:ProjectProperty[0..*] List of project property clauses. Constraints • EvidenceContainer shall not be the object of the requiresContainer relation owned by the EvidenceContainer, either directly or indirectly through requiresContainer of other EvidenceContainers. • Any EvidenceContainer that is the object of the requiresContaienr relation shall be available for exchange. • [Completeness of the evidence container with respect to required evidence containers] Any Element that is referenced by any of the Element defined in the package (i.e., that are members of the lists item, evaluation, or element of the EvidenceContainer) shall be also defined in the EvidenceContaienr or in one of the EvidenceContainers that are referred to as objects of the requiresContaienr relation either directly or indirectly. An Element is referenced if it is an object of an EvidenceProperty or an EvidenceEvaluation. • EvidenceProperty, EvidenceEvaluation, EvidenceRequest, EvidenceAction, ProjectObjective elements shall not be referenced across evidence containers. Semantics EvidencePackage element is the root object of an instance of the Evidence Metamodel (which can be referred to as Evidence Model). A single EvidenceContainer is a unit of exchange of evidence information. All Element defined in an EvidenceContainer are exchanged together as part of the EvidenceContainer. Elements that are referenced shall be either present in the EvidenceContainer or in one of the EvidenceContaienrs that is specified as required for the EvidenceContainer. The Evidence Metamodel does not require completeness of the closure of all required packages. The properties of the EvidenceContainer element make assertions regarding the current container (use the current container as the subject of the corresponding clauses). Therefore, the following properties for an EvidenceContainer can be readily interpreted in the above way: RequiresContainer (for example, verbalized as "the EvidenceContainer requires container X1") ContainerConsistency (for example, verbalized as "the elements of the EvidenceContainer are interpreted formally") ContainerCompleteness (for example, verbalized as" the EvidenceContainer is in draft state") CompliesTo (for example, verbalized as "The EvidenceContainer complies to the Resolved Counter Evidence proof standard") All ProjectProperties clauses directly owned by an EvidenceContainer shall be interpreted with the EvidenceContainer as the main subject. For example, "The EvidenceContainer depends on evidentiary support rendered by exhibit E1 to the claim 'testing is completed'" Replace Figure 15.1 with the following (see also resolution 16815): <<figure on p 99 of ptc/2012-06-04>> Add section ProjectProperties to chapter 15 (see also resolution 16818). Move section 15.1.3 StandardOfProof (enumeration) to the new section Move section RequiresPackage to the new section. Rename section RequiresPackage into RequiresContainer Change section RequiresContainer to the following: RequiresContainer is an owned property of EvidenceContainer element. This element represents a statement asserting that the subject EvidenceContainer requires another evidence container for the resolution of some references. Superclass ProjectProperty Associations - container:EvidenceContainer[1] EvidenceContainer that is required for the resolutions of soem references in the subject evidence contaienr Constraints - RequiresContainer element shall not be owned by any ProjectElement object -subject EvidenceContainer shall no be the 'container' of the requiresContainer relation, either directly or indirectly, Semantics RequiresContainer property represents a state of affairs that the subject EvidenceContainer requires another evidence container for the resolution of some references. This property contributes to the completeness constraint of the EvidenceContainer. This is a commitment to the set of evidence containers that need to be processed together. Add section ContainerConsistency as follows: ContainerConsistency ContainerConsistency element is a counterpart of the Consistency property of Documents. ContainerConsistency clause makes an assertion about the subject EvidenceContainer regarding the level of formality of the element of the container. In combination with other container properties, such as ContainerCompleteness and CompliesTo, this clause determines capability to interpret the elements of this container. Consistency of an EvidenceContainer can be informal, semiformal and formal. Superclass ProjectProperty Attributes value:ConsistencyLevel asserted Consistency level of the elements of the EvidenceContainer, such as informal, semi-formal, and formal. Add section ContainerCompleteness as follows: ContainerCompleteness ContainerCompleteness element is a counterpart of the Completeness property of Documents. ContainerCompleteness clause makes an assertion about the subject EvidenceContainer regarding the level of completeness of the element of the container. In combination with other container properties, such as ContainerConsistency and CompliesTo, this clause determines capability to interpret the elements of this container. Completeness of an EvidenceContainer can be incomplete, draft, final and obsolete. Superclass ProjectProperty Attributes value:CompletenessLevel asserted Completeness level of the elements of the EvidenceContainer, such as incomplete, draft, final and obsolete. Add section CompliesTo as follows: CompliesTo CompliesTo clause makes an assertion about the subject EvidenceContainer regarding the standard of proof used for the evaluation of evidence in the EvidenceContainer. In combination with other container properties, such as ContainerConsistency and ContainerCompleteness, this clause determines capability to interpret the elements of this container. Completeness of an EvidenceContainer can be incomplete, draft, final and obsolete. Attributes criteria:StandardOfProof Standard of Proof used for evaluation of evidence in the subject container. Add section ExtendedProjectProperty as follows: ExtendedProjectProperty ExtendedProjectProperty element represents a user-defined characteristic documents that is asserted during the course of evaluation for the project elements in the subject container. Superclass ProjectProperty Constraints • ExtendedProjectProperty element shall own at least one TaggedValue informally describing the meaning of the element. Semantics ExtendedProjectProperty is a user-defined characteristic. Its meaning is represented by the key-value pair of the corresponding TaggedValue element. ExtendedProjectProperty characteristic can not be verbalized using the standard vocabulary of the Structured Assurance Case Metamodel. However, the key and value pair may be carefully named to result in meaningful verbalizations for the targeted community in the selected language. Replace Figure 15.2 ProjectProperties (shows as part of 16818) as follows: <<diagram on p 101 of ptc/2012-06-04>>
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Summary of changes:
rename Package into EvidenceContainer
collapse all AdministrativeElements into one list based on the superclass to facilitate extensibility and ease
of use
introduce common ProjectPropoerties
decouple Package attributes into explicit ProjectProperties, in compliance with the modelling style and to
simplify reuse between different parts of SACM
Related resolutions: 16815, 16818

Issue 16817: Incorporate 12.1.3 StandardOfProof (enumeration) (p73) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.1.3 StandardOfProof (enumeration) (p73)	 in a coherent way into merged SACM metamodel

Resolution: 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)".
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

The list of attributes for this element misses "Generalogical Proof Standard (GPS)" item,
referred to in the Semantics section. Add this item and rename to "Resolved Counter
Evidence Proof Standard (RCE)" as few people in the target audience care about the field
of Genealogy. Related change made as part of resolution 17309.

Issue 16818: Incorporate 12.1.4 AdministrativeProperty (abstract) (p74) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.1.4 AdministrativeProperty (abstract) (p74)	 in a coherent way into merged SACM metamodel

Resolution: Rename section 15.1.4 AdministrativeProperty (abstract) into ProjectProperty (abstract) (page 92) Change definition of AdministrativeProperty from AdminstrativeProperty is an abstract class that represents owned properties of AdminstrativeElement. This class is added to enhance the readability of the model. into ProjectProperty represents statements related to the structure of ProjectElement. These statements are predicate clauses where the main clause describes some project element. The subject of the ProjectProperty clause is a ProjectElement. Rename superclass of ProjectProperty to EvidenceProperty Add class ProjectProperty to EvidenceAssertions class diagram Change semantics from Defined by concrete subsclasses into Defined by concrete subclasses Add section ProjectProperties Class Diagram move section 15.1.4 ProjectProperty (abstract) to the new section Add Figure ProjectProperties Class Diagram <<diagram on p 103 of ptc/2012-06-04>> Move section 15.4.4 HasRoleIn to the new section change superclass of HasRoleIn from EvidenceProperty to ProjectProperty add Constraints section as follow: - ProjectElement shall not be affiliated with self, either directly or indirectly Remove class RequiresTool (the corresponding section is missing in the document, so it does not need to be removed) Move section 15.2.6. DependsOn to the new section change superclass of the DependsOn to ProjectProperty (page 97) Change text on page 97 from DependsOn element represents a relationship between the owner Activity element and another Activity element that is identified as the activity attribute of the DependsOn element. into DependsOn element represents a relationship between the owner project element and another project element that is identified as the element attribute of the DependsOn element. DependsOn element is a clause where the main subject is the ProjectElement that owns the current element. For example, this clause can be used to specify dependencies between Activities in an evidence collection project. Change associations from activity:Activity[1] Activity that the current activity depends on. into element:ProjectElement[1] Project element that the subject element depends on. Change semantics section from DependsOn element represents a state of affairs that the owner Activity is associated with another Activity identified as the activity attribute of the DependsOn element. into DependsOn element represents a state of affairs that the subject project element depends on another project element identified as the 'element' attribute of the DependsOn element. In Constraints subsection, change text 'Activity' into "ProjectElement'. Remove class isAssociatedWith and the corresponding section 15.2.5, page 97 Remove class RequiresMethod and the corresponding section 15.2.4 page 97 Move section 15.2.3. Satisfies, page 96 to the new section Change the superclass of the Satisfies element to ProjectProperty Change the associations from objective:ProjectObjective[1] Project objective that is satisfied by the activity. into element:ProjectElement[1] Project element that is satisfied by the current element. Change text from Satisfies element represents a relationship between the owner Activity element and a ProjectObjective object that is identified as the objective attribute of the Satisfies element. into Satisfies element represents a relationship between the owner project element and another project element that is identified as the element attribute of the Satisfies element. The Satisfies element is a clause where the main subject is the ProjectElement that owns the current element. For example, this clause can be used to specify that a certain Activity satisfies a certain ProjectObjective in an evidence collection project. Change associations of Satisfies into element:ProjectElement[1] Project element (such as a ProjectObjective) that is satisfied by the subject project element Change the semantics subsection from Satisfies element represents a state of affairs that the owner Activity object satisfies the ProjectObjective identified as the objective attribute of the ProjectObjective element. into Satisfies element represents a state of affairs that the owner project element satisfies another ProjectElement (such as a ProjectObjective) identified as the 'element' attribute of the Satisfies element. Other changes to the ProjectProperties Class Diagram are described in the related resolution 16816 (EvidenceContainer)
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

Summary of changes:
rename to ProjectProperty
add to EvidenceAssertions
change superclass to EvidenceProperty
Simplify ProjectActivities diagram: rename to ProjectProperties, move HasRoleIn,
DependsOn, Satisfies, RequiresPackage. Add EvidenceContainer properties.
change superclass of HasRoleIn
DependsOn, Satisfies
rename RequiresPackage into RequiresContainer
remove classes RequiresTool, RequiresMethod
upgrade association type of object for DependsOn from Activity to ProjectElement                                                                                     upgrade object for Satisfies to ProjectElement
Related resolutions: 16815 (AdministrativeElement), 16830 (Originator), 16311
(Originator), 16816 (EvidenceContainer) 16836 (SACM Common elements).

Issue 16819: Incorporate 12.1.5 RequiresPackage (p74) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.1.5 RequiresPackage (p74)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16820: Incorporate 12.2.1 Activity (p75) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.2.1 Activity (p75)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16821: Incorporate 12.2.2 ActivityProperty (abstract) (p76) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.2.2 ActivityProperty (abstract) (p76)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16822: Incorporate 12.2.3 Satisfies (p76) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.2.3 Satisfies (p76)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16823: Incorporate 12.2.4 RequiresMethod (p77) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.2.4 RequiresMethod (p77)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16824: Incorporate 12.2.5 IsAssociatedWith (p77) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Incorporate	12.2.5 IsAssociatedWith (p77)	 in a coherent way into merged SACM metamodel

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16825: Incorporate 12.2.6 DependsOn (p77) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16826: Incorporate 12.3.1 CollectionMethod (abstract) (p78) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 16827: Incorporate 12.3.2 Service (p79) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 16828: Incorporate 12.3.3 Method (p79) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 16829: Incorporate 12.3.4 Tool (p79) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 16830: Incorporate 12.4.1 Originator (abstract) (p80) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Discussion:

This is a useful class that facilitates creation of structured statements about evidence. No
change is required (other than those already achieved by the restructuring of the element's
superclasses, addressed elesewhere).
Note, that there is a separate (earlier) issue suggesting a rename of 'Originator' element of
the Evidence Metamodel (issue 16311). It will be addressed separately as the scope of the
current issue is related to the changes in the metamodel (this is one of the issues raised
mechanically against the Evidence Metamodel elements).
Disposition: Merged

Issue 16831: Incorporate 12.4.2 Person (p80) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 16832: Incorporate 12.4.3 Organization (p81) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 16833: Incorporate 12.4.4 HasRoleIn (p81) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Issue 16834: Incorporate 12.5.1 EvidenceRequest (p82) in a coherent way into merged SACM metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 29, 2011: received issue
September 13, 2012: closed issue

Issue 16836: Integration issue: An overall goal is to integrate the ARM and SAEM specifications into SACM in a coherent way. (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Discussion:

Summary of changes:
add Common diagram
move ModelElement
add SACMElement
add TaggedValue to ModelElement,
change rolename to tag
add Annotation to ModelElement
change rolename to annotation
change superclass to UtilityElement
add association from InformationElement in ARM to EvidenceItem in EM
add association from ReferencedClaim in EM to Claim in ARM
move primitive datatypes diagram to SACM package

Issue 16839: Integration Issue: Combined scope needs to include original scopes, and any emergent scope (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Issue 16840: Integration issue: introductory text should cover SAEM introductory material (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Integration issue: introductory text should cover SAEM introductory material

Resolution: 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)
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Discussion:

Original introductory material for the Evidence Metamodel has been included into the convenience
document. This resolution provides additional editing.

Issue 16845: Lack of agreement the attribute types for some of the evidence evaluation subtypes - e.g. confidence 0..100 as integer (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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. "
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Discussion:

This issue is also related to issue 16841 (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). This issue has
been deferred to the future RTF, however the remaining part is to make sure that " SACM
rev 1 allows users to 'opt out' of some of the prescribed subtypes in SAEM through the
inclusion of a new general evidence attribute and document attribute. "
This issue 16845 is also related to Evidence and Document attributes and their values.
Response - "leaving it as is, but also adding general evidence evaluation subtype (name
value tuple) so that users are not forced to use existing concrete subtypes. Defer further
discussion on the enumerated types to RTF".
Therefore, the following issues are merged together with the general issue 16845 and
resolved by adding a concrete subclass of EvidenceAttribute called
ExtendedEvidenceAttribute and a concrete subclass of DocumentAttribute called
ExtendedDocumentAttribute for which user defined values can be added by a general
Tag-Value mechanism provided through common supertypes:
16781 SupportLevel
16783 ReportingLevel
16785 AccuracyLevel
16787 ConfidenceLevel
16790 Level
16793 OriginalityLevel
16795 ConsistencyLevel
16797 CompletenessLevel
16799 ReliabilityLevel
This issue 16845 describes the common resolution.
Note that the extended concrete classes are limited to the so-called "attributes
(EvidenceAttribute and DocumentAttribute) and do not cover other Evidence Evaluations
(such as for example EvidenceRelation) or Evidence Properties (such as for example
Timing) since Evidence Attributes and Document Attributes are 1-ary properties having
only a single subject - an Evidence Item, while Evidence Evaluations and Evidence Properties are more complex 2-ary properties which can not be extended by the simple
Tag-Value mechanism (require both the subject and the object).

Issue 16846: evidence evaluation attributes (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Issue 16847: No AssuranceCase Element in either ARM or SAEM - necessary for a Structured Assurance Case Metamodel (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: This issue has been resolved due to resolutions of related issues 16855. Disposition: Merged
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Issue 16848: If AssertedRelationships are genuinely Assertions then they should be subtypes of Assertion (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Issue 16851: counter evidence and challenge should be better modelled by a polarity attribute on the relation (AB comment) (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Discussion:

Response: Reject - CounterEvidence and Challenge need to be highly visible element,
placing it as an attribute would reduce this visibility (and potentially will restrict future
further integration with SBVR and SAEM elements).
Disposition: Closed, no change

Issue 16852: Using the term 'Argument' as the container for the "Claims-Argument-Evidence" aspect of ARM is confusing as people expec (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text:
Actions taken:
November 30, 2011: received issue
September 13, 2012: closed issue

Discussion:

This issue has been originally raised by S Barnum (MITRE)
Agreed resolution is to rename the “Argument” class to be “Argumentation”, in
conjunction with related edit to move “AssertedLinks” to be kinds of “Assertions”
Related issue: 16848 (id=141)

Issue 16855: We need a common route to support instance packaging (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Discussion:

Assurance Case is the packaging element in Part 1 (overarching and common) Argumentation is the
packaging element in Part 2 Package is the packaging element in Part 3, will name change to
EvidenceContainer.
The new AssuranceCase element is a subclass of ModelElement so that TaggedValues and Annotations can
be added to it (this was a special request from Sam).

Issue 16856: Metamodel packaging should broadly align with ARM/SAEM elements (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Issue 16857: Need a revised compliance point approach (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Issue 16858: The detailed enumerated attributes in SAEM need a corresponding location in SACM (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Issue 16859: exchanged model instances should indicate which compliance points have been satisfied (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

exchanged model instances should indicate which compliance points have been satisfied

Resolution: This is achieved by observing the top element. See related resolution 16855. Disposition: Closed, no change
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Issue 16860: Combined specification should have routes and guidance broadly corresponding to ARM and SAEM (sacm-ftf)

Click here for this issue's archive.
Source: AIST (Dr. Kenji Taguchi, kenji.taguchi(at)aist.go.jp)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: This resolution has been merged with 16857. Disposition: Merged
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Discussion:

Issue 16862: The frontispiece sections (introduction, background, scope etc) needs to be edited to reflect integration (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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".
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Discussion:

Merging has been done when the initial convenience document was produced. Perform additional editorial
changes.

Issue 16865: motivate link groups (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

(a missing issue) to motivate link groups

Resolution: 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
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Issue 16866: Need to clarify usage of “nature of dependency” to indicate this is not for evidential or argumentation relations (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Issue 16867: Question of how to characterize the identity of the “artifact-as-such”, as well as its URN (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Discussion:

Issue 16868: Need to provide motivation (the underlying issue) for new “link group” (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: This issue is related to a now obsolete intermediate model of ARM and is not longer applicable. Disposition: Closed, no change
Revised Text:
Actions taken:
December 1, 2011: received issue
September 13, 2012: closed issue

Issue 16879: Name AssertedEvidence (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution: Rejected - keep as ARM Disposition: Closed, no change
Revised Text:
Actions taken:
December 9, 2011: received issue
September 13, 2012: closed issue

Issue 16881: Needed assurance case compliance point (sacm-ftf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: This resolution has been merged with 16857. Disposition: Merged
Revised Text:
Actions taken:
December 9, 2011: received issue
September 13, 2012: closed issue

Issue 17309: Wrong figure in Evidence Evaluation example (sacm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: 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"
Revised Text:
Actions taken:
April 13, 2012: received issue
September 13, 2012: closed issue

Issue 17316: Evidence Metamodel needs a Record element (sacm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution: 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>>
Revised Text:
Actions taken:
April 19, 2012: received issue
September 13, 2012: closed issue

Discussion:

Related resolutions 16815, 16729

Issue 17347: Argument metamodel needs improvement (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


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


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


I propose the following changes:


Create a new Assertion class, as a subclass of ReasoningElement


Set the Claim class to be a subclass of Assertion


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


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


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


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

Resolution: 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>>
Revised Text:
Actions taken:
May 1, 2012: received issue
September 13, 2012: closed issue

Discussion:

Agree, the proposed changes would simplify the model and make it more coherent as ARM is integrated
into SACM.
Related issue 16848, 16692, 16852.

Issue 17354: ArgumentReasoning should also attach to AssertedChallange (sacm-ftf)

Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Minor
Summary:

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


Argumentation metamodel:
ArgumentReasoning should also attach to AssertedChallange

Resolution: 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>>
Revised Text:
Actions taken:
May 5, 2012: received issue
September 13, 2012: closed issue

Discussion:

This seems reasonable, since argument reasoning describes an inference, it should also be able to describe a
challenge. Propose to add new association “describedChallenge:Challenge[0..*]” to ArgumentReasoning
Class in a similar way to association to AssertedInference

Issue 17369: Association names should be nouns (sacm-ftf)

Click here for this issue's archive.
Source: Adelard LLP (Mr. Luke Emmet, loe(at)adelard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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


Title: Association names should be nouns


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

Resolution: 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>>
Revised Text:
Actions taken:
May 15, 2012: received issue
September 13, 2012: closed issue

Discussion:

This seems reasonable, propose to rename the associations in the argumentation part of SACM as follows:
Aggregation collections – remove names as these are collections, change simply to be aligned with
contained element
refersToArgument -> argumentationReference
refersToArgumentelement ->argumentElementReference
hasStructure ->structure
describes -> describedInference

Issue 17432: Incorrect URL for SACM in Appendix B (sacm-ftf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity:
Summary:

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


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


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


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

Resolution: 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>
Revised Text:
Actions taken:
June 19, 2012: received issue
September 13, 2012: closed issue

Issue 17433: Duplicate rolename 'subject' in class 'ProvidesContext' (sacm-ftf)

Click here for this issue's archive.
Source: KDM Analytics (Dr. Nikolai Mansourov, nick(at)kdmanalytics.com)
Nature: Revision
Severity:
Summary:

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

Resolution: 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>>
Revised Text:
Actions taken:
June 19, 2012: received issue
September 13, 2012: closed issue