Understand the art of the possible. My mission is to make executable Model-based Systems Engineering (MBSE) easy with the Object Management Group's Systems Modeling Language™ (SysML®) and UML® to make simple modeling easy to deploy to the masses. This site provides practical experience of tuning IBM® Rational® Rhapsody® - a precision engineering UML/SysML tool. Rhapsody tips and ideas will be posted with links to videos. You can follow by email (if google app is allowed).
In case you're interested, e.g., planning RMM upgrades/installs upgrades, Jazz.net provides a source of wider information, e.g., known issues and limitations articles:
One to be aware of is the Windows file path limitation. This is one reason why I set my sandbox areas to be C:\workspaces (or something short like this).
I'm a big fan of not just tracing model elements to requirements but using use case analysis to define requirements for a system. I like the analogy of how modeling provides a powerful and visual workshop in which requirements can be forged and the requirements management is the "gallery" where the resulting works will be exhibited moving forwards. This isn't just about creating requirements to manage but rather finding way to get a better and more complete set of requirements to manage, and also the use of diagrams to communicate in ways which textual requirements cannot. This is video I cover some of the provisional work I've done in adapting my methods, like ROCKETS (R=Requirements), to work with Rhapsody and Jazz/rm (aka DOORS Next). In this work I use existing technology in the form of the csv importer to first get the requirements into a DOORS Next module. I then add the requirements to the model and use a profile helper in Rhapsody to perform the switch. The good thing about this technique is that it means that my helpers work for wide variety of different Rhapsody and Jazz versions and is not tied to an API or the need to do authentication to achieve the sync, i.e. it's not ROCKET science but it helps load the payload into the ROCKET using a 10 minute method.
Here's the transcript:
This silent video covers some development work I'm doing on my profiles.
Some who've followed me may have picked up that I see value from dovetailing use case steps with textual requirements.
Creating requirements from textual activity diagrams for use cases is stage 1 in most of my MBSE methods, including my executable MBSE method called ROCKETS.
To help achieve quick success from MBSE quickly and systematically I've written profiles like this ExecutableMBSEProfile to set up the tool to provide a "10 minute" method.
Diagrams like this are highly accessible because most people can understand flow-chart like semantics with limited training.
For use case modeling, we can use decision nodes to show alternate paths (e.g. sunny and rainy day) on the same canvas.
Diagrams are richer than text, e.g., you can also show things happening in parallel.
Interruptible regions like this can also be powerful, e.g., to show things being interrupted by events.
Importantly people can read a flow-chart like syntax without needing much training, including users.
The Requirements Analysis stage of ROCKETS, focused on the production of formal requirements using use case steps as a stepping stone.
Requirements are the formal hand-off but they are fortified by the understanding conveyed in the diagrams.
In this particular method, all use case steps and guards must be traced to reviewed requirement(s) before hand off to the next stage.
The profile provides automation to make this easy to do, once the use case steps have been reviewed with stakeholders.
As well as being fun this can lead to a surprisingly complete set of functional requirements when followed through to fruition.
Use case steps are not requirements and requirements are not use case steps. However, they are both enhanced by dovetailing them together.
To accelerate usage, my helper profile has automatically moved the Rhapsody requirements into their own package.
The end of the Requirements Analysis stage involves getting Rhapsody requirements into a formal requirements management tool.
Previously, my methods worked well with the Gateway Add-in and DOORS 9. Moving forward there is a need to be able to switch requirements to DOORS NG (Jazz/rm) without the Gateway.
I want to show you some early work, I've done to achieve this.
Firstly, I'll create a module in DOORS Next where I want the requirements to go.
To get them into DOORS NG I've written a helper to first export them into a CSV file.
This isn't rocket science. However, using the csv import works for all the versions of Jazz, i.e. makes things less coupled to specific versions.
I'll now choose the CSV file import in DOORS Next and select the module I want to import them into.
I'm treating the model as the 'workshop' where requirements are forged, and the requirements management tool as the 'gallery' where they are exhibited.
Next we need to create a view with just the requirements we want to sync back to the model.
Creating shared views are how we aggregate the requirement artifacts we want to trace to the model (include the name of the module here).
We can now tell Rhapsody to load the view we just created into its remote artifacts package for the RM Project.
Remote artifacts are visible in the Rhapsody browser but stored on the server.
To get my automation to switch the Rhapsody requirements to their Jazz/rm counterparts, I first add them as OSLC links to the requirements package.
Finally, I run a "switch requirements to DOORS NG" command that I added to my profile's right-click menu.
This does the switch on all the diagrams and removes the old requirements
All the requirements are now actually in DOORS Next (Jazz/rm).
Before delivery, I'll also run my profile helper to rename action/event names on activity diagram(s).
I'll now deliver the changes so that OSLC links can be seen in DOORS NG (Jazz/rm).
I can now add a column to DOORS Next to show traceability to model element(s).
My renamed actions are nicer to see here.
To finish off, I'll just publish the diagram to Jazz also. Here's the diagram in the web client.
People can review the requirements and use cases using a web browser. Using my profile, we've created formal requirements that tests and design elements can trace to, in less than 10 minutes ;-)
Interested in Rhapsody customization, MBSE methods or Rhapsody training, then feel free to email me.
Last week I did another 3-day remote Rhapsody training for customers of an IBM business partner again. It still amazes me how much there is in SysML and Rhapsody to teach and it's not easy in 3 days. What seemed to work well this time was to actually model the use cases of their system with them. I think this brought into perspective how it might add value in their context. I doubt that 3 days is enough to learn Rhapsody but I think that it provides a solid foundation level of knowledge to then use, to make decisions about how to apply, and also the importance of adapting the training to the participants to make it relevant and fun.
This is the second of two videos that explores how Jazz-based Rhapsody Model Manager workings have changed in the 3 releases from 6.0.6 to 7.0.1. It follows on from tip #88. The main change is that the /am functionality is now provided as an extension to the /ccm application. This means that work items and model management are stored in the same repository. There is also a new license that enables the /ccm server to be used for either just Rhapsody models, or Rhapsody models and source code. In this caption-based video I look at a few aspects of using 7.0.1, including associating changes to work items, and being able to do more functions like accepting change sets directly from the Rhapsody browser. I also recap how to establish links to requirements in the IBM Engineering Requirements Management DOORS Next application (/rm) - although this is not new.
Here's the transcript in case it helps:
In this silent video, I look at enhancements added between 6.0.6 and 7.0.1 in Rhapsody Model Manager (RMM) - the server-side technology for managing Rhapsody projects in IBM's Jazz platform.
Remember, in 7.0.x Jazz, RMM is now part of the /ccm application, not a separate /am application.
This makes integrated work item planning easier, as it's now managed by the same /ccm Jazz application as the change sets.
In 7.0.1, a new RMM license called "Model Manager - Systems and Software Engineer" is used rather than the "Design Manager" license.
Let's make changes to our model under RMM 7.0.1 control.
As in 6.0.6, I can also add OSLC links to requirements stored in the Jazz-based DOORS Next.
From Rhapsody menus, we can exploit Jazz governance and change tracking, e.g., associating changes with work items in /ccm.
Here we can see that the change set has been attached to the work item.
The Engineering Workflow Manager (EWM) Eclipse client still provide more advanced configuration management features such as work item editing.
Tight integration between model management and change management means that linked data and history is automatically captured.
You can also manage things like approvals and reviews using work items linked to elements under review.
Another key theme in the 3 releases since 6.0.6 has been additional menus enabling more EWM commands in the Rhapsody browser. Let's switch user.
Having got Bob to deliver his changes, I've switched user to Deb now.
She's notified of Bob's changes.
She can see there are changes directly in the Rhapsody browser from the descandant overlay icons.
She doesn't need to leave the Rhapsody client to know that changes have been made.
This is new! In 9.0.1 Rhapsody, she can accept incoming change sets directly from the Rhapsody menus.
Her Rhapsody model has been updated with the changes made by Bob.
To finish off, let's have a look at the RhapsodyModelManager > Requirements Coverage Table.
Here we can see the traceability that the elements in this package have with requirements, including those in DOORS Next.
Interested in RMM or Rhapsody training/customisations? Email me.
One of the areas where the IBM Engineering Rhapsody development invested a lot of effort in the last 3-4 releases is in its integration into the IBM Jazz platform with the Rhapsody Model Manager (RMM) server-side technology. This is crucial, of course, for its integration with DOORS Next generation, IBM's web-based Requirements Management (RM) technology built on top of Jazz. RMM also enables web views of the model and linking with work items and planning and shared configured access to models. In version 7 of Jazz there was a significant change, in that the functionality provided by the /am application became an extension to the /ccm application, rather than a separate entity. Over the releases they've also done work to make more functionality available directly in the Rhapsody browser. In this first of two videos, I wanted to give some examples of things that have changed (especially to those who are user older versions and thinking of migrating).
Here's the transcript of Part 1:
Rhapsody Model Manager (RMM) is the server-side technology for managing Rhapsody projects in the IBM Jazz platform.
To enable me to create/update my training for different Jazz releases, I've installed a local 7.0.1 Jazz server using a Hyper-V virtual machine (in Windows 10 Pro).
In this silent video, I look at some of the key differences I've noticed in the 3 releases from RMM 6.0.6 to 7.0.1.
An obvious change is the renaming. Engineering Workflow Management is the new name for Rational Team Concert.
Not too many changes in the Eclipse client. It still performs the role of allowing access to deeper workflow management features.
There's still lots of stuff available here like baselining, data feeds, diff/merge, work item editing, creating components and workspaces.
Let's launch Rhapsody 9.0.1 for the 7.0.1 server. This too has been renamed for 9.x (dropping the 'Rational' branding).
This project has been disconnected from the server, so l need to re-attach it to the server.
As before, status icons show use the status of units under configuration management.
There's some new functionality related to seeing the descendant unit's status though.
The smaller overlay icon in the top-right, tells me that a child unit has changed enabling me to know where changes are in the tree.
Also, the older Team Concert menus are now split across the Unit and Unit with descendants menus.
The Unit with descendants menus makes it easier to do SCM functions further up in the browser tree, e.g., deliver or accept changes.
The status icons are updated and the output window includes slightly more information than in 6.0.6.
Let's try making a diagram change.
As usual with Rhapsody, there are some properties that will control behavior, e.g. diagrams will be updated on deliver according to this policy.
The default Save policy will be to check in the changes and Deliver will deliver the changes and update the web views.
You may notice a bit more information in the web client (compared with 6.0.6) and the diagram was updated (actually this was in 6.0.6.1/Rhapsody 8.4 also).
So, here's the biggest change in 7.0.x. No, not the black bar, but rather the /ccm application has taken on the role of RMM as well.
Let's review of the Jazz applications.
Engineering Insights is what used to be called RELM.
"DOORS Next" name makes an appearance in the menus (/rm).
Quality Manager is Test Management (/qm).
Team Concert is Workflow Management (/ccm).
/am is no longer a separate Jazz application. It's combined into the /ccm application (when installed correctly, the /ccm project area can be configured to enable model management)
This makes it easier to install/deploy but is something to consider when upgrading from pre-V7.0 servers. It also means that a same /ccm project area can provide access to both model information and work items.
I'll cover this in Part 2 and also the ability to accept changes from the Rhapsody menus (stay tuned ;-)
Interested in RMM or Rhapsody training/customizations? Email me.
This week I did another (free) workshop with the engineering apprentices on Requirements Management. I learnt that there's hope for Star Wars yet. At least one 3 year girl with Star Wars wallpaper, duvet and a Lightsaber (I think this is a new hope?). I think this means it's just skipping a generation.
What else? Well, requirements can get a bit messy to begin with, especially if you're messing around with different tools - Teams whiteboards/Google jamboards (hey that's like reality till you get proper in place right ;-).
I also learnt that engineering apprentices are more creative at creating requirements for an Ironman suit than I am (no surprise there). Alas, I didn't get them all into an RM tool in time though.
Also, a well timed Kahoot quiz, leaves nowhere to hide ;-) This is actually quite a fun thing to do with online training. I might do a bit more using this going forward.
Last week I did some (free) MBSE awareness training with some engineering apprentices. I learnt that "star wars" is not a thing. Apparently, there is a film called "ironman" that I should've watched and that ironman is not ironman until he puts on some "special" suit, and that the suit actually can make it's own decisions (which is important to know upfront but sounds a bit dangerous to me ;-)
Subsequently, I did find out from Barclay Brown that Jarvis (actually an acronym) is the AI that Tony uses, and is distributed with parts of it executing in the suit and parts executing on servers in Tony's Malibu basement or elsewhere in the cloud we hope, at least when the Malibu house is destroyed. In any case, Jarvis should be an actor. Also, the suit is able to communicate with and control other suits (depending on which movie you are referencing). The suit may also communicate with some kind of enclosure, like the briefcase in Ironman 3 (?), though the briefcase could perhaps be considered part of the suit, especially if it goes WITH the suit after suit deployment. For yet more subtlety, it seems that the suit can have a 'guest' wearer, who is more like a passenger, with the suit being controlled externally, such as when Tony puts the suit on Pepper to protect her from the attack on the house, so perhaps guest/passenger should be an actor!
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.
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! ;-)
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?
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).
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.
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.
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.
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 ;-)
The Unified Architecture Framework is based on the Unified Profile for DoDAF and MODAF™ (UPDM™) and defines ways of representing an enterprise architecture. The UAF enables stakeholders to focus on specific areas of interest in the enterprise while retaining the big picture and builds on standards such as UML and SysML.
One of my earliest IBM Rational Rhapsody videos ends with a demo that shows a customisation I made to my SysMLHelper profile around 5 years ago (video tip #8) to Rhapsody enhanced tooltip feature. It doesn't go into detail about how I achieved it though and a few people have asked. Actually, in doing this video I realize that the property I used to hook the plugin method into the profile is no longer documented in the product, which is why people have asked! It still seems to work though (up to 9.0.1) hence I've put together this "under the hood" look video. The property is called Model::Stereotype::ModelTooltipPluginMethod. This 5 min video, for advanced users of Rhapsody, also gives a bit of a look at the role of customizing Rhapsody with Java plugins, profiles, and properties. This video is a silent one, i.e. you'll need to read the captions to understand it.
This is one of my more involved and narrated videos. It covers the topic of domain specific profiling with IBM Rational Rhapsody. In it, I give a glimpse of an example profile for automotive model-based systems engineering, showing how it's possible to add new term element types and diagrams to make SysML/UML more easily consumable when following a chosen method. Domain specific profiling in Rhapsody is controlled via properties on stereotypes. At the end I also show one of the more advanced techniques I've moved to is to build and maintain such a profile using model-based techniques, i.e., drawing a class model of the domain specific meta-model that represents the element types (also known as meta-modeling! ;-).
Here's the transcipt:
In this video I thought I’d give a short insight into what a domain specific profile is. Some of the benefits… and how I go about this in Rhapsody now, based on my experience.
Firstly, a profile is type of package that extends the UML language. Profiles contain stereotypes to represent new concepts and meanings. Profiles can also add tags and, in the case of Rhapsody can convey properties that change the user interface.
SysML, for example, is a profile that extends UML, and it contains a stereotype called a Block. Whilst a block in SysML is a general-purpose element for architectural specification, within any given model there likely to be different types of blocks. We could further classify or replace the idea of a Block using stereotypes of our own.
For example, here I have the prototype for a profile I’m dubbing as my 'Autobahn Profile' as it’s designed to speed up the journey into productive model-based systems engineering, and builds on my automotive sector experience. In this profile some Blocks may represent systems while others may represent subsystems or functionality performed by subsystems.
Having created these stereotypes I can use them in the browser. Let’s create a logical system package with a logical system element inside it. Here the browser is representing these new term stereotyped elements as part of the tools’ modeling language, including given them their own categories and icons in the browser.
Stereotypes are a bit like fancy dress. We can stereotype base UML elements to give them new meaning.
With Rhapsody, unlike some of its competitors such as Cameo, the extension mechanism for writing a domain specific profile does not require you to write any code. It is based instead on static values set in profile and stereotype properties. The use of New terms like this Logical System stereotype I’ve added here, can be conveyed by the profile in such a way that they change the Rhapsody menus.
New term stereotypes can also be applied to diagrams. Here’s a stereotype I’ve used to create my own Architecture Definition Diagram type. The drawing toolbar for the diagram has be customised using properties on the stereotype. This enables me to add new classifications of element types to the drawing toolbar, but also subset default element types so that users are not burdened with unnecessary choices.
Let me quickly change this diagram back to the standard Object Model Diagram type. Here you can see if has options such as Objects, Classes, Associations, and Links. By applying the new term stereotype, I can specialise and simplify the available palette of tools. I’ve essentially created my own domain specific Block Definition Diagram type, albeit that I’ve further classifiers such as logical systems, logical subsystems and subsystem functions.
This makes it clearer and simpler for a non-SysML expert to draw a necessary structure, as they can work closely with more familiar terms.
A system comprises of subsystems, and subsystems own subsystem functions. By using this domain specific profile, I’ve made a choice about how to adapt the generic SysML language up front rather than leaving it to end users. This reduces the burden placed on end users to choose how to represent their concepts.
Using properties on the elements, I have also applied some more direct constraints. For example, subsystem functions can be used by subsystems and by not systems.
This makes it possible to achieve a more consistent outcome with less training. Such customisation's become valuable at scale when you start to deploy MBSE in a mass- user environment where black belt SysML experts are not 10 to a penny, rather everyone has a job to do and a limited time to do it.
In building a number of these profiles for different clients, one of techniques I’ve centred on is the use of different package types to simplify menus to role-based work. Here, for example, you can see that there are a number of different package types I’ve made available on the right-click menu for the project.
For example, I quite like the idea of a use case package, where the right-click menus are simplified for just elements needed for use case analysis. As I want use case analysis to be by a domain specialist, I’ve removed SysML types they don’t need like Blocks, Parts, and Ports. In this instance I haven’t actually added any new concepts. I’ve just simplified the menu so that the users working on these packages can focus on the job at hand.
I quite like this idea of sub-setting packages in this way. I also like the flatter, ordered structure that new term package types can give, so users do not have to drill too deep to find the area of the model they’re working on.
That’s just a very short introduction into what domain specific profiling is and some of the benefits such as easing adoption by domain specialists, improving the consistency of models, and simplifying training by removing the need for all end users to learn the full breadth of the UML and SysML languages.
I wanted to finish off by just giving you a glimpse of how I now approach building profiles like these for customers. As you can see here, the profile is specified using properties which formulate how the menu should be structured and what the context menu of an element should allow.
For small profiles these can be doctored by hand. What I found through experience is that manually keeping all these properties in synch becomes exponentially harder as you progressively add new terms, especially as names of things often change during the forging of a profile.
To solve this issue, I’ve created a meta-modeling profile and plugin to apply a model-based approach to building up the profile properties. This enables me to draw the relationships I want between meta-types and get the code to automatically update the corresponding property values. This makes it much more fun. For example adding a composition relation will allow a nesting in the browser and using an aggregation relation will add the element type to the drawing toolbar.
To illustrate this, let’s look at an example. Firstly, I’m going to add some new icons to the profile’s Rhapsody project. These will be used to represent a new type of package called an Actor Package. Actor Packages will perform the role of housing Actors shared by other packages, and will have their own icons to distinguish them in the browser.
I’ll now add a stereotype to represent the Actor Package type. I’ll make this a New Term stereotype applicable to the base UML Package type. Checking the New Term box tells Rhapsody that it needs add Actor Packages as a category in the browser, and also means that some properties applied to the stereotype will come into play.
Let’s use these properties to specify a new icon for Actor Package elements in the browser. I’ll also set this separate property that specifies which icon to use when displaying a category grouping elements of this type.
In general it’s better for stereotypes to not have spaces in their name as it makes managing the properties for them easier, so I’ve not used spaces in the browser, and will give the Actor Package a human readable name via its property instead.
I’ll also give it a category name for use in the Rhapsody browser. Using a number here is a trick that I use particular for new term packages, as it acts to order to the package types in the root of the Rhapsody browser, making them easy to find. This will become more obvious in a minute.
I’m now going to switch to the metamodel that I’m using to maintain the menu related properties. This is declared separate from the profile, using a class model, hence doesn’t need to be deployed to end users. As I mentioned, this metamodeling-based approach enables me to build the menu structures graphically. As I can’t draw class relationships between stereotypes I will use a stereotyped class in the model to represent the stereotype instead.
To begin with I need to add a class to represent the Actor Package. I’m using a stereotype in my metamodel profile to represent that this is a new term. I’ve draw a dependency to bind this class to the stereotype I want the properties to be updated for.
A number of classes are already specified in the metamodel for this profile. I want Actor Packages to be available on the right-click menu for the project, so I’m going to use a Composition relation to specify this. I’ll drag on the class representing the AutoMBSEProfile and draw the composition. I also want actor packages to be in the right-click menu for elements typed as use cases packages, so I’ll drag that concept in from the browser and draw another composition relationship.
Finally, I’m going to use a stereotype to say Actor Packages it should be placed in the AutoMBSE Element submenu. At this point I can run the plugin code that sets or updates the properties based on the metamodel I’ve specified here.
This can take a minute or so but is a lot quicker than trying to find all the necessary properties and update them by hand, especially when the number of terms becomes large, or you want to tweak or change their names. As you can see here, the meta-model plugin displays the aggregates properties for the new term element types in a simple table.
This allows me to spot mistakes. For example, my new actor package is missing some element types. I forgot to say that I want Actor Packages to contain actors, for example. To do this, I’ll drag in the UML Actor type from the base metamodel package. I can then draw a composition relationship to say that Actor packages can contain them.
There are also a number of types that I want all Packages to have such as Comments, Tags, Dependencies and Hyperlinks. Rather than draw these individually I’m going to specify these base relationships using a Generalisation relationship to a base Package type. My plugin code will look at the relations of the inherited metatype when forming the property values.
If things start to get complicated I can get Rhapsody to re-lay out this metamodel diagram with a hierarchical style.
Once I’m happy the desired relations are in place, I can then rerun the plugin to set the necessary properties on the stereotypes. This will include the property that determines the right-click menu structure. Again, this can take a while but is a lot easier to do with the profile doing the work for me.
Now we can see Actor Packages are on the right-click menu. By controlling the menus in this way, it’s easier to direct a team to produce more consistent output. Consistency about how projects or parts of projects are developed can also be valuable when chaining methods together, for example, taking the outcome of use case analysis and consuming them in further downstream analysis such as building an interaction model with executable state machines.
We can think of the team developing the model as a system, where different parts of the system work on different packages and hand off or consume artefacts of others.
Packages are also the default granularity for configuration management of Rhapsody models, and can be shared by reference between different projects.
This concludes the demo for now. The profile I’ve shown here is a prototype of my Autobaun profile, so if you’re interested to know more then let me know and I can maybe show you a few more details.
That’s it for now.
My name is Fraser Chadburn and I’m a specialist in model-based engineering with Rhapsody. As well as developing and delivering tool-based training for Rhapsody and IBM products, I specialise in providing consulting for clients to achieve higher value by extracting the best from their tools. If you do have any questions then feel free to drop us an email.
I did this tips and tricks video in response to a few questions that people have asked as to whether they should tick the box to generate code for use case and generate code for actors? To answer this you need, of course, to understand better what you're doing when it comes to system simulation.
In this video I look at the concept of actor test benches. An actor test bench is part of a simulation that plays the role of an actor. By including the actor in a higher level system, you can show the interactions that is has with named external entities, rather than with the system border. In Rhapsody, this is possible because actors have full classifier status, i.e. they can have ports, operations, event receptions (signals), and state machines, in the same way as blocks do. This is one of my silent videos (it takes longer to create videos with sound, hence I need to balance my time with paid work).
Note: This is not the case for all UML/SysML tools.
This is the transcript:
Rhapsody’s code generator is used for both software (embedded C++/C) and systems engineering simulation.
Occasionally I get asked what the checkbox means to generate code for actors and generate code for use cases. In this short video I will attempt to explain it by creating a simple simulation model.
The first thing to note is that Actor and Use Case are types Classifier in Rhapsody. This means that they can have operations, attributes/value properties and state behavior just like Blocks.
Use Cases can therefore be placed sequence diagrams and used in the same way as if they were a Blocks, e.g., receiving signals or sending events or invoking operations. They could also own state or activity-based behaviors.
This should answer the first question, which is why one would tick the box to generate code for use cases?
Of course, if you do this then you need to treat the Use case as if it were a Block being used for simulation, i.e., set the name as legal as I’m doing here by changing its name to Camel case.
Now I can simulate the behavior of the use case by injecting events and see the changes in state on the animated sequence diagrams. The Government actor here. However, is not sown as injecting the event but I could drag a System Border on to show that the event is coming from outside the use case classifier.
Suppose, that I want to show the event as coming from the actor?
Well, this is where the concept of what is conventionally called an Actor test bench comes in.
Let’s create a build that includes the actor and the use case.
I’ll connect them for now, using rapid ports. Rapid ports are ports that have no interfaces. They can be used for building simulations quickly.
An actor test bench is one that has its own behavior, typically described using a state machine. We’ll get this statechart to send a antibody test event to the port, whenever it receives it as a trigger. We’ll do the same for the test invalidated event.
These are both reactions in state as no state change is needed.
Now, instead of building a simulation of the use case, I’m going to build a simulation of the test bench and it’s owned elements.
In this instance, I need to make sure that generate code for actors is checked.
The Government actor is now bold in the browser. This means that it is in the scope of the build, so I’ll regenerate and build the application.
In this simulation, the Actor test bench is now in scope and has it’s won state-based behavior. I can stimulate the simulation by getting the actor to generate the event on the use case.
Of course, it’s possible for the actor to have more than simple forwarding behavior. However, the approach shown here is the basis for how testbenches were designed to work with the Hamrony/SE toolkit.
This answers the question as to why one might check the boxes to generate code for actors and use cases?
Hopefully, that helps. If you need any more help, or want to discuss hands-on tool-based training options tailored to your company then let me know.
Slightly delayed on getting this one out but this is the seventh in a series of videos on the different types of diagrams in UML and SysML.
This short video (unusually with audio!) covers Package Diagrams one of the simplest structure diagrams that SysML inherits unmodified from UML. In general they show containment and dependency relationships between packages, although it's important to note that any of the structural elements might also be shown such as nested hierarchies of requirements or blocks.
The video covers some tips and tricks to get the most out of Rhapsody including setting the TreeContainmentStyle property depending on the style of containment relationship that you want to show. The video uses Rhapsody 9.0.1 (released July 7 2020).
Here's the transcript (in case people need additional info to help understand):
This is the seventh in my series of videos on the different diagrams in the UML and SysML languages. In this video, I’m going to cover how Package Diagrams are implemented in IBM Rhapsody.
Package diagrams - like use case, sequence, and state machine diagrams, are inherited into the Systems Modeling Language directly from the UML without modification.
The PDF I’m showing here is actually the first UML 2.0 spec from 2003. Here we can see that it states that there are no strict boundaries between the different structure diagram types, and it is possible to display elements such as objects, classes and packages, in any of the variations, it’s just that usually package diagrams are focused - as you’d expect - on packages.
If I switch to the UML menus in Rhapsody so that the SysML profile is not active, then you’ll notice that Rhapsody doesn’t have an explicit Package Diagram type, rather it expects an Object Model Diagram to be used for this purpose.
It does this on the basis that the Object Model Diagram drawing toolbar already allowed in 2003, the modeler to draw any of the structure diagram elements including objects, classes and packages.
If I switch back to the SysML menus, however, you’ll see that there is an explicit menu for a Package Diagram, and that the SysML profile has added this to Rhapsody’s pop-up menus.
Package diagrams are one of the simplest diagrams in the UML’SysML language.
Since all diagrams SysML have a diagram frame, the fact that this is a package diagram can be seen from the pkg abbreviation in the top left-hand corner of the frame.
Packages in Rhapsody are shown with a blue folder icon. They act like folders and are used to split up and organize model elements for access and understandability.
In the case of Rhapsody, they also map to separate units, or files, and hence form the basis of configuration management operations like check in and check out, and for sharing of common model elements between different projects.
Packages, like folders on a file system, can be nested underneath other packages. The package diagram allows useful groupings such as these to be visualised on a diagram.
If you try to show something out of context, then you can see here, that Rhapsody denotes this with a dashed line.
In this instance, I could right-click to change its ownership, in which case the browser will re-structured to match the diagram.
The Nesting style shown here is using Rhapsody’s default display option.
If we look in the latest SysML specification, Figure D.3 here shows us the two different containment notations. Both mechanisms shown here are possible in Rhapsody, but you may need to set a display property to get the top-one to work.
Let’s have a go at drawing this diagram. I’ll add a new package diagram to the HSUVModel package, but before doing anything else, I’m going to set a display property on the diagram called TreeContainmentStyle.
This notation style is also referred to as “alternative membership notation”. The property could be set at diagram, package, or project level.
It can be used to depict hierarchical relationships, not just with packages but also other model elements such as requirements, diagrams, and blocks.
With Tree Containment Style set, if I drag elements from the browser then the containment relationship will be populated on the diagram.
Before doing this, I’m just going to set the default display size for packages, to the one that I’ve got here. These means that when I drop elements on the diagram they’ll take this as their default size.
Notice that in 8.4 onward's I can drag a group of elements from the browser, by dragging the category to select them.
Here we can see that any existing containment relations we will automatically populated, if we drag something on to the diagram from the browser.
Conversely, If I remove the relationship in the model then the diagrams will be updated accordingly to remove the containment display, so that the diagram and model are always in sync.
If the related elements are already on the diagram, then we can choose to populate existing relationship using the Complete relations menu in the main Layout toolbar.
Notice that I can drag any model element on to the diagram.
For example, here is the containment relation shown between the HSUV Structure package and the Automotive Domain block.
The second form of the containment notation will still work with the TreeContainmentStyle property set. This is the default way of showing the HSUV Specification is underneath the HSUV Requirements package.
Package diagrams are also used to show other types of relationship between packages. Most commonly these are dependency relationships with stereotypes applied. The stereotypes could be built in or user-defined.
Here I am saying that the HSUV Use Cases package has a Usage dependency on elements in the HSUV Requirements package.
Profiles are types of packages and can be used on package diagrams in the same way.
If a profile is not globally applied but contains properties that you want to apply to only part of the project, then it can be applied to a package and its children using a built-in Rhapsody stereotype called AppliedProfile.
Sometimes I use colour to differentiate profiles from packages on the diagram. There are no conventions in the use of colour in SysML or Rhapsody, however. Of course, you must be careful in using colour alone as a reasonable proportion of the population is colour blind, hence other formatting could be used.
Don’t forget that you need to set the TreeContainmentStyle property if you want to show containment links on diagrams and that it’s perfectly possible for package diagrams to contain model elements other than packages.
There we have it. Package diagrams. One of the simplest structure diagrams that SysML inherits directly from UML without modification.
My name is Fraser Chadburn and I specialist in tool-based training and consulting in IBM products and in particular in setting up Rhapsody using domain-specific profiles.
Using Java automation, I can simplify and speed up modeling tasks so that users can focus on creative and fun systems and software engineering.
If you do have any questions, then feel free to email me.
Over the last 5 years I've been delivering hands-on tool-based training to a variety of Rhapsody customers. This has meant that I've developed 21-26 hours of labs that can be done with the latest Rhapsody releases. This is much more than can be delivered in a 3 or 4 day training hence I usually do a call with a client first to decide what they really need. Here's the latest Lab Menu IBM Rhapsody HandsOn Labs Menu - V11 - 16 Jul 2020 - 1.pdf: .
If you're looking for tool-based training in Rhapsody then let me know.
Just a quick note to say that I uploaded some fixes to create a v3.0.x version of the SysMLHelper on www.executablembse.com. For those that don't know I host this an open source project on GitHub (with a GPL 3.0 license).
The SysMLHelper profile is a super-set of profiles and actually includes a number of different profiles that re-use a common Java code base:
a) A backwardly compatible update of the original v2.0 SysMLHelper profile
b) An ExecutableMBSE profile (my new term update to the original SysMLHelper), and
c) A FunctionalDesign profile (the first example of a few).
d) A Tau G2 model migration profile (work done for a specific customer).
I have a second stream of profile development underway focused on a function block-based Automotive Profile.
This new stream includes better meta-modelling support to make it easier to build Domain-Specific profiles with Rhapsody very quickly but is not yet available for distribution. This also follows the principal of re-using Java code for Rhapsody helpers so that it's quick to create customer-specific versions that are packed with usability features.
It's similar in thinking to some of the work I'm being doing this year with automotive customers. This work has "driven me" ;-) to use meta-modelling and advanced customisation techniques in Rhapsody to build custom profiles for automotive systems engineering with Rhapsody. It also highlights how automotive differs from other sectors in the way it "thinks" (particularly when it comes to functional safety and ISO 26262 although one could argue it both ways about the challenges of this).
We're all creatures of habit, I guess, hence we tend to find our own ways of doing these and sometimes it's not always the fastest. This short (and mostly silent) tips and tricks video for the IBM Rational Rhapsody UML/SysML tool came off the back of a recent webinar I did with IBM where somebody pointed out a shortcut I don't use for one of the menus that I use all the time. This made me think that a little video on shortcuts would be a good refresher for people. The video covers some "accelerators" (keys that perform actions) and modifiers (keys that modify actions) that you may or may not know.
Here's the transcript:
This short (and mostly silent) tips and tricks video came off the back of a recent webinar I delivered where an ex-IBM colleague commented about his favourite Rhapsody shortcut and I thought, why don't I use that? Anyway, here's a small selection to refresh our minds ;-)
Rhapsody includes various keyboard shortcuts (also known as accelerators). An accelerator key is a key (or combination of keys) designed to achieve a specific action.
Some of these are common to Windows applications but others may be specific to Rhapsody features such as diagram editing or controlling the workspace.
E.g., Edit > Select > Select Same Type is one of the tucked away menus I use a lot in Rhapsody! Ctrl+Alt+T is the shortcut for Select Same Type.
Ctrl+Alt+T selects all the elements of the same type, useful for using the Layout toolbar to align or space elements
Multi-select also enables you to set common display options, e.g., to show Description compartment in all the selected graph elements.
Ctrl+L is Navigate > Locate in browser.
Modifying with Shift, i.e. Ctrl+Shift+L, will Navigate > Locate on diagram.
If a diagram is selected then Ctrl+P will launch the print dialog.
Less familiar, did you know that Ctrl+R, will display the References for a selected element?
Rhapsody's Enhanced Tooltip is sometimes a useful feature (and sometimes not)...
There's some shortcut clues down here...
E.g., Ctrl+F2 will persisted the Enhanced Tooltip window.
Ctrl+Alt+F2 will toggle enhanced tooltip on and off.
Shift+Alt+F2 and it's off.
Shift+Alt+F2 again and it's on.
Another useful toggle is Ctrl+0 (zero). Ctrl+0 will hide/show the browser.
If we want to reset our workspace window layout then Ctrl+W will Window > Arrange Options.
Modifiers change the behavior of a command.
E.g. Delete will normally Remove from View, i.e. element is still in model!
Adding the Ctrl modifier, i.e., Ctrl+Delete, will Delete from model.
Modifiers also work with other commands
E.g. Ctrl+F is a conventional Windows shortcut for launching a Search dialog.
Shift+Ctrl+F will modify to Search in Diagram...
There are more, of course. However, do you know the shortcut for zoom to fit?
F6 will Zoom to fit for a diagram.
... and the Shift modifier, i.e., Shift+F6, does Undo Zoom to go back.