v4.3.f.Release of the Executable MBSE Profile (8-OCT-2024)

 Added some further updates to open source Executable MBSE Profile:

Making MBSE quicker with profile support for IBM Rational Rhapsody: v4.3.f.Release (08-OCT-2024) (executablembse.com) 

IBM Engineering Rhapsody Tip #110 - The Function Block Method

This video shows how it's possible to build a very powerful description of a systems structure and behavior using only two SysML diagram types, if you embrace the notation of function blocks and using BDDs and IBDs to do both. To get this to really work, I've had to extend Rhapsody with my open-source profile called ExecutableMBSEProfile. 

The video creates a project from scratch including bdd/ibds for both behaviour and structure and then shows some of the notation that's possible dove-tailing them together. The ability to show functions inside structural elements together with signals is something similar to Capella/Arcadia. Personally I find it interesting that you don't need something complex to describe something complex. Somehow by limiting the notation you can achieve more, especially as it means that you only really need to understand two SysML diagram types to read the diagrams.

This is the transcript in case that helps:

00:00:00

In this video I'm going to show you the executable MBSE profile again, and then I'm going to do something a bit different with this, which is to explain one of the workflows you can do with this profile without using activity diagram, sequence diagrams or state charts and instead doing an entire project with just two diagrams.

The intent of that methodology is to simplify SysML so, if you understand how to do block definition diagrams and internal block diagrams for structure, then you would understand how to do it for behavior and then you can take those two compositional trees and dovetail them together. This is an approach around function block modeling. I'll do the insulin pump system again.

00:00:48

And I'm going to use the executable MBSE profile. This is the four three E version. If you look on my executable mbse website here (www.executablembse.com), then you can see that there is a link to be able to get this profile from GitHub.

00:01:13

Now, conventionally you might start a project with use cases and use cases you might decompose with, say, an activity model. An alternative to that is to start with blocks and do a decomposition using a block model, so the first thing I'm going to say is let's define a system architecture structure.

00:01:32

Using a block definition diagram and this is for an insulin pump system.

00:01:45

And the insulin pump system has an insulin pump, a continuous glucose sensor, and a blood glucose meter.

00:02:09

This is something called a block definition diagram in SysML, and it's derived from the class diagram in UML and allows me to do directed decomposition to be able to create part property relationships between elements.

00:02:31

The insulin pump system now has three part properties typed by these subsystems.

00:02:40

Well, if I did the same within the behaviour domain then I could do it with something very similar and this profile adds the concept of a feature which might be to deliver basal insulin.

00:03:02

This, rather than being a structural block, is a functional block. I'm able to say well to deliver basal insulin, I need to measure glucose level, calculate basal adjustment and deliver insulin.

00:03:29

Obviously, there might be more detail than the real world, but this is just an example.

00:03:40

I use decomposition to show that there's a functional decomposition and the only real difference here between the feature block and function block is I'm saying the feature block is at system boundary level and I do have some relationships that I can do between the system block and the feature block to say that a feature is a system, for example, using generalization, that I don't allow with these function blocks.

00:04:06

But I do allow function blocks to be decomposed to any arbitrary level as do I allow within the structural model subsystems to be decomposed into any any level but not systems. So we're making a language choice within the profile to put meaning around these different types of block, but fundamentally it's a block definition diagram and the notation is the same across both.

00:04:30

So you would say conventional systems projects such as Magic Grid with Cameo or Harmony/SE with Rhapsody would start with use cases and I could could do that but I'll show you an alternative which is that I've added the idea of a context diagram.

00:04:51

Where the context diagram is going to show me the relationships that the system has with external actors.

00:04:59

So it's very similar to a use case diagram. This is an internal block diagram. It's got parts which are typed by actors.

00:05:07

Obviously I haven't really got drivers using an insulin pump system, I've probably got a patient so if I rename that actor as a patient, I could say that there's an interaction between the patient and the system. The patient might request a bonus correction and the system delivers insulin.

00:05:44

This simplified internal block diagram does have very simplified palette and we're using flows between part properties, and the flow is carrying signals or what Rhapsody calls events, because that's one of one of the easiest things to hook other things into. Lots of different diagrams within SysML are able to capture exchange items using Events/Signals. I could show within this insulin pump system using

00:06:16

A feature usage which is typed by that (Feature).

00:06:22

