Friday, 16 April 2021

IBM Engineering Rhapsody Tip #97 - I can't get no Satisfactions (creating a browser view)

I'm keeping towards the magic 100! This IBM Rational/Engineering Rhapsody tips and tricks video shows the simple steps how to create a new browser filter that shows whether requirements have certain coverage in a model. I show that it works with both requirements in the model and remote requirements in IBM Engineering DOORS Next Jazz application. It's silent though hence if you fancy strutting your stuff then feel free.


The following is the transcript for those that need it:

The theme for this Rhapsody tips and tricks video is the Stones' "I can't get no Satisfaction". It's silent though, hence you have to sing it yourself. 

Rhapsody has a bunch of standard browser filters, e.g., filter browser to Requirements View. But look, there are some non-standard views listed here! E.g., which requirements are covered, and which requirements can't get no satisfaction?

If we add a Satisfaction to the model and save, then the requirements are removed to show they're now covered. Adding such views can speed up requirement tracing.

These custom views were added by one of my profiles. 

Let's have a go at creating the "no satisfaction" one from scratch ;-) First off, I'll do it in a profile, a special type of UML package for customizations. 

I'll create a Query element. Queries are like persisted model searches. We can define a search criteria, such as Element type = Requirement. If we double-click a Query then it runs a search in the model.

We can build a compound filter, e.g. Reference. Find elements that have exactly zero incoming relations of type Satisfaction. The compound filter is now looking for requirements that don't have satisfaction relations. Double-click enables us to test it.

What's more, the Model::Query::ShowInBrowserFilterList property is set. This means that our new Query - AintGotNoSatisfaction is listed as a browser.

Worth noting that these queries also work with remote requirements. These requirements are in IBM Engineering DOORS Next. With DOORS Next requirements, adding a standard dependency allows us to create an OSLC Satisfaction and the requirements has been removed from the filtered view of unsatisfied requirements, i.e., I can't get no satisfaction! ;-)

Interested in MBSE/UML or Rhapsody training/customizations? Email me.

Thursday, 1 April 2021

IBM Engineering Rhapsody Tip #96 - The Good, The Bad and The Ugly of Label Mode

This video is a bit of a Rational Rhapsody aficionado's topic. The joy's of Rhapsody's Label Mode. Most effective use of this has been when presenting quite a complicated diagram, like an executable state machine or sequence diagram, to lay audience. I'm sure there are some other great examples of usage out there also ("The Good"). I do highlight some of the dangers, however. When you write things not knowing that label mode is enabled, for example.  The video is silent though, so you'll have to hum Ennio Morricone's fantastic spaghetti western theme song, if you get bored with reading my captions.

Tuesday, 16 March 2021

New IBM Engineering Lifecycle Management (ELM) User Group page

IBM have set a new User Group page for Engineering Lifecycle Management (aka Jazz Continuous Engineering platform). They're saying this will be the central point of all IBM ELM activities, hence you may want to check it out:

https://ibm.biz/elmusergroup

There will be features allowing IBM to communicate to the user groups and register to events.

It is open to the public. IBM encourages partners and clients to join. 

Academia is also welcome.

Tuesday, 9 March 2021

IBM Engineering Rhapsody Tip #95 - Why diagram ownership is important for Internal Block Diagrams

This video covers an area where new users of SysML often struggle, i.e. understanding the differences between Blocks and Parts, and the role played by the diagram frame of an internal block diagram. Fundamentally, in SysML the frame of the ibd is normally a block and the ibd represents an assembly of parts owned by that block. Within my old friend Rhapsody, unlike Cameo, there's not a context selection method on a diagram that defines the context of its frame. The context of the diagram is determined rather by the ownership of the diagram. This means that diagram ownership is critical. This is why I normally recommend that new users are careful to create internal block diagrams as children of blocks rather than at package level. Related to this is that if you drag an element on to an internal block diagram and it is out of context, then it will be displayed with a dashed line, something new users often struggle to understand. This is because it's not owned by the element that the frame represents. This is video #95 of my Rhapsody tips and tricks video channel that I started 6 years ago.


Here's the transcript:

Hi, in this short video I'm going to show why it's important to have Internal Block Diagrams owned by Blocks rather than being children of packages.

So, I'll start by creating a quick SysML project and I'll create a classic Block Definition Diagram with a structure. I'll create a System A which has a Subsystem B and Subsystem A. The way I create a structure is with Directed Compositions. I'll create a part A and a part B. 


By default, Rhapsody will name the part with the word "its" followed by the name of the Block but I can name it what I like. 


So what we have here is essentially an internal structure with parts. The block definition diagram defines the relationship between blocks but blocks are types of things and parts are named usages of those types, usually within the context of another block.

... although Rhapsody does allow you to also have parts which are global, i.e. owned by a package.


