Wednesday 28 October 2020

IBM Engineering Rhapsody Tip #87 - Custom browsers: A requirements Traceability example (Advanced)

This IBM Rational/Engineering Rhapsody tips and tricks videos follows on from the previous video (#86) on the SysML Profile's part browser. This video covers how it's possible to create your own "browse hierarchy' submenu's to launch browsers based on different context patterns. In this example I create a new browser for viewing traceability to requirements that mimics the Rhapsody Gateway's impact analysis view but doesn't require use of the Add On. I show use of the context pattern, including navigating reverse direction of a dependency (thanks' to Andy Lapping's digging in this area) and then use of a plugin method as part of the context pattern (I need to keep it as geeky as possible ;-). By extending Rhapsody with my own profiles, I'm able to focus SysML to specific tasks, making it easier for users to get higher business value earlier in their adoption lifecycle.

This caption-only advanced-level tip follows on from video #86.

The SysML Profile's parts browser provides an example of how Rhapsody can build a custom browser using a context pattern.

Let's create a custom browser for showing requirements traceability instead!

This Executable MBSE project has lots of traceability to requirements.

Conventionally, I may have used an add-on such as the Rhapsody Gateway to view such traceability. This can take a while to load though. 

Let's add a new browser to do this in Rhapsody instead. To add a new browser we need to create new properties. The New property button is not visible by default (it requires a rhapsody.ini tweak).

Top tip: Never edit the .ini file with Rhapsody open and always create a backup! 

To add properties via the UI we need to add ShowPropertiesButtonFromPropertiesPage=TRUE to the rhapsody.ini file.

To know which properties to create, I'll use the SysML profile as a guide. 3 properties are needed for each metaclass for which a right-click menu is desired.

Firstly, I'll create a Model::Project::BrowseHierarchy property on the Project metaclass. 

We'll define the value to make BrowseTraceability the [key] for the menu.

Now, I'll add a property using the [key] called Model::Project::BrowseTraceabilityName.

This will define "Browse Traceability" as the name of the sub-menu to add.

I now need to specify the context pattern. I'll create a Model::Project::BrowseTraceabilityPattern property for this. 

A context pattern is a way to describe a path of elements in the model. It's a comma-separated list of tokens. E.g., Look for nested packages, when you find a package, look for requirements.

Let's see if it worked?

Here's the new Browse Traceability menu!

The browser contains all of the packages (not just packages with requirements). 

Let's tweak the pattern. * means zero or more, whereas + means 1 or more.

That's better. The browser is now only showing packages that own requirements.

Next up, I want to find elements that trace to the requirements. This line says look at references which are dependencies and then go to the element that owns the dependency.

We can now see the elements that trace to the requirements. However, the dependency relation is also shown.

As a final example of tweaking, I'm going to use a plugin method. A plugin is a way to extend Rhapsody with Java code. Plugins run in the Rhapsody process.

This Java method is in my RPUserPlugin class for my Executable MBSE profile.

I'll replace the references check with this plugin method instead.

The element list below the requirement is now being created by the plugin method.

Job done! This view is rather similar to the Gateway's Impact Analysis view but I don't need to leave Rhapsody ;-)

Interested in advanced training or customizations? Email me.

Friday 23 October 2020

IBM Engineering Rhapsody Tip #86 - The Parts Browser - a SysML profile feature (Intermediate)

I wanted to show how it's possible to create a custom requirement traceability browser in Rhapsody. First off, though, it's worth understanding the Parts Browser in Rhapsody; a feature added by Rhapsody's factory SysML profile. The parts browser allows you to launch a browser to drill down a Block/part hierarchy tree. The parts browser is available as a submenu on the right-click 'Browse Hierarchy' menu  The browser is formed using a context pattern which defines how to traverse relationships in the model to form the browser. In this short, caption-based (i.e. silent) video, I show how it works and then look at some of the properties behind it. In the next video in this series, I'll show how it's possible to use a similar technique to create a browser for showing requirements traceability.

Here's the transcript for those that need it:

This silent video shows the Parts Browser: a SysML profile-based example of Rhapsody's 'Browse Hierarchy' feature.

The Parts Browser is added by the SysML profile, so let's create a SysML project.

The right-click menu now has a Browse Hierarchy > Browse Parts submenu (added by the SysML profile) which launches a Browse Parts window.

Let's create some blocks and parts using a SysML Block Definition Diagram (BDD). Use of Directed Composition relationships on the BDD will define the parts.

In the normal browser the tree stops at parts and we have to right-click to navigate to their types. The parts browser, however, allows us to drill down recursively, e.g. the itsBlock_4 part is typed by block_4.

The tree is dynamic. We can drill down the complete block/part hierarchy.

So, how’s it done?

Well, like many things in Rhapsody, it's done using properties, in this case conveyed by the SysML profile. These 3 properties define the Browse Parts submenu name and pattern (for a Project).

The metaclass for a Block defines its submenu name and context pattern. This context pattern includes displaying attributes/operations contracted on the ports.

Let's create a port with an interface to illustrate.

Now, if we right-click a Block then the context pattern we saw earlier will come into play.

We can create our own custom browsers, if we wish. In the next video in this series, I'll show how to create a requirements traceability browser! ;-)

Thursday 15 October 2020

Smartfacts: Model repository and web publishing for multiple tools not just Rhapsody

Interested in a model repository and sharing platform for many different types of modeling tools, not just Rhapsody? Check out the MID smartfacts technology:

Background: IBM Rational brand originally worked on the Design Manager repository-based technology, an ontological database with a Jazz-based client for web-based access. Originally they moved it to support their Java-modeling Rational Software Architect (RSA) tool. They then acquired Telelogic and began adapting it for Rhapsody, ultimately shipping a Rhapsody Design Manager (RDM) variant. At the same time a web-publishing adapter was also available for MathWorks Simulink models and was covered under the RDM licensing. With the move away from repository-based to the file-based Rhapsody Model-Manager technology (RMM), the Simulink aspect (and ability to write adapters to other tools) got dropped, potentially leaving a gap for companies interested in a library and linking capability for a range of tools. Could smartfacts plug this gap? 


Wednesday 14 October 2020

An evening or self-paced class for contractors/people looking to upskill?

I'm exploring the idea of running an evening/weekly call-type class or self-paced class for contractors/people looking to upskill with SysML/Rhapsody/MBSE knowledge. It's not entirely clear how much interest there would be in this, so I will do a trial if I can get enough interest. If you are interested let me know. I've updated the form here to give it as an option. 

A bit of background: Historically my training focus has been business-to-business, e.g. running private Rhapsody training for companies adopting the tools on either a one-off or a series basis. I did have a lot of success with open training run in conjunction with HORIBA MIRA but Covid-19 and other reasons have put a hold on face-to-face training. It can also be hard for individuals (contractors and engineers looking for personal development) to access such training as it requires a lot of commitment of time. I'm therefore thinking of some lighter-weight, more lower cost options that I could deliver now while lots of people are working from home, and across a broad geography (particularly outside the UK). 

Friday 9 October 2020

IBM Engineering Rhapsody Tip #85 - Using change events with SysML proxy ports (Advanced)

Ok, I'm back into more regular update videos. This again, is a slightly more advanced topic, although it also explains a little about what SysML proxy ports and Interface Blocks are and one of the ways they differ from standard UML ports and interfaces. This IBM Engineering tips and tricks video follows on from video #85 and shows how to get flow properties and change events to simulate with SysML proxy ports. The key thing is that in addition to using the change event and the auto-generated setter, you need to set both ports as behaviour ports. This is actually picked up by the Rhapsody model checker as a warning, as this short (and caption-driven, i.e. silent) video illustrates.

Here's some transcript (for those who want the gist):

Change events were originally developed to work with SysML flow ports. However they also work with SysML newer proxy ports. This video explains how to get them working for both.

