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.
