Issue 16279: Need for general facility for stating and handling issues
Issue 16281: Scope of availability of change management information
Issue 16287: Uncertainty characteristic for claims
Issue 16289: Assurance Cases under development or Incomplete
Issue 16310: Ownership needs improved representation
Issue 16313: SBVR should be available in SACM for use wherever this would make sense
Issue 16505: Properties as Assertions
Issue 16506: Properties of Model Elements must be Distinguished from Properties of what they Represent
Issue 16507: Property Inherence Hierarchy
Issue 16509: Making Role Binding and SBVR more generally available
Issue 16510: Events should be able to be Associated with all Kinds of ModelElements
Issue 16511: Different Meanings of Different Variants/Versions of a Model Elements Need to be Labeled, e.g. for Claims
Issue 16514: Justification of Methods of Reasoning
Issue 16517: Usage of Specializations of Claim
Issue 16518: Need for Groups of Asserted Links
Issue 16519: Multiple Fact types/Rolebindings in a Claim Statement
Issue 16521: InformationAssertion Dependencies on other Elements
Issue 16693: ARM: Page 18, section 8.2.14
Issue 16694: ARM: Page 20, section 8.2.17
Issue 16712: Page73 ,section 13.2, figure21
Issue 16781: Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel
Issue 16807: Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel
Issue 16837: Integration Issue: Inconsistent terminology
Issue 16838: Integration Issue: Overlapping scope
Issue 16841: Integration Issue: Inconsistency in level of prescription in the models
Issue 16842: Integration Issue: Inconsistent approaches to handling counter argument and evidence
Issue 16843: No method of handling confidence in the ARM
Issue 16844: Issue: No approach to allowing Structured Expression of Claims within ARM
Issue 16849: prefixes in the SAEM 'Evidence....
Issue 16850: fundamental difference in modelling style of each metamodel
Issue 16853: There is no support for patterning, which is found to be useful current practice.
Issue 16854: Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...
Issue 16861: combined standard should include a vocabulary for talking about standards of proof
Issue 16863: All associations need to be labeled with a verb
Issue 16864: We are missing an SBVR vocabulary for ARM
Issue 16880: Assurance case composed of assurance cases
Issue 16882: EvidenceProperty inherit from Property
Issue 16883: Identifying nature of element contents
Issue 16884: Use name "Artfact" rather than Exhibit"
Issue 17334: Need examples of the Evidence Metamodel XMI
Issue 17335: Add missing definitions to SBVR Vocabulary in Annex A
Issue 17336: Use uniform 'statement' language for describing evidence properties
Issue 16279: Need for general facility for stating and handling issues (sacm-rtf)
Click here for this issue's archive.
Source: MITRE (Mr. Samuel Redwine, samredwine(at)verizon.net)
Nature: Revision
Severity: Significant
Summary:
As everything is disputable (that is, can be challenged) and issues of many natures can arise, a general “Issue” facility is required. This should also span all of SACM. Currently, “EvidenceObservation” is used in the sense of “comment” or “issue”. Its name could be changed and its availability be made more general. Possibly it should include a sub-element with a more general name for issues that do not fit into current sub-element categories (or possibly not yet categorized). While probably not belonging in the core compliance point, facilities for issue resolution need to be likewise generally applicable.
This seems a reasonable suggestion, apart from the proposed use of EvidenceObservation element. The purpose of the later is to make statements about evidence related to relations between other evidence statements. On the other hand, the Evidence Metamodel already includes a ProjectObjective element as well as an EvidenceRequest element. The former refers to an 'individual project requirement of an evidence collection project". The later represents a "placeholder for an EvidenceItem to be collected during the evidence collection project". The scope of the resolution to this issue should include the Argumentation Metamodel, in particular, the general solution should consider replacing the "toBeSupported" attribute of claims (see related issue 16692 and section 9.2.9 Claims). Further discussion on this topic is deferred to the future RTF. Disposition: Deferred
Timing or change management information needs to be able to be associated with anything as anything can change over time. This includes for example with Attributes (and any Properties). In addition, how to best handle changes and change information over time needs to be reviewed throughout SACM. The version and change management related information although often kept in a CM system needs to be exchangeable along with an assurance case. At least one exchange standard for CM information exists, TECHAMERICA EIA-836B: Configuration Management Data Exchange and Interoperability, publication date: Mar 1, 2010. It is reportedly both ANSI and DoD approved. (http://engineers.ihs.com/document/abstract/BMVKACAAAAAAAAAA) One option is for this to be appropriately included by reference. Versioning should be available for everything. Identification and “HasVersion” attribute should be associated with a near root element, or this availability should be achieved in some other fashion. The standard should not restrict its availability and smallness of possible granularity of elements it may be applied to.
The first part of the request has been already addressed through the resolutions 16730 and related. The second part of the request seems to be addressed (at least in part) through the element Supersedes. Further discussion on this topic is deferred to a future RTF. Disposition: Deferred
From the viewpoint of compatibility with ISO/IEC 15026, the most important issue is that SACM contain an "Uncertainty" characteristic or attribute, a key aspect of 15026-2, in order to facilitate use of SACM with ISO/IEC 15026 conformant assurance cases. These would be useful throughout SACM as attributes of assertions or claims (not relations). Current usage means a need exists for several data type options not necessarily mutually exclusive. Data Types • Probability true: 0-1.00 • Type I error: 0-1.00 • Type 2 error: 0-1.00 • Enumeration: None, low, medium, large, unknown • Standard deviation: real number One might also want to include a data type with customizable meaning (values: 1-100) that would parallel the data type for “Strength” in present draft if this is retained. This attribute element is associated with claims (assertions) and not with relations. Current SAEM draft defines characteristics such as “Strength,” and “Confidence” of evidence relations between an EvidenceItem (e.g. exhibit) and a DominAssertion. These relate to uncertainty but are associated with a relation and not with a DomainAssertion (claim). Note that the draft of SAEM states these are one-to-one relations unlike the many-to-one inferential relations in ARM.
This issue is related to the Argumentation Metamodel. It is deferred to the future RTF due to the lack of time to work on the resolution. Disposition: Deferred
SACM standard must accommodate assurance cases under development as this is expected to be a common usage transferring assurance cases among their developers or maintainers. This includes those incomplete. In addition to incompleteness, decisions may yet to be concerning option options including the type of certain relations e.g. does an inference relation challenge or not. As the relative distinctions are not always known, particularly early in assurance cases construction, which currently abstract classes should be concrete classes should be reviewed and changed as required to accommodate this. Recording explicit options yet to be decided among (and optionally their effects) could be useful (and also relevant to patterns). More elements similar in name to the UnknownSubject might be included if required to meet this need.
This issue is being deferred to the future RTF due to the lack of time to have a discussion. Disposition: Deferred
The following aspects need to be accommodated: Owning, creating, and approving can be done concurrently by multiple entities and different (sets of) entities over time. Ownership can be divided unequally among owners and fractions could need to be recorded. Ownership can have aspects, for example IP rights versus physical object I own the book, but not its copyright.
This issue is being deferred to the future RTF due to the lack of time to have a discussion. Disposition: Deferred
SBVR should be available in SACM for use wherever this would make sense. This includes in (ARM) claims and ReasoningElements and in SAEM many assertions particularly claims and possible rationales. Wherever narrative or prose, or mathematical expressions are allowed, why not also allow SBVR (and some places graphics or even other media also) unless strong reasons exist for doing otherwise?
This is a valid suggestion, however due to the lack of time any further discussion on this issue is deferred to the future RTF. Disposition: Deferred
The property elements of various kinds contain assertions concerning proper values for various properties (or attributes). Should they not therefore inherit from Assertion? This includes tagged values unless these are used to tag kinds of “annotations” instead of using general Annotation elements.
Although every property can be considered to be asserted, SACM focus is on argument structuring elements. Therefore no change made to inherit properties from assertion. Property class was removed, which did not bring much to the table. May consider reintroducing it. This is a unification between ARM and SAEM that cannot be achieved at this stage - Defer to RTF Disposition: Deferred
Obviously, properties that apply to Model Elements must be distinguishable from Properties of what they represent. Both these kinds of properties appear in SACM models. The issues titled “Property Inherence Hierarchy” states a way of doing this.
This is outside of the scope of the initial unification between ARM and SAEM; to be achieved at a later stage - Defer to RTF Disposition: Deferred
A simple, natural and appropriate set of properties would have Property (abstract?) inheriting from Assertion (or less preferably ModelElement) and having ModelElementProperty, RepesentedObjectProperty, Event, and Timing inheriting from it (Property) and appropriately associated. Artifacts and DomainObjects would use RepesentedObjectProperty’s. The two classes of properties are needed to allow properties associated with a model element and those associated with what it represents to be distinguished. Likewise ModelElementEvent and RepesentedObjectEvent inherit from Event. What type of event timing an instance is relevant to will be clear from what it is associated with. CM events and properties for both model elements and what they represent could be treated within this approach. Alternately, a usable set of properties could have Property inheriting from ModelElement and having ModelElementProperty, ArtifactProperty, DomainObjectProperty, Event, and Timing inheriting from it and appropriately associated. The three classes of properties are needed to allow properties associated with a model element and what it represents to be distinguished. Likewise ModelElementEvent, ArtifactEvent, and DomainObjectEvent inherit from Event. What type of event timing is relevant to will be clear from what it is associated with. CM events and properties could be treated likewise.
Covered above by reconsideration of reintroducing property abstract class. This is a unification between ARM and SAEM that cannot be achieved at this stage - Defer to RTF Disposition: Deferred
SBVR should be available for use within element contents everywhere unless strong, explicitly recorded reason exists for excluding it.
TPK: we could allow use of SBVR wherever there is a reliance on free text string, e.g. argument description DECISION: DEFER to RTF Disposition: Deferred
Not just exhibits have events that affect them or otherwise relate to them. This is also relavent to what the elements represent. An event might be associated with more than one element For example, one bug fix that simultaneously change several code exhibits/artifacts.
Agree that this is potentially a good ideas - However, defer to RTF Disposition: Deferred
Claims and other items can have versions that simultaneously exist but have different meanings. For example, what a Claim might represent includes: • Required values • Planned values to be achieved • Supported (established, justified) values Two or more of these can be relevant at the same time. A suggestion has been made that SBVR be used (within associated properties?) to make this distinction. This would require that SBVR be available for these contents. Use of a TaggedValue is another possibility. Regardless of what mechanism is used, some standardization should be included for the key meanings. Placing this distinction within the contents of claim true-false statement might be more awkward and not make it as readily handled by tools as having it reside in a property. In any case, what is standardized needs to have precise definitions or distinguishable among multiple definitions (or explicitly made usage/implementation dependent?) as subtle variations in meaning are possible. Note that for some assertions differences might be entirely in the value for confidence.
Response: This is out of scope. There are mechanisms (tagged values, annotations or an explicit claim) to support this. No model change. Although the initial response was to close this issue, it is an important concern, and since it is related to the use of SBVR to enhance the formality of assurance cases, the future RTF will include this issue for further consideration. Disposition: Deferred
How might and/or should the justification for an ArgumentReasoning element’s method(s) of argumentation be represented in SACM? Several options or possibilities exist. This justification might be a supplied by a Claim, a DescriptiveAssertion, or Assumption connected by an AssertedInference link or an AssertedConext link in turn potentionally supported by InformationElement, EvidenceElement, or Artifact. More generally justification for its method(s) of argumentation can be in the form of an assurance case. On the other hand might it be supplied by an AssertedContextLink to an Artifact or even simply a citation? What is the designers approach? Should these options be restricted or others used particularly for the link between the ArgumentReasoning element and justification of its methods? Should some approaches be preferred?
Action: check with TPK about what is mechanism for supporting warrants. Need to provide guidance to support use justification of ArgumentReasoning RESOLUTION: Need to ensure when describing AssertedInference that we include ArgumentReasoning (ARM) as possible target. This issue is related to the Argumentation Metamodel. It is deferred to the future RTF due to the lack of time to work on the resolution. Disposition: Deferred
May a specialization of Claim element appear anywhere a Claim may? and vice versa? In June Day 2 diagram allows Calims in Augumentation elements but not InformationElements. However, InformationAssertions can appear both places. What is the reasoning behind this? One might consider questions such as: For example, do restrictions exist on where an InformationAssertion may appear? Why should not a Claim element be used in place of each of the kinds or elements that inherit from it (e.g. in 2011 June Day 2)?
N/A to current ARM, Deferred to RTF Disposition: Deferred
Asserted links are already one-to-many, but only one is allowed at the supported-by (single) end. However, a strong case can be made for being able to have multiple ones and being able to group them. Substantial discussions both leading to the conclusion this should be included occurred during two FTF meetings most recently in June 2011. Unfortunately, this occurred as the last discussion at the June meeting and exactly how best to do it (e.g. element names) evidentially due to time constraints was not judged firmly enough agreed upon to appear in the diagram resulting from this meeting. This still needs to be included/finalized.
Deferred as keeping with current arrangement in ARM (1.. many). Disposition: Deferred
Claim true-false statements in SBVR can contain a variety of kinds of concerns. A variety of terms and values can occur. The diagram appears to show/allow only one facttype. Is this appropriate?
Deferred - SBVR for claims in ARM to be looked at only in RTF Disposition: Deferred
An InformationAssertion, particularly a ResultsAssertion, will commonly depend on other elements particularly EvidenceElements and Artifacts. These can be shown by AssertedLinks, but hould they also be able to be shown by HasDependenceOn.
Defer to RTF Disposition: Deferred
: In the AssertedInference class, the invariants leave the possibility of inferring an AssertedRelationship from a set of claims. They do not, however, allow a Claim to be inferred from an AssertedRelationship. Since an AssertedRelationship is a kind of claim (not in the sense of the model, but in a general sense), it seems reasonable to allow it; that is, “I claim A because of the relationship between claims B and C”.
One may want to state the context in which an AssertedRelationship holds. At present, the invariants on AssertedContext disallow this.
response - will remove the constraint to make it possible This issue is related to the Argumentation Metamodel. It is deferred to the future RTF due to the lack of time to work on the resolution. Disposition: Deferred
Some of the concepts being captured in the model here overlap quite strongly with those of Configuration Management, and would probably best left to standards in that domain rather than creating a conceptual overlap here.
Incorporate 11.2.2 SupportLevel (enumeration) (p52) in a coherent way into merged SACM metamodel
Incorporate 11.5.3 Contributes (abstract) (p64) in a coherent way into merged SACM metamodel
Integration Issue: Inconsistent terminology
Inconsistencies are minor, bidirectional associations added between Domain Claim and Claim, InformationElement and EvidenceItem. Overlap Issues - deferred to RTF. Resolution: Deferred to RTF Disposition: Deferred
Integration Issue: Overlapping scope
Defer to RTF (we're aware of overlaps, but these cannot be easily resolved at this stage). Disposition: Deferred
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.
Majority of this issue is deferred to RTF. However, 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. The corresponding changes will be made in related issue 16845. See also related issue 16854. Disposition: Deferred
Integration Issue: Inconsistent approaches to handling counter argument and evidence. Both standards have evaluation mechanisms (e.g. refuting, rebutting mechanisms)
Defer to RTF Disposition: Deferred
No method of handling confidence in the ARM
Defer explicit inclusion of confident in ARM to RTF Disposition: Deferred
Issue: No approach to allowing Structured Expression of Claims within ARM
Defer - will not be done in this revision - currently out of scope - will be looked at in RTF Disposition: Deferred
The name 'Evidence' implies a certain association between some Information / some artefact and some claim. In ARM it was recognised that information can be used both to define context and as supporting evidence to an assertion. This suggests that many of the prefixes in the SAEM 'Evidence....' should be changed to allow them to more generally refer to Information (and specialise to Evidence if required)
Defer to RTF Disposition: Deferred
There is a fundamental difference in how modelling style of each metamodel. For example SAEM has a more "fact oriented" (nouns and verbs) approach which has a simpler MOF implementation. ARM has classes instead.
While the modeling style of the Evidence Metamodel was considered beneficial because of the stronger alignment with SBVR and more formal approach to representing claims and using structured natural language with the formal semantics, the discussion to how to accommodate this style in the Argumentation metamodel is deferred to the RTF. Disposition: Deferred
There is no support for patterning, which is found to be useful current practice.
Defer to RTF - support for patterns desirable but too difficult at this stage Disposition: Deferred
Evidence evaluation attributes in SAEM overlap in purpose - e.g. insufficient distinction between Strength and ...
insufficient distinction of the subclasses on Figure 11.2 in SAEM Resolution of the subclasses will be deferred to RTF. But there will be new subclass of EvidenceAttribute that will allow user to 'dodge' the current subclasses. The corresponding changes will be made in related issue 16845. See also related issue 16854. Disposition: Deferred
combined standard should include a vocabulary for talking about standards of proof
Situation is that it will exist in SAEM part, but not ARM. Unification is Deferred to RTF Disposition: Deferred
All associations need to be labeled with a verb
Defer to RTF Disposition: Deferred
We are missing an SBVR vocabulary for ARM (authors view - this is work someone else to do, maybe close/postpone)
We are not going to attempt to allow SBVR for ARM elements - DEFER to RTF Disposition: Deferred
An assurance case should be able to be composed of assurance cases. This can both math the history of development of the larger assurance case and potentially be a mechanism facilitating structuring and reuse.
Agreed - Assurance Case Element will be allowed to contain Assurance Case Element There is a tricky issue with respect to use of Global identifiers in nested cases. Disposition: Deferred
With integration EvidenceProperty inherit from Property as should all properties - directly or indirectly.
Unification of properties is not being attempted at this stage. Defer to RTF. Disposition: Deferred
2. What is needed to be known by tool or human is information required to establish the meaning of its content (interpret it) for this the notation/means used to express contents needs to be identified. An associated property could do this and with more power/flexibility as any notation could be identified. Among other things, one should not presume that multiple tool vendors would never chose to support a (mathematically) formal notation other than SBVR. The use of different element types to identify nature of contents as “informal” or “structured” would be overkill. Rather, rename/combine “Consistency,” “ IsExpressed InLanguage”or other element to NotationUsed and provide appropriate attributes.
Defer to RTF (It's a comment for improvement, rather than a 'correction') Disposition: Deferred
The term “Exhibit” should be replaced with Artifact” because some Exhibits/Artifacts are not evidentiary but are descriptive or, for example, provide definitions in other words they have other roles than exhibits constituting evidence.
The term 'Artifact' has advantage of being slightly more general, which may address the purely descriptive elements that are not being presented in support of any claims, but rather simply for the illustration purposes, usually in order to establish some context. However, in the Evidence field, the term 'Exhibit' is adopted. For example, according to Wikipedia: Exhibit (legal), evidence in physical form brought before the court. Demonstrative evidence is a term used to describe exhibits and other physical forms of evidence used in court to demonstrate, show, depict, inform or teach relevant information to the viewer. On the other hand, the term 'artifact' may put too much emphasis on a man-made origin of a 'thing': 1 an object made by a human being, typically an item of cultural or historical interest : gold and silver artifacts. • Archaeology such an object as distinguished from a similar object naturally produced. 2 something observed in a scientific investigation or experiment that is not naturally present but occurs as a result of the preparative or investigative procedure : widespread tissue infection may be a technical artifact. According to Wikipedia, the term 'artifact' refers to 'Objects', in particular : • Artifact (archaeology), an object formed by humans, particularly one of interest to archaeologists • Artifact (software development), one of many kinds of tangible byproducts produced during the development of software • Document artifact, an instantiation of a document • Social artifact, a product of individuals or groups (social beings) or of their social behavior • Virtual artifact, an object in a digital environment These usages introduce some 'noise'. SO, maybe we can keep distinction between Exhibits as objects (natural or mad-made) that are being presented in support of claims, and Objects, that are more generic in nature. However, this point is rather irrelevant, since the most common type of Objects are Documents or Records. Discussion on this issue is deferred to a future RTF. Disposition: Deferred
The Evidence Metamodel specification missed examples of the XMI. Such examples are present in the Argumentation Metamodel and significantly increase the clarity of the specification.
This issue is deferred to the future RTF due to the lack of time. Disposition: Deferred
The SBVR vocabulary for evidence in Annex A is missing several definitions.
This issue is being deferred to a future RTF due to the lack of time Disposition: Deferred
Various evidence properties and attributes represent 'statements' about evidence. Specification needs to be systematically edited to introduce this language.
This issue is deferred to a future RTF due to the lack of time. Disposition: Deferred