“…For even as He loves the arrow that flies,
from “On Children” by Kahlil Gibran
so He loves also the bow that is stable.”
Years ago a friend of mine, Joe the Software Architect, spoke often of brittle Architectures. To him (and to me) the idea of a UML model being brittle or stable was just as real as the stability of a physical structure. The world of civil engineering is littered with stories of charlatans passing as architects leaving behind bridges and buildings too brittle to stand use.
SysML is a profile of UML, a ‘language dialect,’ and as such the habits we learned in UML, both the good and the bad, apply. And the number one lesson I learned working with Joe was to be mindful of my arrows. In SysML Block Definition Diagrams (BDD,) in UML Class Diagrams, and Package Diagrams, every arrow implies a dependency (little ‘d’).
It is easier to see this in UML: I taught OOA/OOD for years as well as some language courses. I asked everyone to think every arrow, regardless of type, as a ‘#include’. C and C++ are powerful (and dangerous) languages, anything misused ( like #include ) will cut you and you will bleed. When you add a #include filename you are declaring that something in this file needs something, some bit of code, in filename, you can’t live without it. It would make no sense to then add a #include in filename that pointed back to your file. But in SysML I see that all the time. It is so easy to point ‘up’ the generalization hierarchy for some bit of structure, while the behavior that belongs to that block at the top is pointing back down at some behavior closer to the implementation.
In being mindful of our arrows we will attempt to place the dependency between different blocks as high up the generalization hierarchy as possible. For example, if all my powered lawn mowers have a dependency on a motor I would want to describe this using the most general form of mower and the most general form of motor. Once we have this relationship defined we can add new mowers and motors without having to manage dozens of dependencies: our architecture is stable.
Once we understand this we can develop reference architectures that act as a pattern for all the specific systems expressed by that reference. (If you did not look at the lawn mower link above, do so now.) A mature MBSE approach will include both reference architectures for each product line and a library of reusable components. What does this have to do with arrows? Both the reference and the reusable components are READONLY to the system you are building, you have a dependency (big ‘D’ and little ‘d’ ) on them. The arrows inside these reusable items can go any direction (within reason) and the arrows inside your model can too, but only the pointy end of the arrows can touch them.
The saving grace in all of this is that unlike coders who have to imagine the system dependencies, we Systems Engineers can visualize them. This may seem abstract and academic but a clean and stable symbolic model of your system will lead to system and subsystem interfaces (ICDs) that make sense and can be implemented. And the interfaces are how your symbolic architecture is realized in the integration lab.
Photo by Adri Tormo on Unsplash