<Joanne> Thank you, Mark. Okay, as Mark said
this webinar is about basic structural modeling, and we will be doing an advanced structural
modeling webinar too. So we'll be interested to hear your input at the end of this as to
what you would like to see covered in the advanced version. So what are we going to
talk about today? We'll talk about the different structural diagrams in SysML, the concept
of the block, and then we'll talk about various different things related to blocks, and we'll
talk about parts, and associations, instance specification, we'll go into the block definition
diagram, and properties, connectors, and links. We have some recommended resources. The SysML
video playlist of the previous webinars on SysML, you definitely want to check those
out if this is your first time attending this. The OMG UML specification, as well as the
OMG SysML specification version 1.3. There are a number of books we recommend, the 'Systems Engineering with SysML/UML Modeling Analysis and Design' by Tim Weilkiens, and then the
'Practical Guide to SysML' by Friedenthal, Moore, and Steiner - which is an excellent
reference book. Bruce Powel Douglas, from IBM, has written a number of UML books, we
recommend the 'Real-time UML' book. If you are familiar with UML you have a great start
to learning SysML because SysML is based on UML. It's a special dialect of UML for systems
engineers. And Bruce Powel Douglas is an evangelist here, actually he's an ambassador now, so
he's got a number of books as I mentioned. Now we also mention INCOSE here, they have
a number of good resources as well - The International Council on Systems Engineering. So our focus
today is on the structural diagrams which show the static structure of a system. They
enable the modeling of both the logical and physical structural elements of the system,
the connections among them, and the relationships between them. For example, the logical decomposition
of a system into subsystems. So the block definition diagram is a modification of
a UML class diagram, for those of you that know UML. And the internal block diagram is
a modification of the UML composite structure diagram. And the parametric diagram is fairly
new to SysML, it's unique to SysML. So the first of these, the block definition diagram
is a black box view of the system and it represents structural elements called blocks. The focus
is on defining the system or subsystem. The internal block diagram provides a white box
view of the system, and it shows how the parts of a block are connected. It describes internal
structure, and it shows decomposition of a component into constituent parts. The parametric
diagram is unique to SysML, it represents constraints on property values, and it's used
to support engineering analysis. Parametrics enable integration of engineering analysis
with design models. <Andy> So before we start getting to deep into the myriad structural
aspects of SysML, let's start by exploring the basic architectural unit - the block.
Now what you've got on the slide here is a quote taken directly from the SysML specification.
Now I'm not going to read the whole thing, but you can see that blocks are modular units
that are used throughout the lifecycle. They can be used to model systems, subsystems,
logical or physical elements, software, hardware, even humans. A block is the fundamental unit
of architecture. Next slide, please. A block is described in terms of its feature set and
those features may be broadly categorized into structural features and behavioral features.
On the structural side, blocks can have data items known as value properties or just simply
values. A block can also be architecturally incomposed into its internal structure, and
those structural units are called part properties, or again just simply "parts." Blocks may also
reference other architectural elements that are not necessarily part of the block, and
also have design constraints placed upon them. Blocks may also exhibit behavior. Operations
describe the autonic units of behavior, system functions if you will. And event receptions describe
the external stimuli that the block may respond to. The block's life cycle of behavior may
be described graphically using state machines or activities, and those diagrams physically
reference the set of receptions and operations of the block. Now when a block is shown graphically
on a diagram it can have compartments listing any of those features. So there on the diagram
you see an example. We have a parking allocation subsystem block and it's showing two compartments
- one listing out the system functions or operations of that block and the other one
listing its data items or value properties. Next slide, please. Now, I mentioned that
a block is the fundamental unit of architecture but it's more than that. A block is a specification
for a set of features that are common to the thing that the block is modeling. For example,
this airplane block here is modeling the fact that all airplanes have a weight, and a top
speed, and a registration or tail number. Also all airplanes can take off and they can
land. The blocks also describe classifications. So here it's a generic aircraft, but we might
decide to split that classification into maybe types of aircrafts that can take off vertically
and then those types that can't. Later you'll see different ways of modeling those types of classifications. So a block describes the features of all of its instances. A specific instance, in this
case a specific airplane, would have a specific unique tail number. Later on you'll see how
the model maps out. First let's explore some of those features that we talked about that
a block has. Next slide, please. So the first feature we're going to take a look at here
is the value property. So blocks have data items, that is specific quantifiable pieces
of information - like its weight, its length, its status, and so on. Now each of those value
properties, or again simply values, has a type, and that type is known as the value
type. That type might be an enumeration, so you could for example have the car in red,
black, or yellow. That type might also be a primitive type, like a string or a boolean
or an integer. Or it might be a more complex structure type. For example, we might model
the fact that coordinates can be described using a latitude and longitude. Now in software
engineering primitive types are usually fine, but in systems we need something more. Imagine
you were going to buy a new appliance for your home, a washing machine, and you rang
the store to check if it would fit in the space that you had planned for it. And when
you asked them how wide it was, they said it's "twenty-three." Well, twenty-three what?
Inches? Centimeters? Meters? A simple integer here isn't quite enough information. Next
slide, please. So in SysML, value types can have two extra characteristics. The quantity
kind defines the fundamental type of the value that we measure in weight, length, or time.
The second characteristic, unit, gives us the granularity of the measurement - are we
measuring meters or inches? Units are always associated with a quantity kind. Now as long
as two values have the same fundamental quantity kind then we can compare them. Although we
may need to perform some kind of conversion calculation first. For example, we can compare inches
to millimeters because they share the same quantity kind, they are both fundamental measurements of length. Now SysML actually refers to some basic standard ISO types, but it's really
intended that modelers use these features to build their own domain specific libraries
of value types. Next slide, please. So here are a couple of examples. The block in the
lower left of the slide describes the fact that all squash balls have separate features,
they have a couple of features here. So all squash balls for example have a color. That
color value property has a type - colors. Colors is an enumeration which is shown at
the top left. Therefore, all squash balls are either red, yellow, or green. All squash
balls also have a weight, and this one is of type "g" - that's a value type shown just
above it. That value type has a unit, it's measured in grams, and the gram unit is shown
just above that again. That has a quantity kind again, it's a measurement of mass. Next
slide, please. <Joanne> So, Andy talked about values as a property of blocks. Another property
of blocks is the part property. Here's an example of the structural relationship between
blocks. We see a block decomposed into its internal structure. A part is typed by a block.
The part's left wing and right wing are both typed by the wing block. So they are separate
parts but both are typed by the same block. We also see that the airplane has a part called
body, and that is typed by the fuselage block. The wing block itself also has parts, and
those parts are typed by other blocks. So in SysML we informally refer to parts, but
they are actually part properties - that's the official SysML term. Part association
is also referred to as composition in UML, if you're familiar with UML. On a block definition
diagram, this is how you would show the parts of a block. So here is a block airplane and
it has a left wing and a right wing. The left wing and the right wing are the part names
or role, they are both typed by the wing block. The airplane also has a body part that is
typed by the block fuselage. And all these parts have a multiplicity of one. Now, notice
that there are two ways to show the same thing. We see in the bottom right the airplane block
and the part properties are inside a compartment of the airplane block. In both cases the parts
are owned by the block. These are two graphical representations of the same thing. Multiplicity
is used to denote the number of instances, or usages, of the block. It can be used to
express a range or a list, as shown in the example. We see a motorbike block that has
a part association to a wheel and there is a range of two to three wheels. So all the
motorbikes have two or three wheels. If the multiplicity is not shown it is assumed to
be one. <Andy> So Joanne has just showed you the parts of a block, and when those parts
are shown using that filled in diamond notation it represents an association between the block
and something else, in this case part. Those associations shown graphically like that are
known as graphical paths in SysML. Now there are of course other graphical paths not just
the part association, we've included a couple here on this slide, but let's take a look at them. Next slide, please. Let's start with dependencies. A dependency is represented
by a dashed line with an arrowhead at one end, and it is perhaps the most generic kind
of relationship. Now dependencies are not limited to blocks. In fact a dependency can
go from any kind of model element to any kind of model element. And it simply indicates
that one model element depends upon another in some way. Dependencies are usually stereotyped,
they indicate what the exact nature of that dependence actually is. For example, there
is a predefined stereotype, "satisfy," which indicates that a model element is satisfying
or meeting the need of the requirement that the dependency points to. Next slide, please.
A reference association indicates that a block knows about other blocks. There's no ownership
or containment, it's truly a reference between blocks. In this example, we have a car and
a garage. Now clearly the garage is not a part of the car, so we don't use a part association.
Instead, we have a reference association between them - the car knows about the garage. The
car in fact maintains a list of garages that it considers as approved repairers. The star
multiplicity there indicating there could be any number of garages in that list. Next
slide. <Joanne> Shared association is indicated by a hollow diamond, and it's similar to reference
association. But it's used for containment, it's not the same as a reference or a part
association. There is more containment than reference association, but less containment
than a part association. In the example shown we see shared association between a car and
the roof rack. Roof rack is not part of a car, it is on the car. So shared association
is the appropriate association. If you take the roof rack off the car it still works,
so it's not as separate from the car as a garage. It is not as contained by the car
as a part is. You need the engine for a car to run, but you can run the car without a
roof rack. Generalization is used when you want to redefine the core structure or behavior
of a block. It allows you to add new features or change features based on the original.
As we see on the right the top block is a superclass and the generalized blocks are
subclasses. This is what we mean by classification hierarchy. So cars is a superclass, and electric
car is a more customized or specialized form of the car. Electric car extends the car by
adding a new feature, the charging time, which is a new value property. And the ICE car,
which stands for 'internal combustion engine' car, has a part that the electric car does
not. The ICE car has a fuel tank. Now let's take a look at relations on the internal block
diagram. We see the same thing shown in two different ways - one is on a block definition
diagram, and one is on an internal block diagram. On the left we see the relationships of a
car to blocks on the BDD, and on the right on the IBD, showing the internal structure
of the car we also see the same relationships. It is just a different notation. So we see
that the car has a shared association with the roof rack. Rack is the role name in text
on the left and the type of thing the association points to is a roof rack block. On the right,
the shared association that the car has with the roof rack is shown by the dashed line.
Rack is the roll name, and roof rack is the block that the car has the association to. The
car has a part association relationship to the engine on the left, and on the right on
the IBD, the engine part is shown with a solid line. <Andy> So far we've seen that a block
may be structurally decomposed into its parts, and those parts may be shown on the internal
block diagram for that block. Connectors, are used to connect those parts together allowing
them to communicate. Now while the connector itself doesn't define the type of communication
it may itself by typed by an association to further describe or constrain the nature of
that communication. In this example there's a power supply block with a reference to a
landing gear block. Now imagine that the internal block diagram on the right is the internal
block diagram of an aircraft, and that aircraft has parts PS and LG, then those are typed
by the power supply and landing gear blocks respectively. When we add a connector between
those parts a connector will be typed by the reference association from that block relationship,
and it takes on the same characteristics. In this case it becomes unidirectional. Next
slide, please. So here's an example of the internal block diagram of the airplane that
Joanne showed you right at the start. In the top right hand corner you can see that same
airplane block we've seen previously. We can see that airplane has parts, shown in that
part property compartment. It has a left wing and a right wing and a body. On the internal
block diagram for that airplane, those parts are shown individually using that solid border.
And here we can also indicate that the body of the airplane is connected to the left and
the right wing using connectors. Next slide. <Joanne> Blocks have properties and these
define features of all instances of the block. If you say all airplanes have a number of
seats, you have not defined how many seats all airplanes have. But you can assign default
values to those value properties. This example shows two value properties - seats and rows.
In the example we see that all instances of the Boeing 737 - 300 airplane have 24 rows
and 143 seats. Seats is the value property with a value type of integer and a default
value of 143. An instance specification is modeling a specific instance or configuration
of a block. An instance specification is typed by a block. Each structural feature of the
block becomes a slot in the instance specification that may be overridden or filled in. Here,
the block on the left, shows that all Boeing 737 - 300s have 143 seats and 24 rows. The
instance specification on the right shows a specific configuration of the Boeing 737
- 300, V2. V2 has 137 seats and 23 rows. So V2 is overriding the default values of the
block. <Andy> Okay, here's a slightly larger example of those instance specifications that
Joanne has just been talking about. At the top of the slides we have a Hire Car block
- that's a rental car for you guys in the U.S. Now that car has two structural properties.
A value property indicating its daily cost with a default value of 200 euros. And it
also has a reference to a breakdown cover block. The breakdown cover block is modeling
the level of cover that the hire car would have if it broke down. It has three boolean
value properties again with default values. Now all of those properties become slots in
any instance specification that's based on that block. So on the right underneath the
breakdown cover block there are two instance specifications based on it. That is, there
are two configurations of breakdown cover. The basic cover configuration modifies one
of those values. With this level you don't get a replacement car. The other two value properties just take their default values from the base breakdown cover. The comprehensive
cover configuration also modifies one of the values, adding a hotel to the level of cover.
On the left, underneath the hire car, we can see two instance specifications of that block
- an economy package, and a family package. Both of them modify the "cost per day" value
property, and both of them also modify the policy reference slot. Those references now
refer to the other instance specifications on the right. For example, the economy package
refers to the basic cover instance specification. Next slide, please. <Joanne> Links connect
instance specifications and they are typed by associations. The hire car and breakdown
coverage block have a reference association. We see the links between the different types
of rental cars with the associated insurance coverage. The link that is shown between the
family package and the comprehensive package is typed by the reference association. That
link is shown in two ways. It is shown in green inside the instance specification on
the left, and it is also shown as a pointed arrow going from one instance to another.
Now I'll summarize the three different types of connections we have seen. Blocks have relationships between them - associations. Parts are connected by connectors. And instance specifications
are connected with links. We have seen these on the previous slides, and now we'll see
them again in a complete example. <Andy> Alright let's bring all of that together into one
example. Now the graphic here is kind of busy so let's break it down. There are four diagrams
here on this slide. The two diagrams on the left are both block definition diagrams. The
two diagrams on the right are both internal block diagrams. The two diagrams at the top
deal with blocks and parts. And the two diagrams at the bottom deal with instance specifications.
So let's start at the top left block definition diagram. Here we have a car and that car has
a value property, it's registration, it doesn't have a default value. So there we've modeled
the fact that all cars have a registration but we don't know what that registration is,
or it's not common to all the cars. It also has a number of parts. It has two axles, it
has two wheels on the left of the car, and two wheels on the right. So notice there we've
used the same part association twice, pointing at the same block but they haven't different
role names or different part names. That diagram also shows that each axle knows about two
wheels. And that same relationship shows that each wheel only knows about one axle. Also,
all wheels have a size, and here we've said that all wheels are size 55. Now there we
really should have used engineering units rather than simple integers, but that's really
not the focus for this example. Shifting over to the top right hand side we have much the
same information shown on an internal block diagram, with the addition of connectors connecting
the axles to the wheels. Alright, moving down to the bottom left. There we have an instance
specification modeling a specific car, my car. This one has a specific value for that
registration slot. So this one has a registration of "abcd 123." The other slots are part slots,
and since each one of those has a multiplicity which is greater than one they're shown here
using that curly braces notation. If the multiplicity of those parts was one then the exact instance
specification would be shown instead, just like we saw in the earlier hire car example.
The internal block diagram on the bottom right is the most interesting one. It shows all
the detail that that block definition diagram on the left does not. It's the same instance specification,
my car, but now we can see its internal structure - including instance specifications of each
of the axles and each of the wheels, all of which modify the slots from the blocks on
which they're based. Now note the naming of each of those instance specifications. First
you've got the name of the instance specification, for example "left front," then a slash, then
the slot that that instance specification is filling, example "left 0" or "left 1,"
we had a multiplicity of 2 for that left part. Then there's the colon type notation indicating
the block that that instance specification is based on. Lastly we have links. Links,
as Joanne mentioned, are used to connect instance specifications together. Next slide, please.
<Joanne> Flow properties are properties of a block, and they define what can flow into
or out of that particular block. Those things might be data, physical things, or energy.
Flow properties can by typed by value types but also by other things like blocks. Andy,
why would you want to type a flow property by a block? <Andy> Good question Joanne. Let's
imagine we've got some kind of futuristic robot making factory and we have a block that's
representing the part of the factory that actually assembles the robot together. And
then we have another block which is representing the part of the factory where maybe that robot
gets its artificial skin put over it. And then there's a conveyor belt from the one
block to the other one. Well that first block that's assembling the robot, the thing that's
going to flow out of that block is a robot, and that's clearly not a simple piece of information
or even a simple energy statement like "power" here. It's actually a complex thing and maybe
a system in its own right. So we typically model the robot using a block and that would
have its own internal structure and its own parts. So that's an example of why you might
want to type the flow property by block. <Joanne> Oh, okay, that's a good example. Alright,
a flow property has direction. As shown here we see the power supply block has a flow property
called "power," with the direction of out and a type "W" for watts. So the power supply
is expecting that power will flow out of it. By contrast, the landing gear is expecting
the power will flow into it. So we saw that flow properties define what can flow into
or out of a block. If a part is based on that block - if a part based on the block has a connector
then the energy, material, or data that flows, flows along the connector. This may be shown
by adding an item flow to the connector, and that is designated by the heavy arrow. In
this example, our aircraft has parts based upon the power supply and landing gear blocks,
and those parts are connected with a connector. If the flow property in the power supply part
was assigned a value of say 50 watts, then 50 watts would flow out of the part along
the connector and into the landing gear part at the other end. So flow properties describe
what can flow into or out of a block, and item flows define what actually does flow
given the context. In the example shown we have blocks. The pump block says fluid can
flow out of it. The landing gear says hydraulic fluid flows into it. And the wiper mechanism
says water can flow into it. We also have parts typed by those blocks, and those parts
are connected with connectors. The wiper pump part is typed by the pump block and as such
it is expecting fluid to flow out. It is connected to a part based on the wiper mechanism which
is expecting water to flow in. The item flow on the connector indicates that water actually
flows between these parts. This is of course only possible if the types match. In this
case, water is a type of fluid. In the second case, it's hydraulic fluid that flows between
the hydraulic pump and the landing gear. Again, this is only possible because in our domain
library of value types, hydraulic fluid is a type of fluid. Okay, so we are at the end
of our presentation, and we have covered the basic structural concepts that you need to
know to model system and subsystem structure on block definition diagrams and internal
block diagrams. Now Mark we can take questions now from the audience, if there are any. <Mark>
Whatever questions have rolled in I've already answered for the attendees, but let the attendees
know the panel is open so if you'd like to ask a question now I can immediately read
it to Joanne or Andy. So let's wait a few seconds to see if that happens, and in the
meantime what I'll do is remind everybody that this session is being recorded and I
will be sending everybody an email later today with the presentation and the links
to the recorded session, so please look for that, and if you have any further questions
feel free to reply. It doesn't look like there's any questions rolling in so how
do you feel about us moving into the polling questions? <Joanne> Yeah, that sounds good.
<speaking over on another> <Andy> I'd just like to point out that in our advanced section
which is in our next webinar we're going to be covering things like the new ports that
were introduced in SysML 1.3, we're also going to be going a little bit deeper into something
like generalization with a redefinition capability that's in SysML. But the agenda for that isn't
finalized yet, so if anybody does have any hot topics that they would like us to talk
about during that webinar we are still open to suggestions. <Mark> And again, if you have
any suggestions feel free to send me an email directly, or you can contact Joanne or Andy
directly. I believe, or I'll assume, that on the presentation your contact information
is on the cover page so when the attendees receive the presentation they can reach out
to you based on those email addresses on your cover page. So let's go to the polling
questions. How this is going to work for the audience is that I'm going to go ahead and
select the polling question, it will come up - oh, here's one question that just rolled
in, let's answer it first, and that is, "I'd be interested in the differences between redefined
and subsets in the next seminar." So that's something that we can maybe do for a future
webinar. So, okay, back to the polling questions. So for the attendees here I'm going to launch
a polling question, it will come up on your screen, please go ahead and select an answer,
it will take a few seconds for everybody to submit their questions, and then once they
submit the questions we get close to 100% participation I'll go ahead and either read the answers, or hopefully
I'll be able to launch the results so everybody can see that on their screens. So, I'm going
to select the first question, and I'm going to launch it, and Andy and Joanne do you see
that on your screen there? The question is, "Which structural diagram shows the decomposition
of a component into constituent parts?" So people are now voting - 61% have voted. We're
up to 65% > 68% > 71%. Okay, I'm going to close polling right now and share the results.
Everybody should be able to see that. Andy and Joanne can you see that on your screen
also? <Joanne> No. <Andy> Yes we can. It's kind of, it's not really a trick question,
but although you can show parts on an internal block diagram. It's more usual to use the block
definition diagram to actually show that structural decomposition using the part association.
Kind of a bill of materials, if you will. <Mark> Okay so Joanne I think the reason why you can't see
the results is because you are the current presenter, where Andy isn't he can see it.
So the bottom line Joanne was that 40% answered block definition diagram, 2% answered parametric
diagram, and 58% answered internal block diagram. So okay, let's go to the next polling question.
I'm going to launch it and the question is, "What do flow properties define?" And there
are three answers there, so if you could start voting attendees. We're up to 17% > 20% > 28%
> 44% > 50% > 64% have voted, 70%. Okay 77% have voted, I'm going to go ahead and close
the polling and share the results. Andy, you want to comment about the answer? <Andy> Absolutely, I think that most people got that one right. Flow properties define what can flow into
or out of the block. <Joanne> Which is different from between. <Mark> Okay, off to the next
polling question. And we have a total of four polling questions so there's two more left. I'm
launching it right now, there it is, the question is, "What do links connect?" There's three
possible answers, 53% have voted, 56 now, 61%, 63. <Joanne> Is there any way I can see
it? <Mark> I think the reason why you can't see it Joanne is because I have you selected
as the presenter, that's why. <Joanne> Oh, okay. <Mark> Andy can see it, I know the audience
can see it too. So okay 75% of the people have voted, I'm going to close the polling
and share the answers here. They're pretty much equal across the board, Andy maybe you want to comment about the answers. <Andy> Yeah, that divided the audience, didn't it?
<laughs> So 30% of people said parts, 40% said blocks, and 49% said instance specifications
Joanne. And the correct answer is instance specifications - links are used to connect
instance specifications together. <Mark> Okay great. Alright, last polling question. I'm
launching it, the question is, "What type of association allows you to change the core
structure or behavior of a block?" If you can go ahead and vote attendees I'll go ahead
and share the results as soon as we get up to a certain percentage of who voted. We're
at 6% now, 13%, 17%, 27%, 32%, 44%, 57%, 63%, 68%, 70%, okay we're at 75%, a few more seconds
here wait for some more answers to come in. Okay, I'm going to close the polling and I'm
going to share the results. Andy you want to comment? That's pretty much split evenly
among all the answers there, maybe you can elaborate on that. <Andy> Again, yeah, they
are split evenly. The correct answer of course is generalization. <Joanne> With the superclass and the subclass. <Mark> This kind of reminds me of my high school exams, multiple guess answers. <laughter> <Joanne> We covered a lot of different types of associations.
<Mark> Okay, I'm going to go ahead and hide the results here, I'm going to see if there's
any questions that have rolled in. Okay, alright, let me see here, some of the questions. There's
a request here, it's more of a request than a question, but they're asking if, "Will you
talk about multiple inheritance in the advanced course?" <Andy> We can do, yeah, if that's
something they want to talk about. <Mark> Another one in here is more of a comment,
possible question, "I would be interested in hearing about how SysML diagrams will eventually
be used for software engineers as requirements or design into UML diagrams in UML." <speaking
over on another> <Joanne> I think they mean the hand-off. Don't they? From systems to
software? <Mark> The attendee who asked that question or submitted the comment, if you
want to rephrase it I'll be happy to ask Joanne and Andy. Okay, here's a question here, "What's
the difference between IBD and BDD?" <Andy> Actually fundamentally they're really the
same kind of thing underneath. It's really about the context, by splitting them into
two diagrams we can really guide users in what we want to see on those diagrams and
what to use them for. So a block definition diagram, for example, actually used to be
called an external block diagram - but that was a confusing name and nobody really knew
what they were supposed to use the diagram for. Whereas a block definition diagram really
tells you what the diagram is about. It's about defining the characteristics of a block,
and that might be its value properties, or its relationships to other blocks, things
of that nature. An internal block diagram again the clue is kind of in the name, shows
the internal structure of a block.