In summary, change events are based on a ch followed by the name of attribute (with first letter capitalised). They require that the publisher of the change uses the setter. So, how do we get them to work for proxy ports?

Well, I proxy port is the newer type of port for SysML, and they work with Interface Blocks. Interface Blocks like UML Interfaces are designed to aggregate or group elements in a desired contract, i.e. they are not designed for single elements.
To flow data in an InterfaceBlock we would introduce an owned element called a flow property. Flow properties have a direction tag associated with them. This needs to be explicitly set to the direction the flow is occurring.

Proxy Ports can then be added which specify the use of the interface block.
 As the interface block is carrying flow properties, Rhapsody is showing direction inferred by their direction tags. The corresponding receiving proxy port is typed by the same interface block but is set to conjugated.

This is notated on the diagram by presence of the tilde symbol (~).
The ports can then be connected. This is almost ready to work. However, if I run now then you’ll see that the flow and change event are not occurring. A clue for the reason is actually picked up by the Check Model as a Warning.
If we want change events and flows to work for proxy Ports then we need to check the behavior attribute on the General tab for the port. If we only do this for the subscribing port then the simulation will still now work. This needs to be done not just for the subscribing port (with the reception for the change event) but also the publishing port.

Thursday 1 October 2020

Reflections from last weeks training

Training from last week was interesting. I realized just how much there is to take in when adopting model-based systems engineering for the first time. Enthusiastic people definitely help, not just engineers but also management giving them their support. It's not just knowing the ins and outs of the tools (both the modeling tool and how it integrates with others) either, there are so many aspects to the language and many ways to use it. It was good that we finished with workshop that looked at an example process though. I think when you see an end to end example built around your problem then it helps people appreciate how an appropriately selected process can significantly improve requirements definition and systems architectural work.

IBM Engineering Rhapsody Tip #84 - Getting statecharts to react to change events (Advanced)

This short and silent caption-based tips and tricks video came from a subscriber emailing me for help on getting change events to execute correctly with SysML proxy ports. In this first of two videos, I thought I'd recap some of the fundamentals about how change events in Rhapsody statecharts work, and what they're for. The key tips in this video are really that you need to make sure that you use the setter operation when changing the value of attributes / value properties. Setters and getters (what are often called a mutators and accessors in C++) are auto-generated. The setter will follow the convention of the word set followed by the name of the attribute capitalized. Change events are used as triggers in Rhapsody statecharts for reacting to a change of data. They also follow a naming convention which is the characters 'ch' (for change) followed by the name of property (capitalized). Hopefully the video explains for those who're interested! 

Here's some of the transcript, in case it helps:

Change events were originally developed to work with SysML flow ports. However they also work with SysML newer proxy ports. This video explains how to get them working for both.

In this project I have two parts both with a ‘batteryLevel’ property. In the IBD they’re connected via similarly named SysML flow ports; the port type introduced in the original SysML spec to handle data and material flow.
If I run the simulation then you’ll notice that the batteryLevel is not forwarded. This is because the setter is not being used in the sending blocks statemachine. Let’s correct that.
For those geeks amongst you, it’s actually the code in the autogenerated setter that causes the flow to occur. If you don’t use the setter whenever the value changes, then you don’t get a flow.
We’re now getting the flow. However, partC is not currently reacting to it. This is where a change event comes in. A change event in Rhapsody begins with a ch prefix.
You can now see the battery level change event occurring
In summary, change events are based on a ch followed by the name of attribute (with first letter capitalised). They require that the publisher of the change uses the setter. 

So, how do we get them to work for proxy ports? Well, that's the next video.

SchemaSys video link - Visualizing an electrical circuit diagram built using SysML

Here's an interesting link for people who might be interested in thinking outside the box (so to speak ;-). It seems that John Brush has ideas for visualizing SysML diagrams in more interesting and domain-specific ways, e.g., as electrical circuit diagrams!

Something to discuss at an INCOSE MBSE  working group meeting, perhaps ;-)