What’s new in SysML 1.4 – Constraining decompositions
The fourth part of the blogpost series about the changes in SysML 1.4 presents the new concept to constrain a decomposition hierarchy.
The following figure shows a simple product tree of a drone subsystem (DS) for a forest fire detection system (FFDS). It is the sample system I’ve also used in some previous posts.
The structure allows different configurations of drone subsystem instances due to the multiplicitiy of the camera and the heat sensor and generalization of the camera. For instance drones with 2 standard FFDS cameras and no heat sensor or 1 highend FFDS camera and 1 heat sensor and so on.
SysML 1.4 introduces a new model element to constrain decomposition hierarchies. It is called bound reference. It is a marker to highlight properties that are connected to other properties with a binding connector to constrain them. The binding connector specifies that the values of the connected properties must be the same.
The following diagram shows the definition of the bound reference properties for the drone subsystem:
The bound reference properties are connected with the appropriate properties in the decomposition hierarchy with a binding connector:
The bound reference bindingPath is a derived property. The value specifies the path from the enclosing block to the connected property and could be derived from the binding connector relation.
The type of the bound reference must be compatible with the type of the connected property. Otherwise the values of properties could not be the same.
In our example the types are the same (Camera and Heat sensor). The multiplicity of the bound reference is more general than the multiplicity of the connected properties. Therefore it is not necessary to update the multiplicity each time when the multiplicity of the connected properties changes, for example due to a change of the requirements or a new architecture decision..
Now it is easy to define special drone subsystem configurations. For instance drones with 2 standard FFDS cameras and no heat sensor or drones with 1 highend FFDS camera and 1 heat sensor:
Of course the concept of the bound reference properties could be used for the modeling of variants (for example see my blogpost Variant Modeling with SysML).
6 Responses
Hi Tim,
Thx for sharing this!
Are the semantics of the “constraining decomposition” mechanism (exactly) the same as
1/ when one would add a top-level property cameraBR to the drone system block and add an OCL constraint to the drone system that states that self.cameraBR = self.drones.camera?
2/ when one would add a top-level property cameraBR to the drone system block and bind its value to self.drones.camera using a parametric diagram?
In that case, am I right when stating that:
– The advantage of the new construct is that one doesn’t have to know OCL (or parametrics)
– The disadvantages of the new construct are that (i) it’s less flexible than OCL/parametric diagrams (imagine the case where the top-level property represents the diameter of a subsystem and the deeply nested property represents the radius of the subsystem) and (ii) it’s yet another concept that modelers have to learn
BR,
Klaas
Hi Klaas,
Yes, that’s correct: The binding connector is the same as in parametric diagrams, so the diagram is in fact a parametric diagram (=no advantage), and OCL would also do the job.
OCL allows more flexibility, but gives no visual representation of the constraint. It could constrain anything, so it’s hard to see what it constrains in this case. And in many cases this flexibility is not needed.
Additionally the stereotype «boundReference» makes it easy to distinguish between the real property and the one that is only used for constraining the decomposition. Also defining them in a generic system documents how this generic system could get specialized. And finally bound references may specify an end path multiplicity. This makes it possible to specify that in each of the 4 wheel assemblies of my specific car the wheels shall be mounted with 5 lug bolts while the generic wheel assembly could have from 4 to 7 lug bolts (a parametric diagram can limit the number of lug bolts, but 20 lug bolts could still be distributed randomly like 4/4/5/7).
It may be another concept, that modelers need to learn, but I think it is worth the effort, since it presents a standard way to define such often needed constraints. It also makes it easier to reuse generic assemblies that are defined in a library, opening the path to really useful standard libraries.
Best regards
Axel
HI,
We could have redefined the required part directly, instead of having create the bound reference. Does it create an additional advantage over that method?
One advantage I see though, is that you can refer to properties of a part of the subsystem. For example, Camera is a part of Drone, which otherwise is inaccessible via attributes of ‘Drone Subsystem’.
An advantage of bound references is that you can control the constraints on the whole structure from the single block that owns the bound references.
Ohh so instead of creating specializations of the parts of Drone Subsystem, We can define lower level specializations at a higher level. In essence, less work and keeps specializations in one place.