1. Developing an Algebraic Structure Over Relationships (or Enabling Model Users to Build Inference Engines in Their Models)

2. General Concept Suppose a modeler creates the following elements/relationships.
Then the idea is to define a way for the modeler to tell the tool to automatically create a third dependency (Arrow 3) whenever this happens.

3. To better illustrate how this concept might work, the following material is what I originally brought to Sandy to propose the idea for SysML 1.x/UML 2.x (did not know SysML 2.0 was in the works at the time as I was not involved in the OMG).
(Go easy on this stuff; it was my first time trying to write material for UML/SysML specifications (and OCL) and has been left in very much an unfinished prototype state)

4. This is the symbol used to denote the integration relationship on a profile diagram

5. The following are examples that were originally built around the integrated relationships concept (that is, the following material was put together a while ago to demonstrate some use cases for the integrated relationships concept). The last example (nested parts) was some work put together at Sandy’s request.
To be clear, these are just examples that demonstrate the functionality that was originally desired from this concept. These are not intended to be viewed as proposed solutions for SysML v2.

6. Integration Examples Example 1
Source Idea: Working on making improvements to an as-is system, the question arose on how to bring in the causal analysis (which had already been done outside of the model).
The idea was that the limitations would represent the causal analysis items and would be related to requirements via the limits dependency; then, as potential solutions to the limitations were developed, they would be represented by the mitigations which would have a mitigates dependency with their corresponding limitation.

7. Below is a basic example of how this would work:
Would like for this to happen.
At the time, one thing that bothered me was that I didn’t have a way to automatically tie the mitigation to the requirements. Considering that each limitation would likely have multiple potential mitigations as well as the fact that each limitation would limit multiple requirements, it seemed like it would be a hindrance to flip between relationship matrix setups to try to map the mitigations to requirements. I know I could use a report template or something similar to generate reports that could track this, but I wanted that information explicitly in the model.

8. If the integrated relationships concept was available, I would be able to do this:
Which would result in…

9. … this happening once the mitigate and limits relationships were created.

10. Example 2
Suppose we have a system with sensors, and let’s suppose there are some requirements that all sensors should satisfy. So let’s say we make a block called Sensor and it has specializations of Sensor A, Sensor B, and Sensor C and then we create a satisfy relationship from Sensor to some requirement intending for all of the sensors to inherit that relationship. Let’s look at this idea in three different tools:

11. Certainly, there are other ways of accessing this information (which varies pending on tool), but as we can see, these relationships are not being explicitly inherited.
Addendum: Was later discussed that the real issue here is that our requirement relationships are all based on the Dependency relationship, which isn’t inherited; therefore, a (general) topic of discussion going forward with SysML 2.0 could be how requirements are related to other elements and what we want from those relationships.

12. However…

13. Consider the following problem:
With respect to the project browser (and thus, in the model), vehicle does not have knowledge of the wheels and tires that are also parts of it. Furthermore, we do not really have any concept of the “front wheels” and “rear wheels” as far as the model itself is concerned (outside of an instantiation of vehicle anyways).
Addendum: It was later discussed that the better approach for this idea would be to use the bound reference concept from SysML 1.4 in coordination with the inference capability. I’m leaving the original material as is though since it serves the purpose of illustrating a usage for the general concept.

14. Potential Solution:
Introduce a new type of composition* called “nested composition” and apply the integration relationships in the metamodel.
Note: There has been a change to the original metamodel for integration due to this problem. The boolean attribute isStart has been replace by the enumeration path:PathType. PathType has literals start, end, and same. The difference now is that path = same indicates that if a relationship is repeated (e.g. two compositions) then the new relationship will be created (I didn’t feel like a boolean value could do this issue much justice; that is, if both integrated relationships are the same relationship, how much sense does it make to set one as the start?)
This says: Composition -> Composition = Nested Composition
* - From a UML/SysML metamodel perspective, what would actually happen is that AggregationKind would either be modified in UML to include nested composition or would be extended in SysML to include nested composition. Since this is just a proof of concept, I’m going to be lazy and just pretend like there’s a metaclass called “Composition” as opposed to putting together a rigorous metamodel.

15. So what does this mean?
Suppose that the graphical symbol for nested composition looks like this:
Then what happens in our original diagram is this:
Note: It is not intended that this nested composition relationship automatically show up on diagrams. That would make diagrams horribly cluttered, therefore it is my recommendation that it be elided on
diagrams.

16. So how does this thing work
So how does this thing work? It is intended that the attributes of the nested composition relationship are generated as such: -The multiplicity is the multiplicities of the compositions multiplied together. -The nested property name is the combination of the composite association part property names. In this case, we have front wheel, rear wheel, front tire, and rear tire. The first part of the name will be the part property name of the first composition association while the second part of the name will be the part property name of the second composite association. -In a case such as this where there are multiples of the same relationship (Vehicle and Wheel Assembly share two composite associations), all possible combinations will be created (fun fact: I did not realize this at first, and initially worried a bit over how I would determine which relationships will tie together; when it hit me that it didn’t matter and that everything would be created anyways, I was very happy).

17. Another integrating relationship that I think will be important in this is the following:
This says Nested Composition -> Composition = Nested Composition

18. To understand the reason for the previous slide, consider this diagram
To understand the reason for the previous slide, consider this diagram. We already know from slide 4 that Vehicle will have two nested composition associations with Wheel, so when Sensor is added the metamodel from the previous slide says that two nested composition associations will be created between Vehicle and Sensor, as demonstrated on the next slide.

19. As can be seen, all of the rules presented in slide 5 still apply here, only instead of the first relationship being a composition association, it’s a nested composition association.
The next question might be: why make a new composite association? Why not just use the regular composite association?

20. Here’s an example of what the Vehicle block would look like with a nested parts compartment, which I’ve separated from the parts compartment. Why do this? My gut feeling is that modelers may want to be able to differentiate between parts and nested parts, and I want to avoid just mixing all of these things together. I’m also considering the current setup for instantiation in UML/SysML; my fear is that if parts and nested parts aren’t segregated, then we would wind up having duplication with instances (and on IBDs).
Furthermore, I’m actually considering a nested part property (in terms of a model element) something different from a part property.
However, there is an issue here that we need to address.

21. Refer back to the diagram on slide 8
Refer back to the diagram on slide 8. Now, let’s consider what the Vehicle and Wheel Assembly blocks would look like with nested compartments:
Here, everything in the red boxes represents different levels of abstraction for the sensor, e.g. a wheel has wheel sensors, but more specifically a vehicle has front and rear wheel sensors. What we need is a way for the lower levels of abstraction to inherit relationships from the higher levels of abstraction (e.g. if wheel sensor satisfies a requirement, the front wheel sensor should satisfy that requirement as well, though the front wheel sensor may satisfy requirements that the wheel sensor does not).

22. This ends the material regarding the integrated relationships concept
This ends the material regarding the integrated relationships concept. The point of the past eighteen slides was just to give an idea of what I mean when I say “algebraic structures on relationships” so that we can discuss whether the concept is something we’d be interested in having in SysML v2.
Proposed SysML v2 formalism requirements (rough draft): SysML v2 shall enable model users to build inference engines in their models.
Current thought is that this would go in section (Extension Capabilities) of the SysML v2 RFP.