Semantics of SysML Relationships in SOX

The main relationships between elements are stored in the system design as well and, hence, kept
consistent across all documents: Hierarchy of system elements, hierarchy of functions, assignment
of functions to system elements, assignment of malfunction to functions, cause-effect relationships
between malfunctions, assignment of safety goals to functions, and assignment of requirements to
system design elements. Again, adding such a relationship in one document automatically creates a
corresponding relationship in the system design (but not vice versa) and deleting such a relationship
in the system design can result in appearance of a “Refactoring” dialogue that informs about the
consequences.

The following table lists the relationships that are relevant in multiple types of documents/diagrams and their meanings within a certain document/diagram type:

Relationship	Usage in Document
Relationship	SysML Diagram	FMEA Document	RE Document	FMEDA Document	FTA Document
Hierarchy of system elements	Composition	Hierarchy of system elements	Hierarchy of modules	Hierarchy of modules	-
Assignment of functions to system elements	Allocate relationships	Assignment of functions to system elements	-	Assignment of hardware function to module	-
Assignment of malfunctions to functions	Composition	Malfunction	-	Assignment of hardware failure to hardware function	-
Assignment of safety goals to functions	Satisfy relationship	Assignment of safety goals to functions	-	Safety goal	-
Assignment of requirements to any other object	Satisfy relationship	-	-	-	-

Terminological aspects:

Association: specifies peer-to-peer relationships between model elements, e.g. if a Class-x has an attribute of type Class-y, it can be viewed in a class diagram as an association between Class-x and Class-y.
Aggregation: is used to model a whole/part relationship between model elements. The part element can exist without the whole. Aggregation causes the generated code to contain the aggregate either by reference or by value, depending on the details of the relationship. E.g. to model an aggregation, the aggregate (Department) has an aggregation association to its constituent parts (Employee). A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation.
Composition: is an aggregation with strong ownership, i.e. if the container is deleted, all of its composite
objects are deleted as well.
Generalization: relationship causes a class to be generated as a subclass of another class.
Realizes: relationship specifies that, e.g. an implementation realizes a specification. The Realizes relationship does not affect the code.

To create a relationship between two modeling elements, use the tool palette in the diagram editor, e.g. to create an Association between two classes, select the Association tool in the tool palette, click on the source element and then click on the destination element.