all concept Stereotypes shall be prefixed SCM_ , cleanup stale diagrams

CHANGES.md

@@ -2,6 +2,7 @@
 # SAF User Documentation : Changes
 |Date|Change|
 |--|--|
+|2024-06-18.1|* all Stereotypes from SCM_Profile are prefixed "SCM_", not "SAF_"|
 |2024-06-15.1|* write down naming conventions for table and matrix representations of Viewpoints (postfixed with "_Matrix" and "_Table"<BR>* Rename stereotypes accordingly (SAF_L8_LFUM_Matrix, SAF_O8_OPRM_Table, SAF_F8_SCYM_Table, SAF_O8_OCYM_Table, SAF_F8_SRQT_Matrix, SAF_F6_SRQD_Table, SAF_C7_PRND_Table, SAF_C2_TRMD_Table)<BR>* new, because there is a table representation. They're currently not covered by example : SAF_F3_SSTA_Table, SAF_F3_SPRO_Table, SAF_F2_SDIK_Table, SAF_F1_SUCS_Table, SAF_F1_SCXE_Table, SAF_F1_SCXD_Table<BR>* apply coloring legend to all viewpoint concept and profile diagrams, and redactional corrections<BR>* In Grid Definition Viewpoint, the Implementation of Viewpoint is changed to a user usable SAF_Viewpoint defined by SAF Profile, late  the SAF_Viewpoint in SCM profile will be renamed to SCM_Viewpoint, since it is used to specify SAF, and not to be intendet to be used in system models.<BR>* Add a library of SAF_Viewpoint objects to SAF_Profile to be used to plan modeling using grid Definition VP. The viewpoint objects collect automatically all views(diagrams conform to the Viewpoint)<BR>* SAF_LogicalContextRole did not inherit from part property<BR>* remove exposure of elements related to domain item kinds in SDIK, since It is by no way covered by concerns of VP SDIK. |
 |2024-06-12.1|* make internal role stereotypes inherit from part property<BR>* dont expose abstract general physical role, but derived non abstract concepts PFUM and PLOM, partly adressing issue #60<BR>* rename stereotypes for PLOM and PFUM Diagrams to *_Matrix, because the Representation is a matrix.<BR>* logical element role was'nt exposed in PLOM|
 |2024-06-07	.1|Argument concept in argumentation assurance viewpoint is no longer abstract, issue #56<BR>Separate network PIEX view, issue #57|

developing-saf/concept/concepts.md

@@ -20,7 +20,7 @@ This argument concept is used to claim that a conclusion about the whole object
 ## Argument Substitution
 This argument concept is used to claim that if a property holds for one object, then it holds for an equivalent object. Similarly, if a property holds for some object, then an equivalent property will also hold for the same object. The nature of the equivalence will vary with the object and property and will need to be defined.
 ## Aspect
-realized by Stereotype [SAF_AspectColumn](../../stereotypes.md#SAF_AspectColumn)
+realized by Stereotype [SCM_AspectColumn](../../stereotypes.md#SCM_AspectColumn)
 
 Aspects capture a set of characteristics or features of the Entity of Interest in its Environment to address Concerns within an Architecture Description.
 ## Asset
@@ -64,7 +64,7 @@ realized by Stereotype [SAF_CounterClaim](../../stereotypes.md#SAF_CounterClaim)
 
 A party's claim is a counter-claim if one party asserts claims in response to the claims of another.
 ## Domain
-realized by Stereotype [SAF_DomainLayer](../../stereotypes.md#SAF_DomainLayer)
+realized by Stereotype [SCM_DomainLayer](../../stereotypes.md#SCM_DomainLayer)
 
 
 ## Evidence

developing-saf/development.md

@@ -10,17 +10,20 @@ There are several kinds of models around SAF serving a certain purpose
 
 * **SAF System Model**
 
-  This is a model dedicated to the development of one or more systems. It is a model that users of SAF create and maintain. It may be maintained in one of the Tools supported by a SAF Profile Implementation Model. The SAF example models are System Models.
-* **SAF Profile Implementation Model**
+  This is a model dedicated to the development of one or more systems. It is a model that users of SAF create and maintain. It may be maintained in one of the Tools supported by a SAF Profile Model. The SAF example model SAF_FFDS.mdzip is a System Model.
+* **SAF_Profile Model**
   This is a model needed to create a SAF System Model. It is tool specific and (hopefully) compliant to the SAF Specification. There are currently several contributed models:
 
   * [SAF-Cameo-Profile](https://github.com/GfSE/SAF-Cameo-Profile)
   * [SAF-Rhapsody-Profile](https://github.com/GfSE/SAF-Rhapsody-Profile)
   * [SAF-EA-Profile](https://github.com/GfSE/SAF-EA-Profile)
 
   The Repositories usually also contain an example System Model
-* **Conceptual Model**
-  The conceptual model contains the definitions serving as foundation for SAF development. See the following chapter for details
+* **SAF_Specification Model**
+  The specification model contains the definitions serving as foundation for SAF development. See the following chapter for details.
+
+* **SAF_SCM_Profile Model**
+  The SAF SCM Profile is used by the SAF_Specification model. It contains Stereotypes used to specify concepts, viewpoints, framework concerns and stakeholders. It is used to specify or extend SAF.
 
 ## Conceptual Model
 
@@ -35,7 +38,7 @@ Within the conceptual model the following elements can be recognized (many of th
 * **SAF Architecture Framework Stakeholders**
  are classes of users having an interest on the information that is maintained in a SAF System Model.
 * **SAF Architecture Framework Concerns**
- sketch out the information need of SAF Architecture Framework Stakeholders, which in turn should be adressed by a SAF System Model.
+ sketch out the information need of SAF Architecture Framework Stakeholders. The SAF Frameworks Viewpoints shall be designed in a way to frame these concerns, and in the end the information need should be adressed by a SAF System Model using the appropriate SAF Viewpoints.
 * **SAF Rationale**
  expains why a SAF Architectur Framework Stakeholder has abovementionend information need resulting in a SAF Architecture Framework Concern. This is currently not covered by ISO 42010.
 * **SAF Concepts**
@@ -47,6 +50,7 @@ select a set of SAF Concepts in order to adress the information need expressed b
  are like SAF Viewpoints but at a larger scale. They can group SAF Viewpoints while constraining them further. They also can be nested.
   This allows to specify Information Items like e.g. an ISO 29148 SyRS by breaking it down into smaller Information Items and finally into Viewpoints.
   This allows to define which concerns are to be adressed e.g. by a SyRS document and which viewpoints are needed for it.
+  They also could be used to plan work items in order to plan a MBSE effort.
   The goal is, to precisely define the needed model work for certain points in an engieering project.
 
 Details are documented in the [metamodeling guide](./metamodel-guideline/modelguideline.md).