Added some further updates to open source Executable MBSE Profile:
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).
Tuesday 8 October 2024
Thursday 22 August 2024
IBM Engineering Rhapsody Tip #110 - The Function Block Method
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.
Sunday 7 July 2024
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.
Thursday 20 June 2024
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.
Friday 26 January 2024
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