Aerospace Systems Engineer


A LinkedIn Tools Discussion

I have been chasing a tool to implement the methodology we employ in our system engineering process for many years, since before the three amigos came together.
Early on it was ROOM, then Rose, then TAU. In working with Telelogic (at the time) they said, like your approach and see value in the diagram, but its not UML so we wont support it. There is some material on my blog about this history, but that is neither here nor there.
I was involved in the OMG efforts toward SysML which rapidly became bloated and fractured, but that story is seldom told.
I thought SysML had some promise with the activity diagram with swimlanes. Pictorially it is analogous but the proof is in the metadata.

Your comment that UML/SysML can achieve my goal intrigues me, because I, working with several modeling teams, at a major Aerospace companies, have failed. I will readily admit this could very well be because the "modelers" were often Jr Engineers or, not systems engineers at all, but model builders.

The graphic is important but so is the underlying metadata. The tool should unambiguously link the two.

I am interested in;
Architecture - the actors and their life lines.
Behavior - Communication between the actors – messages, and the actions of the actors - Functions.

The UML/SysML activity diagram appears to provide the ability to assign an activity to an actor by its placement in the swimlane. But the model doesn't know or enforce this. The graphic interface doesn’t generate the meta data. Thus we miss a valuable brainstorming aspect.

Also the activity diagram doesn't contain message traffic, thus no triggers for the activity.

When you have a trigger, an actor and an action you have a requirement. "Upon trigger, the actor shall do X". Thus this Use Case behavior analysis as scenarios of behavior fulfills the key SE function of requirement decomposition.

My visio based tool understand the source and destination of a message, and understand the owner of each function. This is provided by the connections to the lifeline. It also understands sequences of the scenario. These are UI generated metadata, not attributes that must be added by the modeler. The tool also provides the opportunity to enter additional data in the message and the functions (actions) and visio captures this in its database. The report function of visio can extract this data and generate a companion table (we call the event flow table) which supports the graphic.

The graphic is much more than a diagram, its the UI, and the metadata.

The touted extensibility of these open systems is typically in areas that really provide little utility, but great opportunity for "modelers" to tinker, and keep Systems Engineers from getting the job done. Happy

The extent of possible diagrams bewilders the junior engineer and they typically think they have to do all of them and with every option. I can't fault the tool for that. Happy

Frankly, and finally, I have heard some good things about Artisan. It was recommended to me by an engineer I respect. I had a trial version, was just before a buyout or name change? A few years ago? I haven't given it a fair assessment. I think there was a foreign ownership issue as well?

At any rate. The slide presentation covers the method and the utility of the diagram in some detail. But only really alludes to the utility of the tool's UI and metadata capture utility.

Feel free to take a more in depth look at the Visio tool.

Nothing would please me more than to find a tool that efficiently supports our needs of brainstorming and robust metadata capture.