If I create an internal block diagram where I want to show these parts, then normally the frame of that diagram would represent the element, i.e. Block, that owns those parts. So, if I create an internal block diagram at package level, then we can see in the frame that this is a package diagram of a package called default.


I can put the parts in it and you can see that the dotted notation will tell me where in its nested structure it is.



Of course, I could put the part into the System A block here and that removes the dotted notation.


But the frame here, doesn't represent system A. It doesn't represent anything that's a classifier. Let me just add a port on the boundary of System A here, and another port with a connector.


Now, if I create an internal block diagram underneath the System A block then the frame tells us that this is an internal block diagram of a block called system A.


That means that the frame represents the block System A. This means that you can show a port of System A on the frame, and the things inside that frame then would normally represent parts that are owned by System A.


So the Block Definition Diagram is a diagram that shows relationships between Blocks and blocks are types of things.

The internal block diagram is a diagram that shows me the relationships between parts which are usages and the frame represents the block that owns these parts.


Let's see what happens if I have a nested hierarchy that goes deeper. Maybe component C is a child part typed by  Subsystem A and component D has a child part typed by subsystem B.


If I put part D here on the internal block diagram, then you can see that it's dashed because part D is not directly owned by subsystem A, rather part D is owned by subsystem B.


If I move it into the correct context then it's boundary is no longer dashed.


So, if I drag something on to an internal block diagram, for example a Block, then it's dashed because it's not owned by the element that the frame of the ibd is representing.

Internal block diagrams are diagrams of the internal structure of a block, so things that are not in that internal structure are going to have dashed lines on them.


There's two fundamental things here really. One is that blocks are types of things and that parts are named usages of blocks, usually within the context of another block. 

Secondly, an internal block diagram is a diagram of those usages and how they're connected within the context of a a block, and that the frame of the ibd normally represents that owning block.


In Rhapsody, there's no context setting on the internal block diagram. The internal block diagram frame is determined by the ownership of the diagram. So the internal block diagram here is owned by system A which means that its frame will represent system A. This is why I always create an internal block diagram underneath a block, rather than at package level (unless you have parts which are global - which I tend to avoid anyway).

I hope that helps. Don't forget that I have a business that can deliver customised training in Rhapsody that suits your needs and your budget, so feel free to email me if you want more information on ways of accelerating your adoption of successful model-based systems engineering with Rhapsody.

Monday, 22 February 2021

IBM Engineering Rhapsody Tip #94 - Downloading and installing Rhapsody 9.0.1 (Intermediate)

In my previous video, I covered adding Cygwin/gcc compiler to an existing Rhapsody installation. This video is actually the precursor to that, and covers installing the latest Rhapsody 9.0.1 (to date) without a compiler. The actual steps you may choose to use for your installation may different. However, I point out a couple of important things. Firstly, how the TELELOGIC_LICENSE_FILE environment variable is used by Rhapsody to find either a license server or a FlexLM license file, and secondly how the rhapsody.ini file is used by Rhapsody to determine default edition. I also create a simple test project that can be used to verify whether your compiler is installed correctly (actually the steps for doing this are in the previous video #93).

SysML v2 2021-01 Incremental Release

For those who may be interested:

Incremental release 2021-01 of SysML v2 is now available at https://github.com/Systems-Modeling/SysML-v2-Release.

This release includes language support for filtering of elements imported into a package (“smart packages”), enhanced support in the Tom Sawyer visualization tool to allow mixed views on a diagram, and a prototype implementation of pagination of return data for one API endpoint.

Complete release notes can be found at the links below.

SysML v2 Pilot Implementation: https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/releases/tag/2021-01

SysML v2 API and Services: https://github.com/Systems-Modeling/SysML-v2-API-Services/releases/tag/2021-01

Updated drafts of the specification documents and training material can be found at https://github.com/Systems-Modeling/SysML-v2-Release/tree/master/doc

Thursday, 11 February 2021

IBM Engineering Rhapsody Tip #93 - Adding Cygwin/gcc compiler to simulate systems (Advanced)

Always interested in new ideas. This ones actually at the suggestion of Bruce Powell Douglass. One of the questions he gets asked a lot...

You may have installed and used Rhapsody for UML/SysML for a while just drawing diagrams, only to discover later on that there are more advanced executable MBSE methods such as Harmony/SE and my ROCKETS-based modification of it (one of my passions). This narrated video covers what you need to do to your installation in order to extend it to simulate systems or compile C++ code down the line. 

At this point you will discover that you need to install a C++ compiler but, as the video highlights, it's possible to install this compiler after Rhapsody, without having to reinstall Rhapsody. In this video, I demonstrate by going through all the steps to install the minimal parts of the open source Cygwin/gcc compiler for system simulation purposes. I also show steps for verifying the gcc compiler is working, recompiling the framework (and what this means), and testing it with a model. Hope it helps.