Hacker News new | ask | show | jobs
by kown7 1348 days ago
I feel the attempts to build SysML just have to go the same route.

Does anybody have information why this shouldn't be the case?

2 comments

I'm working in a project that uses SysML, an extension of the ISO standards group that originally developed it. There are problems in that none of the tools for it are compatible with each other but it works if everyone uses the same one.

I'm also looking at whether QVT will work for doing transformations between models.

An open source tool is also desperately needed imo.

I kind of like SysML, but where I've seen it on a large scale it has failed spectacularly. People spend their time trying to figure out how to model things and fiddling with the diagrams to make them look nice. Distributed work is hard because merging becomes unintuitive. I think it could work if one really committed and tried to figure out all the edge cases, but the types of people pushing it at my shop have never been interested in that.

Personally I tend to just use the SysML package for Visio and draw "SysML inspired" diagrams these days.

Eclipse Papyrus is open source, I have been told that recent versions have gone off in a strange direction though.

Our use case is to be able to create models, they are the deliverable. Merging is a problem for us too.

My view on SysMLv1 is that domain-specific modelling techniques or tools are almost always far superior, and SysMLv1 therefore becomes a burden as you have to use the other techniques or tools anyway, and SysMLv1 doesn't have much to offer on top.

SysMLv2[1], which is work in progress, is more interesting because it separates itself from general domain-specific modelling techniques and tools by:

* Allowing definition of requirements

* Allowing modelling and checking of constraints/assertions

* Allowing modelling and execution of verification methods

* Allowing trade-off analysis where objects are instantiated differently to assess impacts

* Having the concept of concurrent/parallel states

* Having spatial, time and units concepts built in

* Allowing modelling with event triggers (e.g. when X happens, then the object's Y property increases by Z)

Graphical notations are still there but I doubt they will get much use. Instead, SysMLv2 introduces textual notations and I would expect this becomes the easiest notation to communicate with. Even for Object Process Methodology (OPM) which is frequently touted as being one of the better general purpose graphical (with parallel textual) modelling notations for readability, I always look at at the textual representation as it is easier to understand.

I think the intent is that SysMLv2 would allow you to specify requirements such as (completely made up scenario):

* [Site X] shall be located at [coordinates X]."

* [Site Y] shall be located at [coordinates Y]."

* A minimum of 15 [sites] shall be located in [territory X]."

* "Each [site] shall have a [line of sight path] to two or more other [sites]."

* "[Line of sight paths] between [sites] shall be calculated using [XYZ:2022 standard]."

* "Each [line of sight path] shall not exceed a length of 50000m."

* "For each [site] located in [territory X], [planning overlay X] shall not overlap."

* "For each [site] located in [territory Y], [planning overlay Y] shall not overlap."

* "Each [site] shall have a [chance of flooding] not exceeding {some metric}."

* "[Chance of flooding] for sites shall be calculated using [XYZ:2022 standard]."

You can then write many of these requirements as constraints/assertions in the textual notation and embed other languages within the SysMLv2 textual notation or call external software tools so that constraints/assertions can be calculated externally with external data, for example, GIS tools and data or historical records.

[1] https://raw.githubusercontent.com/Systems-Modeling/SysML-v2-...