And establish the flows to those features. If you think of this as similar to what a use case would do, the difference is instead of having an ellipse here and having a use case, I've got a block.

00:06:36

To do this (project), I've only actually used two different types of SysML diagram so far. I've used block definition diagrams to do decomposition. I've used a high level internal block diagram. When I say high level, I mean an internal block diagram where the part properties are global. I've got the concept of a block called a feature which decomposable into functions.

00:06:57

And I can then establish relationships between these blocks, and although I could do it with allocation dependencies, what this opens up quite easily is the ability to do allocation through composition. I could say, that my.

00:07:16

Calculation of basal adjustment is done by the insulin pump.

00:07:25

My deliver of insulin is actually also done by the insulin pump.

00:07:34

My measuring glucose levels is done by the continuous glucose sensor.

00:07:42

If I wanted to, I could go into using internal block diagrams.

00:07:48

I've got an internal block diagram here. I can populate the parts.

00:07:53

And I've got a helper here to to be able to do that. Some of these are function usages. Some of them are subsystem usages. If I just say, populate them all.

00:08:05

You'll see how it it dovetails the two together.

00:08:10

Just can pack this a bit than because my screen size is not so good.

00:08:14

The insulin pump then might might have connections with the continuous glucose sensor.

00:08:26

The helper is going to automatically create some interface blocks and conjugate one of the ports. If I do that, I could say that the measurement of the glucose level.

00:08:37

So might might bits or less.

00:08:41

This way, that's the way of doing it.

00:08:45

I could say measuring glucose level produces flows on this connector into these parts, so you see how I'm using part properties with a structured compartment here to be able to see both entities.

00:09:11

So that will be our flow input into that function you can see it's part of the insulin pump.

00:09:22

This gives me some sort of unique but recognizable views, which I can't quite do as clearly/closely using activities as I can with parts and blocks.

00:09:38

And this might be a pre step. I could take that feature.

00:09:44

And then take the part properties and chain them purely in a functional model.

00:09:54

So I measure glucose level.

00:09:58

And that flows.

00:10:02

I haven't typed these by events, but I could that flows to calculating the basal adjustment and then calculating the basal adjustment flows into the delivery of insulin.

00:10:14

And the helper here is creating some flow ports there, and if I wanted to I could put some conditional logic or parallel logic and I'm using business process (BPMN-inspired) notation here because that works quite well in nodes, but this is actually an internal block diagram being used to perform the function that an activity diagram would have.

00:10:39

So it's relatively powerful notation but I've got the whole port/part capability in that this measure glucose level function block here, assuming that essentially the capability and it owns things like a requirement diagram.

00:10:57

And show requirements that the function block owns. Then if I allocate this function block to a subsystem, then I'm essentially allocating the requirements.

00:11:08

And these function blocks then become these reusable elements. So I could create a completely different architecture with different subsystems and allocate the same functions if I wanted to. Or I could start to use some of the things of object orientation such as generalization and composition to assemble reusable functionality as a block, and then use that functionality in another system. It's SysML but all these diagrams are done entirely with the notation of block definition diagrams and internal block diagrams. I haven't used any use cases. I haven't used any activity diagrams, haven't used any sequence diagrams.

00:11:49

But I can achieve quite a lot with a very small syntax.

00:11:53

And once you understand that small syntax, you can express quite interesting relationships and start to assemble systems from reusable components. So it's a more fluid, dynamic way of modeling a system.

00:12:08

Which does rely on some extensions here to be able to specialize the types of blocks, but is something that may be interesting if you're into this idea of functionally decomposing system capabilities rather than trying to say, that we need to express our system in terms of a SysML sequence diagram or state chart.

00:12:26

So I thought I'd show you that it's a slightly different approach to SysML. There's lots of different ways you can use SysML, but I think the idea of only using two diagrams is actually quite clever (i.e. powerful) if you need any more information then let me know.

IBM Engineering Rhapsody Tip #109 - Activity diagram swimlanes and allocation

Gosh, almost on a roll. This Rhapsody Tips and Tricks video which came from some new lab work I've done for my Rhapsody training labs. 

It covers both basic principles of swimlane allocation in IBM Engineering Rhapsody using SysML but it also has a fair share of advanced aspects. For example, I show how to create a context pattern table to show allocation and how Rhapsody creates inferred allocation relations. I then illustrate how it's possible to see allocation in compartments on a block definition diagram, and how Rhapsody also has a slightly hidden capability to show allocation using SysML Callouts, a type of new term comment added by the SysML profile.

