Bulldozer00's Blog

Introduction

The Unified Modeling Language (UML) and System Modeling Language (SysML) are two industry standard tools (not methodologies) that are used to visually express and communicate system structure and behavior.

The UML was designed by software-weenies for software-weenies. Miraculously, three well-known software methodologists (affectionately called the three amigos) came together in koom-bah-yah fashion and synthesized the UML from their own separate pet modeling notations. Just as surprising is the fact that the three amigos subsequently donated their UML work to the Object Management Group (OMG) for standardization and evolution. Unlike other OMG technologies that were designed by large committees of politicians, the UML was originally created by three well-meaning and dedicated people without hidden agendas.

After “seeing the light” and recognizing the power of the UML for specifying/designing large, complex, software-electro-mechanical-hardware systems, the system engineering community embraced the UML. But they found some features lacking or missing altogether. Thus, the SysML was born. Being smart enough not to throw the baby out with the bathwater, the system engineering powers-that-be modified and extended the UML in order to create the SysML. The hope was that broad, across-the-board adoption of the SysML-UML toolset pair would enable companies to more efficiently develop large complex multi-technology products.

The MLs are graphics intensive and the “diagram” is the fundamental building block of both of them. The most widely used graphics primitives are simple enough to use for quick whiteboard sketching and brainstorming, but they’re also defined rigorously enough (hundreds of pages of detailed OMG specifications) to be “compiled” and checked for syntax and semantic errors – if required and wanted.

The Diagrams

The stacked UML class diagram below shows the structural relationships among the diagrams in the UML and SysML, respectively. The subsequent table lists all the diagrams in the two MLs and it also maps which diagram belongs to which ML.

In the table, the blue, orange, and green marked diagrams are closely related but not equal. For instance, the SysML block definition diagram is equivalent too, but replaces the UML class diagram.

Diagrams are created by placing graphics primitives onto a paper or electronic canvas and connecting entities together with associations. Text is also used in the construction of ML diagrams but it plays second fiddle to graphics. Both MLs have subsets of diagrams designed to clearly communicate the required structure(s) of a system and the required behavior(s) of the system.

The main individual star performers in the UML and the SysML are the “class” and (the more generic) “block”, respectively. Closely coupled class or block clusters can be aggregated and abstracted “upwards” into components, packages, and sub-systems, or they can be de-abstracted downwards into sub-classes, parts, and atomic types. A rich palette of line-based connectors can be employed to model various types of static and dynamic associations and relationships between classes and blocks.

A Conundrum?

In the pre-ML days of large system specification and design, ad-hoc text and structured analysis/design tools were predominantly used to communicate requirements, architectures, and designs between engineering disciplines. The use of these ad-hoc tools often created large gaps in understanding between the engineering disciplines, especially between systems and software engineers. These misunderstandings led to inefficient and error prone development. The figure below shows how the SysML and UML toolset pair is intended to close this “gap of misunderstanding”.

Minimization of the gap-of-misunderstanding leads to shorter *and* higher quality product development projects. Since the languages are large and feature rich, learning to apply the MLs effectively is not a trivial endeavor. You can’t absorb all the details and learn them overnight.

Cheapskate organizations who trivialize the learning process and don’t invest in their frontline engineering employees will get what they deserve if they mandate ML usage but don’t pay for extensive institution-wide training. Instead of closing the gap-of-misunderstanding, the gap may get larger if the MLs aren’t applied effectively. One could end up with lots of indecipherable documentation that slows development and makes maintenance more of a nightmare than if the MLs were not used at all (the cure is worse than the disease!). Just because plenty of documentation gets created, and it looks pretty, it doesn’t guarantee that the initial product development and subsequent maintenance processes will occur seamlessly. Also, as always in any complex product development, good foundational technical documentation cannot replace the value and importance of face-to-face interaction. Having a minimal, but necessary and sufficient document set augments and supplements the efficient exchange of tacit, face-to-face communication.

Closing Note: The “gap-of-misunderstanding” is a derivative of W. L. Livingston’s “gulf-of-human-intellect” (GOHI); which can be explored in Livingston’s book “Have Fun At Work”.