The goal of the SysMLHelper profile is to make MBSE with Rhapsody simple.
We’re not going to use IBDs and BDDs in the use case model, so I’ve removed and simplified the right-click menus.
If all the packages are built with consistent and appropriate modelling constructs for their role, then a measure of uniformity will permeate through our models; making them easier to build, navigate and review. This leads to more consistent simplified usage.
The use case diagram is also customized and includes a process note giving advice.
As with the Generation 2 profile - the double-click will create a nested activity diagram pre-populated with a template to conveys consistency and gets people working straight away.
Obviously, a system will be able to perform multiple use cases and multiple features. Imagine that the project is for a single system. We might have one user working on new use cases for a new feature in version 1 while another user works on use cases for a different feature for version 2.
We can create any number of use case packages. We’re using the use case package here to group use cases into features or functions that might constitute marketable commodities. We can run this command multiple times in the same project, giving a unique name to get package.
We could choose also whether to create a separate requirements package, or not.
With the Generation 3 of the profile I’ve switch to using properties. The use of Rhapsody properties replaces the previous profiles use of tags under root packages with fixed names. This makes it simpler to configure and maintain, and more consistent with other profiles such as the SE toolkit.
If I tick Enable Gateway types for example, then I can create a stereotyped requirements package when I create the structure.
The goal here is to get the best balance between integration and isolation. One of the benefits of bringing users into the same project is to improve collaboration, especially as Rhapsody Model Manager brings the capability to view Rhapsody projects via the web client.
Requirement stereotypes work really well if we apply a Format to the stereotype. We can do this by right-clicking on the stereotype to access its Format… menu.
We can now see that requirements with the stereotype applied are different from other requirements in the project. This gives us a visual cue that the requirement is related to a different specification or collection than other requirements in same project.
This concludes the demo for now. It’s just a glimpse really of the stuff I’ve been working on to make the process of using and deploying Rhapsody to a large team, that little-bit simpler. I’ve just shown the requirements analysis method helpers, one of three stepping stones to achieving a working white box architecture traced to system requirements.
In today’s world many things are automated. Like Rhapsody’s built in Harmony/SE toolkit, the SysMLHelper brings the idea of automation to SysML modeling tasks. You want your team to be doing fun and creative tasks, in a consistent way, as part of a big team in a shared model without stepping on each other’s toes.
This requires more than installing a tool. You need a combination of a modelling language, tools, people, and process to come together. You essentially need a system. The more automation you can get into that system the faster it run, the better it will scale, and the more consistent and predictable its output will be. Consistency also shows that you are meeting your process which may be important for certification and quality assurance reasons.
Some of the methods are based heavily on IBMs Harmony process but use an open-source Rhapsody profile, meaning we have the option to tailor it to fit your organisation and business goals.
I can offer both consulting and training to take these ideas and make them work for your organisation, meaning less time spent trying to re-invent the wheel, and increasing your chance of achieving success earlier in your adoption lifecycle.
If you want to explore any of these ideas, then feel free to look at my www.mbsetraining.com website, or fire me an email.