Here's the transcript:

00:00:03

OK, my name is Fraser Chadburn. In this demo, I'm going to show you some things about swim lanes in activity diagrams. I'll just navigate to this activity diagram and show you what I mean. I've got double click here working with a Java helper.

00:00:22

This is an activity diagram that just shows control flow with Rhapsody and you can see how this activity diagram is quite useful for capturing the operational scenario perhaps of the system and also how we can link these actions to requirements. 

00:00:41

I'm just going to remove a customization as at the moment the drawing toolbar here has got some additional things like a derivation and that's been done through an applied profile which is a profile that which isn't globally applied but is applied if there's a dependency with applied profile on it.

00:00:59

I'm just going to delete that and then I'll reopen the activity diagram.

00:01:11

And here I've got the default drawing toolbar for an activity diagram. Let me just expand this a bit so we can see it. I've also got action pins and activity parameters.

00:01:22

I've got these swim lanes (in the toolbar). The concept of swim lanes is the ability to associate structure to those swim lanes and then, if I put the action inside of a swim lane, then there's an implicit thing in SysML that this behavioral element is allocated to this structural element. Let me just zoom out and.

00:01:42

I'll draw a swim lane frame of roughly the same size as these actions.

00:01:47

And I'll subdivide it into three different swimlanes (or partitions).

00:01:51

This is what we'd call a black box sequence; we're looking at the operational scenarios from the perspective of the user and we're treating the system as a black box.

00:02:06

Let me just resize these to be able to resize the frame. Here I need to hold down the alt key and that allows me to have some modification of the behavior of the resize.

00:02:22

I'll make them slightly bigger. The first thing with these swim lanes is that we could associate or get a swim lane to represent a structural element. Here's my first action. The operator logs in at the control panel and activates the teleportation system because this is a teleportation system.

00:02:44

I'll turn off the hovering toolbar. I'm going to say well that that's an action performed by the operator.

00:02:53

Within my use case package here I've got an operator actor so to represent that actor I could look at the features and then pick the element.

00:03:05

Or I can drag the element onto the name of the swim lane. If I drag it here I just get an object node. If I drag it directly onto the text, it will do that represents for me. This is the swim lane that represents the operator so I move this action into that swim lane.

00:03:24

I can use the arrow keys here to just shift it across.

00:03:30

What I'm saying is that this action is performed by that actor. Let me delete and redraw the initial flow. I could move it, but generally it's just easier to redraw.

00:03:43

So that's the first step. The operator has logged in at the control panel, so the second step here the Teleportee (actor) tells the Operator where they want to transport to. I'll shift that over with my arrow key on my keyboard andmove that into the second swim lane.

00:04:02

And that is an action performed by the Teleportee. Something that Rhapsody does automatically here, if I have a swimlane, if I look in here, is it it will create an inferred relationship. You can see here that an allocation relationship has been created in the model because of the presence of that action within that swimlane.

00:04:30

What I'll also show you then, is the ability to see this allocation of behavior to structure within a table. I'm going to create something powerful concept here called a context pattern table.

00:04:46

So I create a table layout of my swim lane allocations.

00:04:59

And I'll go to the features for that.

00:05:03

Go to the columns, and go to the advanced options. Not everybody needs to know how to create a context pattern, but they're useful to know what they do and how powerful they can be so that if you think well, actually it would be really useful to see this stuff in a table. You know that it's possible, perhaps as someone in your organization who's able to to understand the series of tokens you need to write to create a contacts pattern. So here's an example I'm going to say go to all the packages and any nested packages. Then if you find a use case.

00:05:34

Then list that, but underneath the use case is an activity diagram.

00:05:39

And I'll give that a token name of act, which is the system mail abbreviation. Effectively, I actually then want to have the actions.

00:05:52

These are states in Rhapsody.

00:05:55

And then I want to see the allocated to elements, so that's go to the allocation relationship and find the end element.

00:06:06

So this is a context pattern. If I collapse the first column I can use the fill defaults to populate columns from that context pattern. The table layout is like a template, so I'll create a view so this is a table view.

00:06:23

Of my swim lane allocations.

00:06:30

If I don't click Refresh, we can see that this action is performed by this actor.

00:06:40

