Relates to:
Throughout this Webel IT Australia site you'll find references to and examples of analysis modelling with Systems Modeling Language (SysML®) of software systems and hybrid systems (systems of systems with software components and/or software-like protocols) .
As used here, 'analysis modelling' is in contrast to reverse-engineering and forward-engineering of compatible object-oriented languages (such as Java, C++, and C#) to/from Unified Modeling Language (UML®), where there is a digital binding between the code and the UML models.
Whether the dream of substantial model-driven code-generation using forward-engineering from UML and full-cycle model-driven code engineering was realised (or turned out to be practical for many projects) is beyond the scope of this article. If you've followed any of my posts on Unified Modeling Language (UML®), you'll know I am a huge fan of: Reverse to UML; Plan refactoring in UML; Refactor in code; Reverse and Repeat. But that too is beyond the scope of this article.
This article is about the benefits of using SysML on any project involving code to introduce a "systems thinking" view, which can be of benefit with or without any use of UML bound to code, and can also be of benefit on projects involving coding languages with functional programming support (so not just for primarily object-oriented languages).
Aspects of Model-Based Systems Engineering with SysML that can be leveraged on projects involving software and software-like protocols include:
- SysML Requirements Engineering.
- For larger projects that warrant it, use of a formal systems engineering methodology and especially functional analysis breakdown.
- Tracking of dependencies between components (both physical and software).
- Port-based modelling, interface modelling, and signal and data flow modelling.
- Representation of documents and software engineering artifacts (such as libraries, packages, application installs, and configuration files), and how the various components on a project relate to or depend on them.
- Representation of technologies used using custom stereotypes with icons.
- Representation of communication protocols using custom stereotypes: «WiFi», «TCP/IP», «HTTPS» etc.
- Use of SysML Diagrams in tools as launchpads for URL-executable components, noting that in most good SysML tools one can hyperlink symbols to external URLs.
- Feature tracking, typically supported by custom stereotypes and tagged values metadata.
- Issue tracking, typically supported by custom stereotypes and tagged values metadata, and with hyperlinks to issue tracking tickets for JIRA or similar.
- Tracking and documentation of the IT infrastructure and deployment.
- And last but not least, tracking of an entire project using custom stereotypes and metadata (which can include task tracking and human resource tracking).
SysMLv1 analysis modelling combined with reverse-engineered UML bound to code
Compared with UML, SysML has superior mechanisms for representing port-based engineering, flows, systems views of projects, and Requirements Engineering. One powerful and very easy to implement strategy is to have – if using SysMLv1 – SysMLv1 Blocks that acts as wrappers for UML implementation components, which could be one or more UML Classes reverse engineered from Java, C++, C# or even XML Schema. Under this approach, the SysMLv1 Blocks are integrated with the SysML Requirements Engineering.
Since SysMLv1 is based on UML2, many SysMLv1 tools support use of UML in parallel with SysMLv1, and there are many ways of representing the bridging from a wrapping SysMLv1 Block to a UML Class (and it really doesn't matter whether you use an existing relationship like Trace or a custom stereotyped relationship).
The SysML layer of the project model carries the systems engineering «analysis», and the UML carries the «design» layer (or "designed" if reverse engineered). In this nomenclature the code is considered the 'implementation'. You may prefer to use a slightly different systems engineering terminology (especially if using formal functional analysis breakdown from logical components to design and/or implementation), but all that matters here is to have a clear distinction between the systems engineering view and aspects directly related to code.
SysML analysis modelling without use of UML
On nearly every project of every kind (except for trivial code scripts) Webel IT Australia uses at least some analysis modelling with SysML. And yes, even on projects using Python, PHP, JavaScript, the Wolfram Language for Mathematica, or other languages that do not readily admit reverse engineering to UML.
Why? Because the graphical, model-based, systems thinking view offers a cognitive advantage over just using code. And especially because representing any system using a port-based engineering approach with a signal processing mindset helps you see your entire system differently (as opposed to code, reload, code reload, code reload bashing away at a keyboard and living in "Flatland").
Some actual examples:
Webel IT Australia developed a Mathematica application using the Wolfram Language for air conditioner heat exchanger calculations. It is a very complex problem. SysML was used throughout the project, and modelling the complex Wolfram Language code using the Webel SysML4Mathematica (v1) recipe proved extremely useful. In fact, cross-checks for some of the psychrometrics (humid air physics) and heat exchanger calculations were also performed directly on Magic Model Analyst® (Cameo Simulation Toolkit®) using SysMLv1 Parametrics:
The main recipe for SysML4Mathematica is recorded also in great detail here:
Another good example was use of SysMLv1 for mapping out an existing Python code MVP prototype and planning refactoring to reduce undesirable coupling on this project, and for documentation. Note that we aren't talking about "analysis paralysis" and trying to capture every aspect of Python in SysML!
That Python project did not just involve the Python codebase. It involved interactions with many other components, databases, other calculations services. The entire system of components and their dependencies were modelled in SysML, and the deployment to an Elastic VPS using Docker and Traefik reverse proxy web serving was also documented in SysML.
During a project
During development of the Arduino-based version of the accelerometer-driven Drancel Light Art system, SysMLv1 was used to record the entire development, including maintaining a registry of all electronics components and their serial numbers, and for creating a port-based signal view of the entire system. (Reverse-engineering UML was also for modelling the embedded C++ code for the Arduino microcontroller.) This is a good example (if somewhat trivial compared with industry applications) of a hybrid system with both physical and software aspects.
It's even quite easy to model electronics in SysML:
Webel Parsing Analysis for SysML as the meta-process
The primary weapon for SysML analysis modelling of software systems and hybrid systems in the model-based engineering arsenal of Webel IT Australia is the Webel Parsing Analysis recipe for SysML, which approach pre-empted the new generation of so-called "AI" based model creation and Large Language Model (LLM) and machine learning driven systems for creating SysML models from text.
The domain source document from which text "snippets" are sources for parsing analysis and traceable elicitation of model elements can be anything: device descriptions, formal requirements documents, quick meeting notes, etc.
You can even use graphics and diagrams from source documents as targets for elicitation of SysML model elements, and most good SysML tools like Magic Cyber-Systems Engineer® (Cameo Systems Modeler®) enable you to paste images into SysML Diagrams too.
What about SysMLv2?
SysMLv2 is not based on UML2, but that does not make it any less useful for analysis modelling of software systems, for introducing a "systems thinking" view, for creating port-based engineering and data and signal flow views, and for requirements engineering and project tracking! And just like in SysMLv1, you can create custom Domain Specific Language modelling elements (and you can of course still use custom icons too, which can be very useful communication devices).
Aside from direct use of SysMLv2 for systems engineering (and with its new textual representation modeling code), the modelling recipes Webel IT Australia has developed for representing interfaces and functions of languages such as the Wolfram Language for Mathematica using SysMLv1 Activities are easily adapted to use the new SysMLv2 modelling elements.
But that possible limitation is only likely to affect a small fraction of project kinds.
Webel IT Australia are specialists in combining SysML/MBSE with software engineering!
To learn how to effectively combine SysML/MBSE with any project involving software engineering, code, or protocols, attend our course: