SAF Ontology Elements
The Elements of the SAF Ontology are listed in the following Table. The Table contains two kinds of Elements:
- Relations between Elements that are subject or objects. These are documented in a "triple Form", e.g. Function - Has- Parameter.
- Elements used as subject or objects
| Concept | Documentation | Base Concept | Specific Concept | Viewpoint |
|---|---|---|---|---|
| 1 Argument AGTsupportingCLM 1..* Claim | Specifies the fact that a claim is supported by one or more arguments via a claim-argument relation. | Argumentation Assurance Viewpoint | ||
| 0..* Abstract Physical Element APEbeeingInSSE 0..* System State | Specifies the fact that a Physical System Element can be in distinct states. | |||
| 1 Abstract Physical Element APEimplementingGFN 1..* General Function | ||||
| 0..* Any SAF Element ASFconformToSTD 0..* Standard | Specifies, that a SAF Element may be conform to one or more Standards. | Common Standards Definition Viewpoint | ||
| Abstract Physical Element | Abstract element representing physical structure items keeping properties and relations applicable to all physical items. | Physical SOI , Physical Element , Hardware Element , Software Element | ||
| Any SAF Element | A concept used only together with relational concepts to specify that the relation goes to any other SAF Concept. | |||
| Argument | An argument is a rule that provides the bridge between what we know or are assuming (sub-claims, evidence) and the claim we are investigating. The argument used depends on the type, trustworthiness and extent of available evidence and the nature of the claim. | Claimable Item | Argument Decomposition , Argument Substitution , Argument Concretion | Argumentation Assurance Viewpoint |
| Argument Concretion | This argument concept is used when a claim needs to be given a more precise definition or interpretation. | Argument | ||
| Argument Decomposition | This argument concept is used to claim that a conclusion about the whole object or property can be deduced from the claims or facts about constituent parts. Decomposition argument blocks can also be used to incorporate defeaters into the case. | Argument | ||
| 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. | Argument | ||
| Aspect | Aspects capture a set of characteristics or features of the Entity of Interest in its Environment to address Concerns within an Architecture Description. | Framework Viewpoint Overview Viewpoint | ||
| 0..* CounterClaim CCMcounteringCIM 0..* Claimable Item | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is countered by one or more claims. | Argumentation Assurance Viewpoint | ||
| 1..* Context Function CFNallocatedToLCE 1 Logical Context Element | Specifies the fact that a Context Function is assigned to a Logical Context Element. Note: This fact may be derived from the Usage of Function of a Context Function allocated to a Logical Context Element. | |||
| 1 Claim CLMbeingMadeAboutSBC 0..1 Subject of Claim | Specifies the fact that a claim is made about an identified subject matter. | Argumentation Assurance Viewpoint | ||
| 0..* Claim CLMsupportingCIM 0..* Claimable Item | Specifies the fact that any claimable item, e.g., claim, argument, and evidence, is supported by one or more claims. | Argumentation Assurance Viewpoint | ||
| 1 Claimant CLTmakingCLM 1..* Claim | Specifies the fact that a claim is made by a defined claimant. | Argumentation Assurance Viewpoint | ||
| 1 Compliance Statement CSTconfirmingSHR 1 Stakeholder Requirement | Specifies the fact that a Stakeholder Requirement has certain States of Compliance. | Stakeholder Requirement Definition Viewpoint | ||
| 1 Connection CallowingE 0..* Exchange | Specifies the fact that a connection allows Exchange to happen | |||
| Category Of Standard | Specifies categories in which the standard could be categorized , e.g., a data exchange format or a protocol standard, or categories as national, company or international standard. | Common Standards Definition Viewpoint | ||
| Claim | A claim is a true/false statement about a property of a particular object. A claim is just what you might consider it to be from common usage of the term; an idea that someone is trying to convince somebody else is true. An example claim could be made on a train, e.g., the train is safe. | Claimable Item | Argumentation Assurance Viewpoint | |
| Claimable Item | A claim, argument, and evidence are all types of the abstract concept of a claimable item. This allows a counter-claim to be made about any type of claimable item and a claim to support any type of claimable item. | Claim , Argument | ||
| Claimant | A party asserting claims. | Argumentation Assurance Viewpoint | ||
| Compliance Statement | Used in the communication between Stakeholder (Customer) and Contractor. Compliance Statements are the first answer to the Stakeholder Requirements and are usually together with the Stakeholder Requirements part of the contract. They are valuable input for the System development and System Requirement elicitation. Information status: * not compliant (with explanation / rationale) * partially compliant (with explanation / rationale) * fully compliant | Stakeholder Requirement Definition Viewpoint | ||
| Concern | Specifies an information need that a stakeholder of the SAF needs to be satisfied within an MBSE approach using SAF. | Framework Stakeholder and Concern Definition Viewpoint | ||
| 1 Interaction Point Connection 1 Interaction Point | Specifies the connection of two interaction points. | |||
| Context Function | Specifies the fact that a fundamental action or task is expected to be carried out by an External Entity. Note: The intention is to capture the expectations and to explicitly dissect the functionality. This must not be interpreted as an attempt for a behavior specification of an External Entity. Capturing this valuable information is the basis to reach agreement on the functionality at the System boundary by clarifying the expectations about what is performed by Context Elements. | General Function | System Process Viewpoint , System Functional Breakdown Structure Viewpoint | |
| 0..* Context Function Context Function IN System Process 0..* System Process | Specifies the fact that a Context Function is used in a System Process. | General Functional Usage | System Process Viewpoint , System Functional Breakdown Structure Viewpoint | |
| CounterClaim | A party's claim is a counter-claim if one party asserts claims in response to the claims of another. | Argumentation Assurance Viewpoint | ||
| Domain | Domain captures viewpoints that belong together within typical SE workflow stages. | Framework Viewpoint Overview Viewpoint | ||
| 1 Exchange EEfromSM 1 System | Specifies that an exchange comes from a system | |||
| 1 Exchange EEtoSM 1 System | Specifies that an exchange goes to a system | |||
| 1 Exchange Kind EKtypingE 0..* Exchange | Specifies the fact that a Exchange Kind defines the type of a Exchange. | |||
| 1 Exchange Kind EKtypingIPP 0..* Interaction Point Property | Specifies the fact that a Exchange Kind defines the type of a Interaction Point Property. | |||
| 1..* Evidence EVCreinforcingAGT 1..* Argument | Specifies the fact that an argument is reinforced by one or more evidence via a argument-evidence relation. | Argumentation Assurance Viewpoint | ||
| Evidence | An evidence is an artifact that establishes facts that can be trusted and lead directly to a claim. In projects there can many sources of information, but what makes this evidence is the support or rebuttal it gives to a claim. | Argumentation Assurance Viewpoint | ||
| Exchange | Specification for general item exchange (energy, material, information, etc.). | |||
| Exchange Kind | Specification for a general kind of item (energy, material, information, etc.) to be exchanged. | |||
| 1..* Functional Requirement FRboundedByNFR 0..* Non-functional Requirement | Specifies the fact that a Non-Functional Requirement constrains Functional Requirements. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint | ||
| 1..* Functional Requirement FRrefiningSFN 1 System Function | Specifies the fact that a System Function is refined by Functional Requirements. | System Requirement Traceability Viewpoint | ||
| Functional Requirement | Functional Requirements specify System Functions of the System. | System Requirement | System Requirement Definition Viewpoint | |
| 1 Grid GDcontainingAT 1..* Aspect | Specifies that the grid is composed of several aspects. | Grid Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 1 Grid GDcontainingDN 1..* Domain | Specifies that the grid is composed of several domains. | Grid Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 1 Grid GDcontainingVP 1..* Viewpoint | Specifies that the grid contains multiple viewpoints | Grid Definition Viewpoint | ||
| 1 General Function Exchange Point GFEPrelatedToGFUEP 1 General Function Usage Exchange Point | specifies that a General Functional Exchange Point is related to a General Function Usage Exchange Point | |||
| 0..* General Functional Exchange GFEbeingPartOfGFNU 1 General Functional Usage | Specifies the fact that a Functional Exchange appears within a general Functiona Usage. | System Functional Refinement Viewpoint | ||
| 1 General Functional Exchange GFEfromGFUEP 1 General Function Usage Exchange Point | Specifies the fact that a General Functional Exchange is coming from a General Functional Usage Exchange Point. | |||
| 1 General Functional Exchange GFEtoGFUEP 1 General Function Usage Exchange Point | Specifies the fact that a General Functional Exchange is going to a General Functional Usage Exchange Point. | |||
| 1 General Functional Usage GFNcontrolledAFTER 1 General Functional Usage | Specifies a sequential execution of Functions. | System Process Viewpoint , System Functional Refinement Viewpoint | ||
| 1 General Function GFNreceivingINPUT 0..* General Function Exchange Point | Specifies the Input of a General Function. | |||
| 1 General Function GFNsendingOUTPUT 0..* General Function Exchange Point | Specifies the Output of a General Function. | |||
| 1 General Functional Usage GFUEPreceivingINPUT 0..* General Function Usage Exchange Point | Specifies the Input of a Functional Usage. | |||
| 1 General Functional Usage GFUEPsendingOUTPUT 0..* General Function Usage Exchange Point | Specifies the Output of a Functional Usage. | |||
| 1 Glossary GYcontainsTRM 0..* Term | specifies that a glossary contains a number of terms. A term is contained only in one glossary. | |||
| 1 General Scenario Participation General Chronological Message 1 General Scenario Participation | Ordered sequential occurrence of exchanges between General Interaction Scenario Participants. | |||
| General Context | Specifies a General Context. | System Context , Operational Context | ||
| General Context Element | Specifies a General Context Element. | System | System Context Element , Operational Performer | |
| 1..* General Context Element General Context Element Role 1..* General Context | Specifies the fact that a General Context Element exists in a given General Context. | System Role | System Context Element Role , Operational Context Role | |
| General Function | Specifies a General Function. It is used as base Class for specific System or Context Functions, or Partial Functions. | System Function , System Partial Function , Context Function | ||
| General Function Exchange Point | A Exchange Point of a Function Usage | |||
| General Function Usage Exchange Point | A parameter of a System or Context Function. | System Process Viewpoint , System Functional Refinement Viewpoint | ||
| General Functional Exchange | Specifies the fact that an General Functional Exchange between General Function Parameters is taking place. | System Process Viewpoint , System Functional Refinement Viewpoint | ||
| 1 General Function General Functional Usage 0..* General Function | Specifies a General Usage of a General Function within one or more other General Functions. | Context Function IN System Process , System Function IN System Process , System Partial Function in System Function | Logical Functional Mapping Viewpoint | |
| General Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between General Interaction Scenario Participants. | |||
| General Physical Role | General concept of usage of system elements in the context of other system elements on physical level. | Software Element Role , Physical Hardware Role , Physical Software Role , Hardware Element Role , Physical Element Role | ||
| General Scenario Participant | ||||
| 0..* General Context Element Role General Scenario Participation 0..* General Interaction Scenario | Specifies the fact that a System Role participates in a General Interaction Scenario. | |||
| Glossary | specifies a coherent set of terms. | |||
| Goal | A Goal is defined as an end state that a Stakeholder intends to achieve. Goals are generally expressed using qualitative words; e.g., “increase”, “improve”, or “easier”. Goals can also be decomposed; e.g., “increase profit” can be decomposed into the Goals “reduce cost” and “increase sales”. However, it is also very common to associate concrete objectives with Goals, which can be used to describe both the quantitative and time-related measures which are essential to describe the desired state, and when it should be achieved. | |||
| Grid | The grid manages the viewpoints in grid cells assigned to the categories of an domain (row) and an aspect (column). | Grid Definition Viewpoint | ||
| Hardware Element | Pure Hardware Elements. Similarity with the V-Model "hardware unit". | Abstract Physical Element | Physical Structure Definition Viewpoint , Physical Internal Exchange Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Hardware Element Hardware Element Role 0..* Hardware Element | Specifies the fact that a hardware structure comprises hardware elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Interaction Point Definition IPDtypingIP 0..* Interaction Point | Specifies the fact that an Interaction Point Definition defines the exchange capabilities of an Interaction Point. | |||
| 0..* Interaction Point Property IPPisDetailOfIPD 1 Interaction Point Definition | Specifies the fact that an Interaction Point Property is a detail of an Interaction Point Definition. | |||
| Interaction Point | Specifies the existence of an interaction point. | |||
| Interaction Point Definition | Specifies the exchange capabilities of an interaction point on Physical Level. | |||
| Interaction Point Property | Specifies a detail of an interaction point. | |||
| 1..* Logical Context Element LCEactingInSUC 1..* System Use Case | Specifies the fact that a Logical Context Element acts in one or more System Use Cases. | System Use Case Viewpoint | ||
| 0..* Logical Context Element Role LCEperformingCFN 0..* Context Function IN System Process | Specifies the fact that a Context Function is expected to be carried out by the Logical Context Element in this System Context. | System Process Viewpoint | ||
| 1 Logical Connection LCNallowingLIE 0..* Logical Item Exchange | Specifies the fact that a Logical Item Exchange is allowed on the Logical Connection. | Logical Internal Exchange Viewpoint | ||
| 0..* Logical Interaction Point LCPboundedByPLS 0..1 Physical Layer Stack | Specifies the fact that a Logical Interaction Point is constrained to be implemented on a particular Physical Layer Stack. | |||
| 1..* Logical Environment LENconceptingPEN 1..* Physical Environment | Specifies the fact that a logical Environment Entity is a concept for a Physical Environment Entity. | |||
| 1..* Logical Element Role LERspecifyingGPR 1 General Physical Role | Specifies that a usage of a Logical Element specifies functions for the usage of a Physical Element. | Physical Logical Mapping Viewpoint | ||
| 1..* Logical External System LESconceptingPES 1..* Physical External System | Specifies that the Logical System is a concept for a Physical System. | |||
| 0..* Logical Element LETbeeingInSSE 0..* System State | Specifies the System States a Logical Element can be in. | System State Viewpoint | ||
| 1..* Logical Element LETimplementingGFN 1..* General Function | Specifies the fact that a Logical Element is responsible to implement a System Function. Note: Logical Elements don't "implement" anything, they pass the function implementation task to Physical Elements. | Logical Functional Mapping Viewpoint | ||
| 1..* Logical SOI Role LETperformingSFN 1..* System Function IN System Process | Specifies the fact that a System Function is expected to be carried out by the SOI in this System Context. | System Process Viewpoint | ||
| 1..* Logical Element LETspecifyingAPE 1 Abstract Physical Element | Specifies the fact that one or more Logical Element specifies exactly one Physical Element. Rationale: If more than one Physical Element would offer to realize the functionality specified by a Logical Element the responsibility would be ambiguous. It is okay to assign several Logical Elements to one Physical Element. This means all specified functionality assigned to the Logical Elements is to be implemented by the Physical Element. Note, that typically the usage of logical elements in a context is mapped to the usage of physical elements in a context (allocation of usage). Thus this relationship between the definitions is derived. | |||
| 0..* Logical Item Exchange LIEboundedByPL 0..1 Physical Layer | Specifies the fact that a Logical Item Exchange is constrained to be implemented on a particular Physical Layer. | |||
| 0..* Logical Item Exchange LIEboundedByPLS 0..1 Physical Layer Stack | Specifies the fact that a Logical Item Exchange is constrained to be implemented on a particular Physical Layer Stack. | |||
| 0..* Logical Item Exchange LIEimplementsOIE 0..* Operational Item Exchange | specifies that this exchange in the FD implements (possibly partly) that exchange in the OD | |||
| 1 Logical Interaction Point Definition LIPDdefiningDetailOfLIP 0..* Logical Interaction Point | Specifies the fact that a Logical Interaction Point Definition defines the exchange capabilities of a Logical Interaction Point. | System Interface Definition Viewpoint , Logical Internal Exchange Viewpoint | ||
| 0..* Logical Interaction Point Property LIPPspecifyingDetailOfLIPD 1 Logical Interaction Point Definition | Specifies the fact that a Logical Interaction Point Property is a detail of a Logical Interaction Point Definition. | System Interface Definition Viewpoint , Logical Internal Exchange Viewpoint | ||
| 0..* Logical Interaction Point LIPapplyingToLCE 1..* Logical Context Element | Specifies the fact that a Logical Interaction Point applies to a Logical Context Element. | System Context Exchange Viewpoint | ||
| 0..* Logical Interaction Point LIPapplyingToLET 1 Logical Element | Specifies the fact that a Logical Interaction Point applies to a Logical Element. | System Context Exchange Viewpoint , Logical Internal Exchange Viewpoint | ||
| 1 Logical Interaction Scenario LIScontainingILCM 0..* Logical Chronological Message | Specifies the fact that an Internal Logical Interaction Scenario contains one or more Internal Logical Chronological Messages. | |||
| 1..* Logical User LURconceptingPUR 1..* Physical User | Specifies that the Logical user is a concept for a Physical User. | |||
| 1 Logical Scenario Participation Logical Chronological Message 1 Logical Scenario Participation | Ordered sequential occurrence of exchanges between Logical Interaction Scenario Participants. | Logical Internal Interaction Viewpoint | ||
| 1 Logical Interaction Point Logical Connection 1 Logical Interaction Point | Specifies the connection of two interaction points on Logical Level. Note: Connections between logical components indicate that item flows are passed from one output of a source component to one or more inputs of target components. | System Context Exchange Viewpoint , Logical Internal Exchange Viewpoint | ||
| Logical Context Element | Represents an abstract element in the given System Context on Logical Level, outside the SOI scope, interacting with the SOI. | Logical Environment , Logical External System , Logical User | ||
| 1..* Logical Context Element Logical Context Element Role 1..* Logical System Context | Specifies the fact that a Logical Context Element exists in a given Logical System Context. | System Context Role | System Process Viewpoint , System Context Exchange Viewpoint , System Context Definition Viewpoint , System Context Interaction Viewpoint | |
| Logical Context SOI | Represents the Logical SOI in the System Context on Logical Level. | Logical Element | System Context Definition Viewpoint , Logical Structure Definition Viewpoint | |
| Logical Element | Describes a conceptual Logical Element as specification for an implementation of a system, or system element. | Logical Context SOI | Logical Structure Definition Viewpoint , Logical Internal Exchange Viewpoint , Logical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Logical Element Logical Element Role 0..* Logical Element | Specifies the fact that a logical element comprises logical elements. | Logical Structure Definition Viewpoint , Logical Internal Interaction Viewpoint , Logical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | ||
| Logical Environment | A Logical Environment in the Logical Domain, outside the SOI scope, interacting with the SOI. E.g., air, dirt, sun, road. | Logical Context Element | System Use Case Viewpoint , System Context Definition Viewpoint | |
| Logical External System | A Logical External System in the Logical Domain, outside the SOI scope, interacting with the SOI. E.g., power grid, mobile network, fresh water system (in a house). | Logical Context Element | System Use Case Viewpoint , System Context Definition Viewpoint | |
| Logical Interaction Point | Specifies the existence of an interaction point on Logical Level. | System Requirement Traceability Viewpoint , System Context Exchange Viewpoint , System Interface Definition Viewpoint , Logical Internal Exchange Viewpoint | ||
| Logical Interaction Point Definition | Specifies the exchange capabilities of an interaction point on Logical Level. | System Context Exchange Viewpoint , System Interface Definition Viewpoint , Logical Internal Exchange Viewpoint | ||
| Logical Interaction Point Property | Specifies a detail of an interaction point on Logical Level. | System Interface Definition Viewpoint , Logical Internal Exchange Viewpoint | ||
| Logical Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between Logical Interaction Scenario Participants. | Logical Internal Interaction Viewpoint | ||
| Logical Item Exchange | Specifies the exchange that is to take place on a connection of two interaction points on Logical Level. | System Context Exchange Viewpoint , Logical Internal Exchange Viewpoint | ||
| 1 Logical Context SOI Logical SOI Role 1..* Logical System Context | Specifies the fact that a Logical Context SOI exists in a given Logical System Context. | System Context Role | System Process Viewpoint , System Context Exchange Viewpoint , System Context Definition Viewpoint , System Context Interaction Viewpoint | |
| 0..* Logical Element Role Logical Scenario Participation 0..* Logical Interaction Scenario | Specifies the fact that a Logical Element Role participates in a Logical Interaction Scenario. | Logical Internal Interaction Viewpoint | ||
| Logical System Context | Specifies the fact that a System Context for a System of Interest is defined on Logical Level. | System Use Case Viewpoint , System Context Exchange Viewpoint , System Context Definition Viewpoint | ||
| Logical User | The Logical User is the representation for a human in the Logical Domain, outside the SOI scope, interacting with the SOI. | Logical Context Element | System Use Case Viewpoint , System Context Definition Viewpoint | |
| Need | A User has a Need in order to reach a certain Goal. Note: "Buying sugar to bake a birthday cake". | |||
| Non-functional Requirement | Non-Functional Requirements specify the quality of System Functions, or non-functional requests like legal conformance. | System Requirement | System Requirement Definition Viewpoint | |
| 1 Operational Connection OCNallowingOIE 0..* Operational Item Exchange | Specifies the fact that an Operational Item Exchange is allowed on the Operational Connection. | |||
| 1 Operational Capability OCYcomposedOF 0..* Operational Capability | Specifies the fact that an Operational Capability consists of other Operational Capabilites. | Operational Capability Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Operational Capability OCYdependingON 0..* Operational Capability | Specifies the fact that an Operational Capability depends on another Operational Capability. Aliases: UAF::CapabilityDependency | Operational Capability Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 1 Operational Capability OCYspecializedBY 0..* Operational Capability | Specifies the fact that an Operational Capability is specialized by other Operational Capability. Aliases: UAF::CapabilityGeneralization | Operational Capability Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Operational Capability OCYsupportingOSY 0..* Operational Story | Specifies the fact that an Operational Story is supported by Operational Capabilities. | Operational Capability Mapping Viewpoint | ||
| 1 Operational Domain Kind ODKcomposedOF 0..* Operational Domain Kind | Specifies the fact that an Operational Domain Kind consists of one or more Operational Domain Kinds. | Operational Domain Item Kind Viewpoint | ||
| 1 Operational Domain Kind ODKtypifyingOIE 0..* Operational Item Exchange | Specifies the fact that an Operational Domain Kind typifies an Operational Item Exchange. | |||
| 1 Operational Domain Kind ODKtypifyingOPE 0..* Operational Process Exchange | Specifies the fact that an Operational Domain Kind typifies an Operational Process Exchange. | Operational Process Viewpoint | ||
| 1 Operational Interaction Scenario OIScontainingOCM 0..* Operational Chronological Message | Specifies the fact that an Operational Interaction Scenario contains one or more Operational Chronological Messages. | |||
| 1..* Operational Interaction Scenario OISrefiningOSY 1 Operational Story | Specifies the fact that an Operational Story is refined by one or more Operational Interaction Scenarios. | |||
| 1..* Operational Performer OPRactingInOSY 1..* Operational Story | Specifies the fact that an Operational Performer acts in an Operational Story. | Operational Story Viewpoint | ||
| 0..* Operational Performer OPRcapableOFperformingOPS 0..* Operational Process | Specifies the fact that an Operational Performer performs an Operational Activity. Traceability from Operational Activities to Operational Performers is derived via assignment of Operational Action to Operational Roles. Aliases: UAF::IsCapableToPerform | Operational Process Mapping Viewpoint | ||
| 1 Operational Performer OPRcomposedOF 0..* Operational Performer | Specifies the fact that an Operational Performer consists of one or more Operational Performers. | Operational Performer Viewpoint | ||
| 1 Operational Performer OPRexhibitingOCY 0..* Operational Capability | Specifies the fact that an Operational Performer exhibits an Operational Capability under specific environmental conditions. | Operational Capability Mapping Viewpoint | ||
| 0..* Operational Context Role OPRperformingOPSU 0..* Operational Process Usage | Specifies that an Operational Context Role uses an Operational Process in the context of an other Operational Process. | Operational Process Viewpoint | ||
| 0..* Operational Process OPSenablingOCY 0..* Operational Capability | Specifies the fact that an Operational Process contributes to the provision of one or more Operational Capabilities in the field. Aliases: UAF::MapsToCapability | Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Operational Process OPSrefiningOSY 1 Operational Story | Specifies the fact that an Operational Story is refined by one or more Operational Processes. | Operational Process Mapping Viewpoint | ||
| 1..* Operational Story OSYtakingPlaceInOCT 1 Operational Context | Specifies the fact that an Operational Story occurs in a certain Operational Context. Note: When parts of an Operational Story do occur in several contexts, they shall be duplicated. | Operational Story Viewpoint | ||
| Operational Capability | A Operational Capability is a high-level description or specification of an organizational unit's ability to execute a specified course of action, to implement a business process or to provide a service. Operational Capabilities typically require people, processes, infrastructure, technology and supporting systems to be implemented. A Operational Capability is an enduring element, its implementation may change over time. A necessary or desired change of a Operational Capability triggers the updated of involved systems or the integration new systems. Aliases: UAF::Capability NAF4::Capability | System Capability Definition Viewpoint , System Capability Mapping Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Capability Definition Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| 1 Operational Scenario Participation Operational Chronological Message 1 Operational Scenario Participation | Ordered sequential occurrence of exchanges between Operational Interaction Scenario Participants. | Operational Context Interaction Viewpoint | ||
| 1 Operational Context Role Operational Connection 1 Operational Context Role | Specifies the connection between Operational Context Roles in an Operational Context allowing Operational Item Exchange. Aliases: UAF::OperationalConnector | Operational Context Exchange Viewpoint | ||
| Operational Context | An Operational Context is representing a separate Usage Scenario with a specific configuration of Operational Performers, these are interacting in the Scenario exhibiting a specific identified Operational Capability. One or more Operational Contexts meaningful for the Operational Domain are to be identified. Aliases: UAF::HighLevelOperationalConcept | General Context | Operational Story Viewpoint , Operational Context Definition Viewpoint , Operational Context Exchange Viewpoint | |
| 1..* Operational Performer Operational Context Role 1..* Operational Context | An Operational Context Role represents a participant in an Operational context. It is interacting with other roles of the given Operational Context. Specific characteristics and features or, in case of persons or organizational units, knowledge and skills are assigned to a role necessary for the execution of the performed Operational Processes. | General Context Element Role | Operational Context Interaction Viewpoint , Operational Context Definition Viewpoint , Operational Process Viewpoint , Operational Context Exchange Viewpoint | |
| Operational Domain Kind | Specifies the kind of Operational Item Exchange between Operational Context Roles or Operational Processes. | Operational Process Viewpoint , Operational Context Exchange Viewpoint , Operational Domain Item Kind Viewpoint | ||
| Operational Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between Operational Interaction Scenario Participants. | Operational Context Interaction Viewpoint | ||
| Operational Item Exchange | Specifies the Operational Item Exchange that is to take place on an Operational Connection. Aliases: UAF::OperationalExchange | Operational Context Exchange Viewpoint | ||
| Operational Performer | An Operational Performer is an element of the Operational Context that is capable to perform Operational Process Activities contributing to a specific identified Operational Capability. An Operational Performer may be any kind of organization, person, or even a system playing a role in one or more Operational Contexts. Aliases: UAF::OperationalPerformer | General Context Element | Stakeholder Identification Viewpoint , Operational Story Viewpoint , Operational Context Definition Viewpoint , Operational Process Viewpoint , Operational Performer Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | |
| Operational Process | An Operational Process captures activity-based operational behavior including scenarios, activity actions, and operational exchange flows, e.g., including information, materials, natural resources, etc. Aliases: UAF::Operational Activity NAF::Logical Activity | Operational Process Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| 1 Operational Process Operational Process Exchange 1 Operational Process | Specifies the fact that an Operational Process has an exchange with another Operational Process. | Operational Process Viewpoint | ||
| 1 Operational Process Operational Process Usage 0..* Operational Process | Specifies the fact that an Operational Process is used in context of another Operational Process. Aliases: UAF::OperationalAction | Operational Process Viewpoint | ||
| 1..* Operational Context Role Operational Scenario Participation 0..* Operational Interaction Scenario | Specifies the fact that an Operational Context Role participates in an Operational Interaction Scenario. | Operational Context Interaction Viewpoint | ||
| Operational Sketch | Specifies a free form sketch depicting a concept. | Operational Story Viewpoint | ||
| Operational Story | The Operational Story represents one or more Operational Use Cases in the Usage Scenario identified by the Operational Context. The Operational Story is described as narrative story-telling. | System Use Case Viewpoint , Operational Story Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Process Mapping Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Physical Connection PCCapplyingToPCN 0..1 Physical Connector Compatibility | Specifies the fact that a Physical Connector Compatibility Assertion shall apply to a Physical Connection. | |||
| 1 Physical Connector Compatibility PCCassertsCompatibiltyForPCPD 2 Physical Interaction Point Definition | Specifies the Physical Interaction Point Definition the Physical Compatibility Assertion is valid for. | |||
| 1 Physical Connection PCNallowingPIE 0..* Physical Item Exchange | Specifies the fact that a Physical Item Exchange is allowed on the Physical Connection. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| 1 Physical Interaction Point PCPOverPCP 1 Physical Interaction Point | Specifies the fact that a physical interaction point communicates / transfers / flows / over an other physical interaction point. Used to define layered physical interfaces, and show layer relationships between interfaces. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| 1 Physical Interaction Point Property PCPPOverPCPP 1 Physical Interaction Point Property | Specifies the fact that a physical interaction point property communicates / transfers / flows / over an other physical interaction point property. Used to define layered physical interfaces, and show layer relationships between interface details. | Physical Interface Definition Viewpoint | ||
| 0..* Physical Interaction Point PCPisPartOfPIPD 1 Physical Interaction Point Definition | specifies that a physical interaction point can be a part of a physical interaction point definition. This fosters reuse and allows structuring of definitions. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| 0..1 Physical Layer PEKisAssignedToPL 0..* Physical Exchange Kind | Specifies the fact that a Physical Exchange Kind is assigned to a particular Physical Layer. | |||
| 1..* Physical Exchange Kind PEKrealizingSDK 1 System Domain Kind | Specifies the fact that a System Domain Kind is realized by Physical Exchange Kinds. | Physical Logical Item Mapping Viewpoint | ||
| 1 Physical Exchange Kind PEKtypingPIE 0..* Physical Item Exchange | Specifies the fact that a Physical Exchange Kind defines the type of a Physical Item Exchange. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| 1 Physical Exchange Kind PEKtypingPIPP 0..* Physical Interaction Point Property | Specifies the fact that a Physical Exchange Kind defines the type of a Physical Interaction Point Property. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| 1 Physical Interaction Point Definition PIPDdefiningDetailOfPIP 0..* Physical Interaction Point | Specifies the fact that a Physical Interaction Point Definition defines the exchange capabilities of a Physical Interaction Point. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| 0..* Physical Interaction Point Property PIPPspecifyingDetailOfPIPD 1 Physical Interaction Point Definition | Specifies the fact that a Physical Interaction Point Property is a detail of a Physical Interaction Point Definition. | Physical Interface Definition Viewpoint | ||
| 0..* Physical Interaction Point PIPapplyingToAPE 1 Abstract Physical Element | Specifies the fact that a Physical Interaction Point applies to an Abstract Physical Element. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| 0..* Physical Interaction Point PIPapplyingToPCE 1 Physical Context Element | Specifies the fact that a Physical Interaction Point applies to a Physical Context Element. | Physical Context Exchange Viewpoint | ||
| 1 ProfileItem PIimplementsSEC 1..* SE Concept | specifies that a stereotype from the SAF profile implements a concept | Framework Viewpoint Implementation Viewpoint | ||
| 0..* Physical Layer Ordering PLOisValidInPLS 1 Physical Layer Stack | Specifies the fact that a Physical Layer Ordering is valid within a particular Physical Layer Stack. | |||
| 1 Physical Interaction Point Physical Connection 1 Physical Interaction Point | Specifies the connection of two physical interaction points. Note: Connections between physical components indicate that item flows are passed from one output of a source component to one or more inputs of target components. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| Physical Connector Compatibility | Specifies the fact that two Physical Interaction Point Definitions are compatible and how the Physical Interaction Point Properties are mapped. | |||
| Physical Context Element | Abstract element of a System Context on Physical Level, outside the SOI scope, interacting with the SOI. | Physical External System , Physical User , Physical Environment | ||
| 1..* Physical Context Element Physical Context Element Role 1..* Physical System Context | Specifies the fact that a Physical Context Element exists in a given Physical System Context. | Physical Context Definition Viewpoint | ||
| Physical Element | A composition of Hardware and Software Elements. Similarity with the V-Model segments and system. See [VXT]. | Abstract Physical Element | Physical Structure Definition Viewpoint , Physical Internal Exchange Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Physical Element Physical Element Role 0..* Physical Element | Specifies the fact that a physical structure comprises physical elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Physical Environment | The Physical Environment in the Physical Domain, outside the SOI scope, interacting with the SOI. E.g. air, dirt, sun, road. | Physical Context Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint | |
| Physical Exchange Kind | Specification for any kind of physical item (energy, material, information, etc.) to be exchanged on Physical Level. This is the realization of the specification made by System Domain Kinds. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint , Physical Logical Item Mapping Viewpoint | ||
| Physical External System | The Physical External System in the Physical Domain, outside the SOI scope, interacting with the SOI. E.g. power grid, mobile network, fresh water system (in a house). | Physical Context Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint | |
| 1 Physical Element Physical Hardware Role 0..* Hardware Element | Specifies the fact that a physical structure comprises hardware elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Physical Interaction Point | Specifies the existence of an interaction point on Physical Level. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| Physical Interaction Point Definition | Specifies the exchange capabilities of an interaction point on Physical Level. | Physical Interface Definition Viewpoint | ||
| Physical Interaction Point Property | Specifies a detail of an interaction point on Physical Level. | Physical Internal Exchange Viewpoint , Physical Interface Definition Viewpoint | ||
| Physical Item Exchange | Specifies the exchange that is to take place on a Physical Connection. | Physical Context Exchange Viewpoint , Physical Internal Exchange Viewpoint | ||
| Physical Layer | Specifies a Physical Layer, usually used for communication. | |||
| 0..1 Physical Layer Physical Layer Ordering 0..1 Physical Layer | Specifies an order among two physical layers. This order is valid within a Physical Layer Stack | |||
| Physical Layer Stack | Specifies a detail of an interaction point on Physical Level. | |||
| Physical SOI | Represents the Physical SOI on Physical Level. | Abstract Physical Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint , Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint | |
| 1..* Physical SOI Physical SOI Role 1 Physical System Context | Specifies the fact that a Physical SOI exists in a given Physical System Context. | Physical Context Definition Viewpoint | ||
| 1 Physical Element Physical Software Role 0..* Software Element | Specifies the fact that a physical structure comprises software elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Physical System Context | Specifies the fact that a context for a System of Interest is defined on Physical Level. | Physical Context Definition Viewpoint | ||
| Physical User | The Physical User is the representation for a human in the physical domain, outside the SOI scope, interacting with the SOI. | Physical Context Element | Physical Context Definition Viewpoint , Physical Context Exchange Viewpoint | |
| Process | Unit of Work in Systems Engineering. | |||
| ProfileItem | SAF Stereotype , SysML Stereotype , UML Metaclass | |||
| 1 Refuter RFTmakingCCM 1..* CounterClaim | Specifies the fact that a counter-claim is made by a defined refuter. | |||
| 1..* Stakeholder Rationale 1..* Concern | Specifies why a stakeholder has a concern. Typically that has to do with the work a stakeholder has to do within an MBSE approach. | Framework Stakeholder and Concern Definition Viewpoint | ||
| Refuter | A party asserting counter-claims. | Argumentation Assurance Viewpoint | ||
| SAF Stereotype | A stereotype of the SAF Profile Model | ProfileItem | Framework Viewpoint Implementation Viewpoint | |
| 0..* System Context Element SCEactingForOPR 1 Operational Performer | Specifies the fact that a System Context Element is acting for the benefit of an Operational Performer. | |||
| 1..* System Context Element SCErepresentedBySSH 0..* System of Interest Stakeholder | Specifies the fact that a System Context Element is represented by a SOI Stakeholder. | Stakeholder Identification Viewpoint | ||
| 1 System Context Interaction Scenario SCIScontainingLCM 0..* System Context Chronological Message | Specifies the fact that a System Context Interaction Scenario contains one or more System Context Chronological Messages. | |||
| 1 System Capability SCYcomposedOF 0..* System Capability | Specifies the fact that a System Capability consists of other System Capabilities. | System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Capability SCYdependingON 0..* System Capability | Specifies the fact that a System Capability requires another System Capability. Aliases: UAF::CapabilityDependency | System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Capability SCYenablingOCY 1 Operational Capability | Specifies the fact that an Operational Capability integrates System Capabilities to produce a specific outcome to achieve a mission objective. | System Capability Definition Viewpoint | ||
| 0..* System Capability SCYsatisfyingSHR 0..* Stakeholder Requirement | Specifies the fact that a System Capability satisfies one or more Stakeholder Requirements. | |||
| 1 System Capability SCYspecializedBY 0..* System Capability | Specifies the fact that a System Capability is specialized by another System Capability. A CapabilityGeneralization is a taxonomic relationship between a more general Capability and a more specific Capability. Aliases: UAF::CapabilityGeneralization | System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Capability SCYsupportingSUC 0..* System Use Case | Specifies the fact that a System UseCase is supported by System Capabilities. | System Capability Mapping Viewpoint | ||
| 0..* System Domain Kind SDKbeeingInSSE 0..* System State | Specifies that a System Domain Kind can have certain states. Note: Of course an item is in only one distinct state at a certain time. The multiplicity means that an Item can have a set of possible states, and a state can be used to specify possible States for several domain items. | System State Viewpoint | ||
| 1 System Domain Kind SDKcomposedOF 0..* System Domain Kind | Specifies the fact that a System Domain Kind consists of one or more System Domain Kinds. | System Domain Item Kind Viewpoint | ||
| 0..* System Domain Kind SDKderivingFromODK 0..1 Operational Domain Kind | Specifies the fact that a System Domain Kind on system level is derived from an Operational Domain Kind. | |||
| 1 System Domain Kind SDKtypingFPM 0..* General Function Usage Exchange Point | Specifies the fact that a System Domain Kind defines the type of a Function Parameter. | |||
| 1 System Domain Kind SDKtypingLIE 0..* Logical Item Exchange | Specifies the fact that a System Domain Kind defines the type of a Logical Item Exchange. | Logical Internal Exchange Viewpoint | ||
| 1 System Domain Kind SDKtypingLIPP 0..* Logical Interaction Point Property | Specifies the fact that a System Domain Kind defines the type of a Logical Interaction Point Property. | System Interface Definition Viewpoint , Logical Internal Exchange Viewpoint | ||
| 0..* Standard SDTcategorizedCOF 0..* Category Of Standard | Specifies the fact that a standard is categorized by one or more categories. | Common Standards Definition Viewpoint | ||
| 0..* Standard SDTincludingSDT 0..* Standard | Specifies the fact that a standard is part of another standard. | Common Standards Definition Viewpoint | ||
| 1 Standard SDTsupersedingSDT 0..* Standard | Specifies the fact that a standard supersedes one or more other standards. | Common Standards Definition Viewpoint | ||
| SE Concept | specifies a SE concept to be supported by SAF | SECrelatesToSEC | Framework Concept Definition Viewpoint , Framework Viewpoint Implementation Viewpoint | |
| 1..* SE Concept SECisProvidedByVP 0..* Viewpoint | Specifies, that one or more SE Concepts are provided by the Viewpoints Views | Framework Viewpoint Definition Viewpoint | ||
| 1 SE Concept SECrelatesToSEC 0..* SE Concept | specifies that a SE concept may be related others. Relations are also concepts and may be subject or object of other relations. | SE Concept | Framework Concept Definition Viewpoint , Framework Viewpoint Definition Viewpoint | |
| 1..* System Function SFNallocatedToAPE 1 Abstract Physical Element | Specifies the fact that a relationship is derived from the assignment of Functions to Logical Elements and the assignment of Logical Elements to Physical Elements. | Physical Functional Mapping Viewpoint | ||
| 1..* System Function SFNallocatedToLET 1 Logical Context SOI | Specifies the fact that a System Function is assigned to a Logical SOI. Note: This fact may be derived from the Usage of a System Function in a System Process allocated to a Logical Context SOI Role. | |||
| 1 System Function SFNboundedByNFR 0..* Non-functional Requirement | Specifies the fact that a Non-functional Requirement constrains System Functions. | |||
| 0..* System Function SFNresultingInSSE 0..* System State | Specifies the fact that a System Function can perform a particular set of transitions, resulting in the related target System States. | System State Viewpoint | ||
| 0..* System Function SFNsupportingSCY 0..* System Capability | Specifies the fact that a System Function supports one or more System Capabilities. | System Capability Mapping Viewpoint | ||
| 1..* Stakeholder Requirement SHRimposedBY 1 System of Interest Stakeholder | Specifies the fact that a Stakeholder Requirement is provided by Stakeholders. | Stakeholder Requirement Definition Viewpoint | ||
| 1..* Stakeholder Requirement SHRrefiningCRN 1..* System of Interest Concern | Specifies the fact that a Stakeholder Concern is refined by Stakeholder Requirements. | Stakeholder Requirement Definition Viewpoint | ||
| 0..* Stakeholder Requirement SHRrefiningOCY 0..* Operational Capability | Specifies the fact that an Operational Capability is refined by Stakeholder Requirements. | Stakeholder Requirement Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| 0..* Stakeholder Requirement SHRrefiningOSY 0..* Operational Story | Specifies the fact that an Operational Story is refined by Stakeholder Requirements. | Stakeholder Requirement Definition Viewpoint | ||
| 1 System SMhavingGF 1..* General Function | Specifies, that a system has general functions. | |||
| 1 System SMhavingIP 0..* Interaction Point | Specifies the fact that a System has one or more Interaction Points. | |||
| 0..* System Of Interest SOIactingForOPR 1 Operational Performer | Specifies the fact that a SOI is acting for the benefit of an Operational Performer. | |||
| 1..* System Partial Function SPFNallocatedToAPE 1 Abstract Physical Element | Specifies the fact that a System Partial Function is assigned to an Abstract Physical Element. Note: This fact may be derived from the Usage of Function of a System Partial Function allocated to a Physical SOI Element Role | Physical Functional Mapping Viewpoint | ||
| 1..* System Partial Function SPFNallocatedToLET 1 Logical Element | Specifies the fact that a System Partial Function is assigned to a Logical SOI Element. Note: This fact may be derived from the Usage of Function of a System Partial Function allocated to a Internal Logical Element Role | |||
| 0..* System Process SPSenablingOPS 0..1 Operational Process | Specifies the fact that a System Process enables the accomplishment of an Operational Process. | |||
| 0..* System Process SPSenablingSCY 0..* System Capability | Specifies the fact that a System Process contributes to the provision of one or more System Capabilities in the field. | System Capability Mapping Viewpoint | ||
| 0..1 System Process SPSrefiningSUC 1 System Use Case | Specifies the fact that a System Use Case is refined by one System Process. | System Requirement Traceability Viewpoint | ||
| 0..* System Requirement SRderivingFromSR 1 System Requirement | Specifies the fact that System Requirements are derived from a Stakeholder Requirement. Note: This is the relationship of requirements of different architectural levels. When the team responsible for the subsystem has direct access to the full upstream requirements set, then no subcontractor relationship needs to be established. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint | ||
| 0..* System Requirement SRderivingFromSTKR 1..* Stakeholder Requirement | Specifies the fact that a System Requirement is derived from a Stakeholder Requirement. Note: It may be used in a customer supplier relationship situation and supports the V Model concept of "External Unit Specification". See [VXT]. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint | ||
| 0..* System Requirement SRrefiningLICP 0..* Logical Interaction Point | Specifies the fact that a Logical Interaction Point is refined by System Requirements. | System Requirement Traceability Viewpoint | ||
| 0..* System Requirement SRrefiningSCY 0..* System Capability | Specifies the fact that a System Capability is refined by System Requirements. | System Requirement Traceability Viewpoint , System Capability Mapping Viewpoint | ||
| 0..* System Requirement SRrefiningSUC 0..* System Use Case | Specifies the fact that a System Use Case is refined by System Requirements. | System Requirement Traceability Viewpoint | ||
| 0..* System State SSEperformingSFN 0..* System Function | Specifies the fact that the Function is only provided in distinct States. The state is a precondition for the Function to be able to perform. | System State Viewpoint | ||
| 1 System of Interest Stakeholder SSHhavingCRN 1..* System of Interest Concern | Specifies the fact that a Stakeholder has certain Concerns. | Stakeholder Identification Viewpoint | ||
| 1 System of Interest Stakeholder SSHrelatedToSSH 0..* System of Interest Stakeholder | Explains relations between the Stakeholders of the System and other relevant System parties. It helps to understand the Stakeholder community and to approach the right point of contact for clarification of project relevant issues. | Stakeholder Identification Viewpoint | ||
| 0..* System of Interest Stakeholder SSHrepresentingOPR 1..* Operational Performer | Specifies the fact that a SOI Stakeholder is representing an Operational Performer. | Stakeholder Identification Viewpoint , Operational Performer Viewpoint | ||
| 1 System of Interest Stakeholder SSHrepresentingUSR 0..* User | Specifies the fact that an User is represented by Stakeholders. | |||
| 1..* SAF Stereotype SSTimplementsVP 1 Viewpoint | specifies, that one ore more SAF Stereotypes implement a viewpoint. Note: Multiple Stereotypes are used if there are alternate presentations. | Framework Viewpoint Implementation Viewpoint | ||
| 0..* Standard STDcontainsGY 0..* Glossary | specifies that a standard may contain one or more glossaries. | |||
| 0..* Standard STDdependsOnSTD 0..* Standard | specifies that a standard depends on an other. | Common Standards Definition Viewpoint | ||
| 0..* Standard STDissuedBySTO 1 Standardization Organization | Specifies the fact that a standard is issued by an organization of standardization. | Common Standards Definition Viewpoint | ||
| 0..* System Use Case SUCenablingOSY 0..* Operational Story | Specifies the fact that a System Use Case enables the realization of an Operational Story. | System Use Case Viewpoint | ||
| 0..* System Use Case SUChasPostConditionSSE 0..* System State | Specifies the fact that a System Use Case has a state as Postcondition. | System Use Case Viewpoint | ||
| 0..* System Use Case SUChasPreConditionSSE 0..* System State | Specifies the fact that a System Use Case has a state as Precondition. | System Use Case Viewpoint | ||
| 1 System Use Case SUCincludingSUC 0..* System Use Case | Specifies the fact that a System Use Case includes other System Use Cases. The included use case is then no longer a full System Use Case, but a partial System Use Case. | |||
| 0..1 System Use Case SUCrefiningSHR 0..* Stakeholder Requirement | Specifies the fact that a Stakeholder Requirement is refined by System Use Cases. | |||
| 1..* System Use Case SUCsynthesizingCFN 0..* Context Function | Specifies the fact that a Context Function is used in a System Use Case, e.g., as a Trigger, Action, or Task. Note: This is a derived relationship. | |||
| 1..* System Use Case SUCsynthesizingSFN 0..* System Function | Specifies the fact that a System Function is used in a System Use Case, e.g., as a Trigger, Action, or Task. Note: This is a derived relationship. | |||
| 1..* System Use Case SUCtakingPlaceInLSC 1 Logical System Context | Specifies the fact that a System Use Case takes place in a Logical System Context. | System Use Case Viewpoint | ||
| Software Element | Pure Software Elements. Similarity with the V-Model "software unit". | Abstract Physical Element | Physical Structure Definition Viewpoint , Physical Internal Exchange Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| 1 Software Element Software Element Role 0..* Software Element | Specifies the fact that a software structure comprises software elements. | General Physical Role | Physical Structure Definition Viewpoint , Physical Functional Mapping Viewpoint , Physical Logical Mapping Viewpoint | |
| Stakeholder | specifies someone (typically a role) having an information need within an MBSE approach. | Framework Stakeholder and Concern Definition Viewpoint | ||
| Stakeholder Requirement | A Stakeholder Requirement is a Requirement imposed by a Stakeholder. Stakeholder Concerns are refined by Stakeholder Requirements applicable for the SOI. The Stakeholder Requirements are a result of discussions and agreements of how the SOI addresses the Concerns of the respective Stakeholder. | System Requirement Definition Viewpoint , System Requirement Traceability Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Capability Mapping Viewpoint | ||
| Standard | Specifies a standard which shall potentially be complied by the system or a part of the system. | Common Standards Definition Viewpoint | ||
| Standardization Organization | An organization of standardization, e.g., International Organization for Standardization (ISO), Object Management Group (OMG), etc. | Common Standards Definition Viewpoint | ||
| 1 System State State Transition 1 System State | Describes an allowed transition between two states of an item that can be in distinct States. | System State Viewpoint | ||
| Subject of Claim | Note: A claim cannot be generic, it has to be about something, it has to have a defined subject, e.g., system safety. | Argumentation Assurance Viewpoint | ||
| SysML Stereotype | A stereotype from sysml | ProfileItem | Framework Viewpoint Implementation Viewpoint | |
| System | An abstract element representing a System. | General Context Element , System Of Interest | ||
| System Capability | 1) A System Capability is an operation or task that performs an action to produce a specific performance-based outcome. NOTE that a system capability represents the potential to perform an action. In contrast, an operational capability may integrate several physical system capabilities to produce a specific outcome to achieve a mission objective. [Wasson2006, SystemAnalysis+Design+Development] 2) System Capabilities, as system assets, characterize the mechanical, electrical, optical, or processing features that enable a system to function, process mission resources, make decisions, and achieve a required level of success based on performance. A system capability is broader in scope than simply a functional element (and performance bounding elements), especially in large, complex ecosystems. It represents a physical potential - strength, ability, endurance - to perform an outcome-based action for a given duration under a specified set of operating environment conditions. [Wasson2006, SystemAnalysis+Design+Development] Aliases: UAF::Capability NAF4::Capability | System Requirement Traceability Viewpoint , System Capability Definition Viewpoint , System Capability Mapping Viewpoint | ||
| System Context | Specifies the fact that a context for a System of Interest is defined. | General Context | Loss Context | |
| 1 System Context Scenario Participation System Context Chronological Message 1 System Context Scenario Participation | Ordered sequential occurrence of exchanges between System Context Interaction Scenario Participants. | System Context Interaction Viewpoint | ||
| System Context Element | An abstract element representing a System Context Element. Base class for specific kinds of Context Elements. | General Context Element | Adversary | |
| 1..* System Context Element System Context Element Role 1..* System Context | Specifies the fact that a System Context Element exists in a given System Context. | General Context Element Role | ||
| System Context Interaction Scenario | Ordered sequence of exchanges of information, energy, or material between System Context Interaction Scenario Participants. | System Context Interaction Viewpoint | ||
| System Context Role | General role of a Logical System Context. | Logical Context Element Role , Logical SOI Role | ||
| 0..* System Context Role System Context Scenario Participation 0..* System Context Interaction Scenario | Specifies the fact that a System Context Role participates in a System Context Interaction Scenario. | System Context Interaction Viewpoint | ||
| System Domain Kind | Specification for any kind of conceptual item (energy, material, information, etc.) to be exchanged on Functional or Logical Level. The System Domain Kind is agnostic to any realization on Physical Level. | System Domain Item Kind Viewpoint , System Interface Definition Viewpoint , Logical Internal Exchange Viewpoint , Physical Logical Item Mapping Viewpoint | ||
| System Function | Specifies the fundamental action or task that have to take place in the System in accepting and processing the inputs and in processing and generating the outputs. A System Function * accepts input from the System boundary * exposes its output at the System boundary * changes the System's State * is dependent on System's State Note: A System Function does not need to expose observable output, when it changes the System's state in a way that is observable by other system functions. Furthermore, a System Function does not need to accept any input from the system boundary, when it is dependent on the System State, which in turn is changeable by other System Functions. | General Function | System Process Viewpoint , System Requirement Traceability Viewpoint , System Functional Breakdown Structure Viewpoint , System Functional Refinement Viewpoint , System Capability Mapping Viewpoint , Logical Functional Mapping Viewpoint , Physical Functional Mapping Viewpoint | |
| 0..* System Function System Function IN System Process 0..* System Process | Specifies the fact that a System Function is used in a System Process. | General Functional Usage | System Process Viewpoint , System Requirement Traceability Viewpoint , System Functional Breakdown Structure Viewpoint | |
| System Of Interest | An abstract element representing a SOI. Base class for specific kinds of SOIs. | System | ||
| System Partial Function | Specifies the fact that a System Partial Function is a decomposed part of a System Function and defines details of the System Function it belongs to. | General Function | System Functional Breakdown Structure Viewpoint , Logical Functional Mapping Viewpoint | |
| 0..* System Function System Partial Function in System Function 0..* System Partial Function | Specifies that a System Partial Function is used in a system function | General Functional Usage | System Functional Breakdown Structure Viewpoint , System Functional Refinement Viewpoint | |
| System Process | Specifies the fact that a System Process captures system behavior as a specific sequence of actions or tasks, and system exchanges including information, materials, energy, etc. | System Process Viewpoint , System Requirement Traceability Viewpoint , System Functional Breakdown Structure Viewpoint , System Capability Mapping Viewpoint | ||
| System Requirement | System Requirements specify System Functions, non-functional properties, or constraints of the System. | Functional Requirement , Non-functional Requirement | System Requirement Traceability Viewpoint , System Capability Mapping Viewpoint | |
| 1 System System Role 0..* System | Specifies, that a system is part of a system. | General Context Element Role | ||
| 1..* System Of Interest System SOI Role 1 System Context | Specifies the fact that a System SOI exists in a given System Context. | |||
| System State | Describes a state (or mode) of something that can have distinct states. | System State Viewpoint | ||
| System Use Case | The System Use Cases are a table of content of the services provided by the System of Interest to its System Actors. A System Use Case is only the abstract of the depicted System behavior and represents the purpose. While the main System of Interest interaction actors participating in this Use Case are identified, the behavior itself is specified by a Use Case Activity, Note: The intended use (and also misuse in so called "black use cases") of the System of Interest is captured in free text; story telling at a coarse level of detail which is understandable to Customers (non engineering stakeholders in general). | System Use Case Viewpoint , System Requirement Traceability Viewpoint , System Capability Mapping Viewpoint | ||
| System of Interest Concern | Any kind of interest a Stakeholder has. Note: Redundant with the meaning of "Need"? | Stakeholder Identification Viewpoint , Stakeholder Requirement Definition Viewpoint | ||
| System of Interest Stakeholder | An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. It may be involved in any life cycle phase of the System. The Stakeholder represents a class or kind of Stakeholders. Stakeholders have a certain involvement: Stakeholder Involvement captures the influence of a project specific Stakeholder on the System. Stakeholder Involvement is characterized by * Contact Person * Kind of involvement * Life Cycle Phases involved * Relevance decision if and up to which degree Stakeholder is considered * Rationale for decision when Stakeholder is not considered | Stakeholder Identification Viewpoint , Stakeholder Requirement Definition Viewpoint , Operational Performer Viewpoint | ||
| 0..* Term TRMdefinedBySDT 1 Standard | Specifies the fact that a term is defined by a standard. | Common Terms Definition Viewpoint | ||
| Term | Specifies the fact that a term is usually defined by a standard, but can also be defined as part of system development work. | Common Terms Definition Viewpoint | ||
| Triggering Event | ||||
| UML Metaclass | A metaclass from UML | ProfileItem | Framework Viewpoint Implementation Viewpoint | |
| 1..* General Functional Usage USAGEallocatedTo 1 Logical Element Role | Specifies the fact that a Usage of Function is allocated to a Usage of System Element. | Logical Functional Mapping Viewpoint | ||
| User | Representation for a human in the Logical Domain, outside the SOI scope, interacting with the SOI. Note: This seems to be highly redundant with definition of "Role". | |||
| 0..* Viewpoint VPbelongingToAT 1 Aspect | specifies that a viewpoint belongs to one aspect. | Grid Definition Viewpoint , Framework Viewpoint Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 0..* Viewpoint VPbelongingToDN 1 Domain | specifies that a viewpoint belongs to one domain. | Grid Definition Viewpoint , Framework Viewpoint Definition Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 0..* Viewpoint VPframesCN 1..* Concern | Specifies that a Viewpoint frames one or more concerns. That means that the views conform to that viewpoint satisfy the information need expressed by the concerns. | Framework Viewpoint Definition Viewpoint | ||
| 0..* View VWconformingToVP 1 Viewpoint | specifies that a view conforms to a viewpoint. | Grid Definition Viewpoint | ||
| View | A architecture view comprises portion of an architecture description and addresses information-relevant concerns framed by a architecture viewpoint. | Grid Definition Viewpoint | ||
| Viewpoint | A architecture viewpoint defines set of conventions for the creation, interpretation and use of an architecture view to frame one or more concerns | Framework Viewpoint Definition Viewpoint , Framework Viewpoint Implementation Viewpoint , Framework Viewpoint Overview Viewpoint | ||
| 1 Operational Process controlledAFTER 1 Operational Process | Specifies the sequencing of Operational Processes in time. | Operational Process Viewpoint | ||
| 1 Any SAF Element satisfyingSHR 0..* Stakeholder Requirement | Specifies the fact that a Stakeholder Requirement is satisfied by SAF Model Elements. | |||
| 0..1 Triggering Event triggering 0..* State Transition | System State Viewpoint |