OK, let's look at the next things. Operator sets the destination point, the Teleportee stands on it. I'll just get rid of the Interruptible Region here and what I'll do is move across these actions into the swim lanes.

00:07:00

Once they've moved across, if I go to table view and do a refresh.

00:07:04

Here you can see it's representing that (allocation).

00:07:07

So let's look at the next thing. Actually, this is something done by the system. I've got a third swim lane but I haven't actually allocated any structural element to it, and often when we use swim lanes, we actually have blocks or parts of the system that we're allocated behaviours to. If we go into the white box model. So I'll just create a package.

00:07:34

With a block in it. So I'll create a design synthesis package.

00:07:42

In that I'll create a block definition diagram. This is a BDD of the teleportation system.

00:07:56

And there's a block on it called Teleportation System.

00:08:04

And what I want to show with this is also compartment. So firstly let me take that block and I'll allocate it, or get the swim lane here, to represent it.

00:08:22

And then I'll move this action into that swim lane.

00:08:36s

And I'll check that it then appears OK (in the table). So here we go, we've got an allocation of the system analyzes target location to the teleportation system.

00:08:47

If I go to the display options of this block then what I could do is show that allocation in a compartment.

00:08:57

And an allocated from compartment is available in the pull down list here.

00:09:02

And now I can see the allocation of that behaviour to that structural element on my block definition diagram in a compartment using the specification view.

00:09:15

In terms of the activity if I go to the display options of this action, then there isn't the ability to do compartments, but there is this option to use the SysML callout tool. It's a type of stereotype comment and if I set the display options to the anchored info on here and I make sure that box style isn't shown.

00:09:38

And I anchor it.

00:09:41

Comment to that action.

00:09:44

It's going to pick up the allocated to relationship and show that in system. SysML call out notation.

00:09:52

I'll just show you this final thing here. If I had a a core behaviour here which is dematerialise and rematerialise and I'll just move that in to a swimlane.

00:10:13

Then the question is, is it the call behaviour, or the referenced activity, that I want to allocate to the teleportation system?

00:10:26

Now. If I look at the activity model that's underneath the activity diagram here.

00:10:35

You'll see that there are two different things I've got.

00:10:39

An activity which is dematerialized and rematerialized and then I've got the action that then invokes that activity.

00:10:48

So if I want this activity to be allocated soon, then rather than using inferred, I actually have to use an explicit relationship to allocate. The right click (menu) here would require me to create a dependency and then select that this activity is performed by the teleportation System block.

00:11:11

I'm explicitly creating a dependency here and making that an allocation new term.

00:11:20

And that means that it will then also appear in the allocated from compartment.

00:11:30

If I had the activity on here, we can see that relationship. The display options of the activity on a block definition diagram do allow me to put compartments.

00:11:50

So that’s it. A quick introduction to the idea of using swim lanes to do allocation of behaviors to structures from activity diagrams.

00:12:00

And also some of the support within Rhapsody for inferred allocation that comes from the presence of an action within and from lane.

00:12:10

Or explicit allocation which comes from creating allocation dependencies from the behavioral element to the structural element, in this case, and how we can see these in either compartments on a block definition diagram, or using call out notation on an activity diagram.

00:12:28

Hope that helps. My name is Fraser Chadburn and I do a lot of work with customization, specialization of Rhapsody. If you have any questions then give us a call. Thank you.

IBM Engineering Rhapsody Tip #108 - Creating models quickly, incl. package diagrams automatically

In some ways this is more of the same. However, this video has some of my very latest work for auto-creating package diagrams for model navigation which has gone through a few iterations but is getting quite promising, considering that I used to think that package diagrams weren't that useful in SysML.

The video shows how I create models quickly using a mosaic SysML package approach with an open-source profile I've created called the Executable MBSE Profile. The beginning point for a lot of projects is often a use case and requirements-driven approach but this 11 min video does show that the profile goes beyond that with functional and system architecture packages. This video ends with the auto-creation of package diagram - index for model navigation of the project that was created.

New release of SysMLHelper

The latest SysMLHelper package (4.3.b.Release) is now available on Github. This is an open-source profile and helper collection. The ExecutableMBSE profile part of this as well as providing a Harmony/SE like approach includes function block and function chain modeling enhancements using advanced profile features of Rhapsody. It works with 8.3.1 upwards. 

See my other website which is: http://www.executablembse.com