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).
This video gives some housekeeping tips for IBM Rational Rhapsody. A model, by definition, differs from drawing pictures because you have the ability to view the same artifacts in many different ways. A common data dictionary means we can keep things consistent as information and ideas are evolved by the team developing it.
But what if someone sends you a model that references a profile or units in a different model that you don't have, or your CM strategy fails to ensure related files are propagated together? This video hopefully helps to explain. It also shows how you can use the File > Add to model dialog in Rhapsody to reference other profiles and Edit > Advanced Search and Replace dialog to check a model for unresolved elements.
p.s. I've expanded my domain names. Can you guess which ones I've gone for? ;=)
The command line part is very CC tool specific but some of the principles such as units and the need to configure properties run across all SCM tools. The MS-SCCI mode setup for Rhapsody is also more generically useful for a range of other CM tools but the actual CM tool and related API does make a difference. Eclipse has its own way of integrating with SCM and is a option some people use for Rhapsody with RTC or SVN. For some tools such as RTC, however, more than one option exists (Eclipse or MSSCI) hence it's important to understand the general tool landscape/product versions and what you want to achieve.
If you google well enough then you can find the Team Collaboration Guide from the 'list of books' days before IBM. The first bit, at least, is worth a read just to get a basic grounding. It's been superseded by IBM's online help but I like the intro.
During a recent discussion at the INCOSE Working Group there was a comparison between Model Driven Architecture (MDA) and Model-based Systems Engineering (MBSE). It promoted an old friend to raise a point that he felt that his organization does apply MDA techniques in MBSE because they transform models from one form to another. They may not call it MDA - and it may be semi-automated or manual - but fundamentally there is an underlying concept of a model-driven transformation that exists. I really liked this idea.
One method is to transform use cases into functional requirements via actions in an activity diagram. With the right tool customization, I can explain and show an engineer who knows nothing about SysML how to do this in 10 minutes. It's a very simple method and very simple to explain. It's amazing what they can come up with. Simple methods can be used to embody and analyze very complex behaviors and “model driven transformation” is a neat way of thinking about it.
Ultimately teams use Model-based Systems Engineering methods to transform ideas into other ideas. The transform may be model-to-model (M2M), model-to-text (M2T), or text-to-model (T2M). The adage that you don’t need something complex to explain something complex applies. Using a set of simple transformations we can assemble an end-to-end process that flows information across teams and achieves astounding results. We can move from static pools of silo'd knowledge:
To business level transformation of ideas (notice the use of the «block» notation at the bottom ;-):
(if we can get all the teams to all agree that is, ha ha).
I created this video to help explain some basic principles about how Rhapsody stores UML/SysML projects on the file-system; the folder structure and the concepts of units are the key ones. For more advanced users I've also highlighted what happens when you rename units plus one of many properties Rhapsody has that can be configured to control how it works. Whether you need to use the property may depend on the setup. At the very least, my hope is that the video gives a few basic concepts worth knowing. Hope it helps ;-)
The next opportunity for public Rhapsody MBSE training is 10th-12th May at HORIBA-MIRA Academy near Nuneaton. This includes an option for a 1 day "hands on" Introduction to MBSE with Rhapsody and SysML. The 1 day focuses on a Wireless Alarm System sample project and provides an introduction to SysML. It's self contained and hence provides a great "hands on" introduction to Rhapsody 8.1.3 for those taking their first steps or wanting to refresh.
Depending on how bold you want to be (and whether you have budget) you can expand into the longer course. See MIRA landing page for course inquiries and booking. I'm happy to give you a call if you need more info.
Rhapsody has thousands of properties to customize the way it works. Diagram display defaults, toolbar menus, the browser, code or simulation generation behavior can all be tailored for your project or company needs. Accessing this power requires understanding of the property hierarchy.
1. When you open Rhapsody, it reads the properties in the read-only factory prp files in the $OMROOT/properties folder.
2. It then opens the site prp files in the same folder. The latter are user editable. Setting a property here will override the value set in the factory prp files. Care, however, is needed when sharing models as different users may have different site.prp files (unless you're pointing to a common OMROOT). As such, site prp customization may not be the best way.
3. Rhapsody then opens the project. A property set at the project level will override properties in the Site prp files, and so on; this is what we mean by the property hierarchy.
4. Next comes the profiles or settings. If a profile is ‘globally applied’ it will override the Project settings. If we don’t tick ‘Globally Applied’ then we can make the profile apply to only part of the project by establishing an «AppliedProfile» dependency.
5. At this stage we could still override the properties at a level lower than the project, e.g., at a package level or a diagram level. If you want to customize the code generation then this can also be done at Component/Configuration level. This help topic is pretty good.
This video illustrates the hierarchy in action:
The benefit of using profiles are that we can standardize the use of the same default properties across multiple projects. You can create your own profiles or settings (a setting is like a profile) be careful though, there’s no guarantee of order precedent here if you have multiple profiles. One guarantee you do have though, is that you need to customize Rhapsody properties if you want to harness the true power of MBSE for your project. In our training we provide a ready to use example of this.
IBM Rational Rhapsody allows us to extend
the UML/SysML with our own terms. It's a bit like playing fancy dress with
UML/SysML. Standard stereotype mechanisms provide us with a fairly transparent
extension mechanism (a James Bond theme party?). If we want to pull out the
stops then we can mark a stereotype as a New Term and give it new browser
icons. This is more akin to dressing up as the Pink Panther or a Giraffe (well something like that ;-). This 2 min video shows an example starting from a blank project:
