Towards understanding the UML analogs of SysML BDD and IBD diagram types

[avi-mak]

Hi,

I have been learning and using SysML for a while (BDDs, IBDs, and Activity diagrams). However, due to certain company constraints I might now have to move (“down”) to UML (i.e., use diagram types offered by ‘non-SysML, generic UML’).

In general, I need to know what are the UML analogs of SysML BDD and IBD diagram types.

However, it seems to be more correct to first ask about the UML Component diagram type: does the Component diagram type specify types (like classes) or does it specify instances? Please forgive me for asking wat appears to be a UML question on a SysML forum.  

The OMG UML Spec v1.6, writes a lot of definition text to explain components. Some selected quotes: 

Section 11.6.1 writes: “A Component can always be considered an autonomous unit within a system or subsystem.” and “The Components package supports the specification of … physical Components.“
For me, the use of the terms autonomous unit and physical/hardware units implies that the components are instances. 

However, section 11.6.3 writes: “A Component is a self-contained unit that encapsulates the state and behavior of a number of Classifiers.” 
For me, the use of the term Classifiers implies that a Component is a type.

So to repeat the question: is a Component diagram a type (like a class) or an instance?

To try to answer my own question: from the fact there exists the isDirectlyInstantiated property, it seems that a Component is both a class and an instance, and by that same name. 

An important point here therefore seems to be: can I create multiple instances of a component?  I get the feeling the answer is no, and in this lies the difference between a component and a class. 

Comments?

Thanks

Avi

[kob...@gmail.com]

Hello Avi,

> In general, I need to know what are the UML analogs of SysML BDD
> and IBD diagram types.

You will find a table that systematically compares and contrasts UML2 vs
SysML diagram types in the following FAQ:

"SysML FAQ: What is the relationship between SysML and UML?"
https://sysmlforum.com/sysml-faq/what-is-relation-between-sysml-and-uml.html

> Please forgive me for asking [what ]appears to be a UML question
> on a SysML forum.

Please don't apologize for your UML vs SysML question, since (as the FAQ
above indicates) numerous persons are confused about the *dialectical*
differences between the two languages. Consequently, I am cross-posting
my response to UMLf...@googlegroups.com.

(Disclosure: I am the Editor of both SysMLforum and UMLforum Google
Groups, and previously led the UML 1.x, UML 2, and SysML Open Source
design teams. I have ~25 years experience applying UML/SysML to
software-intensive Systems-of-Systems. So I know both languages and the
mainstream tools that implement and mis-implement them quite well.)

Back to your specific questions...

> However, it seems to be more correct to first ask about the UML
> Component diagram type: does the Component diagram type specify

> /types/ (like /classes/) or does it specify /instances/?

Short answer: Both!

Longer Answer:
Both the UML 2 Component diagram and UML 2 Composite Structure diagram
allow you to specify *types* and *instances* of Components and
Structured Classes, respectively.

Since SysML is a dialect (Profile) of UML 2, the same is true of a Block
Definition Diagram (BDD): you can specify both a Block *type* and a
Block *instance* on a BDD.

This shouldn't be surprising, since UML2 and SysML are essentially the
same language!

I hope your next questions have something to do with: "How are UML 2
Parts related to UML 2 Components and Instances? and "How are SysML
Parts related to SysML BDD Blocks and Instances?" If you are interested
in either of these questions you may want to check out the following FAQ:

"What is the difference between a Block Definition Diagram (BDD) and an
Internal Block Diagram (IBD)?"
https://sysmlforum.com/sysml-faq/what-is-diff-between-BDD-and-IBD.html

> The OMG UML Spec v1.6, writes a lot of definition text to explain
> components.

Yes, and it does a poor job of explaining them and their relationships
with Ports (Standard, Proxy, Full) and Interfaces ([Standard]
Interfaces, Interface Blocks).

> Section 11.6.1 writes: “A Component can always be considered an
> autonomous unit within a system or subsystem.” and “The Components
> package supports the specification of … physical Components.“

> For me, the use of the terms /autonomous unit/ and /physical/hardware
> units/ implies that the components are /instances/.

Although I agree with you that this explanation is poor, your inference
that "autonomous unit" and "physical/hardware unit" imply that
components = instances is a non sequitur.

Please keep in mind that you are reading a language specification, not
an Object Primer or User Manual! You are expected to fully understand
the following Object paradigm basics (using Miller Analogies notation:
https://en.wikipedia.org/wiki/Miller_Analogies_Test):

Classifier/Type : Instance :: Definition : Usage

- OR (more fundamentally) -

Classifier/Type : Instance :: Abstraction : Reification

(BTW, a UML2/SysML "Part" fits in between "Classifier/Type" and
"Instance" (indeed, it is sometimes referred to as a "Propotypical
Instance"), but I will defer details to a future FAQ.)

For example, in a System Design for a "Ethereum CryptoCurrency Mining
Rig" System you might *define* the following "physical/hardware
components", which are also "autonomous units", Blocks on a BDD:

"MiningRigFrame <Block>" w/ mult = 1; "MotherBoard <Block>" w/ mult = 1;
"SSD <Block>" with mult = 1; ... ; and "GPU Card" <Block> w/ mult = 9.
Note that the various multiplicities define the numerical constraints
for the number of *instances* that can be specified on the same, or some
other, BDD. So in this "Ethereum CryptoCurrency Mining Rig" System
example, you would expect to find nine (9) instances of "GPU Card"
<Block> "physical/hardware components", each of whose ValueProperty
"Slot Values" may vary at any point of time.

> However, section 11.6.3 writes: “A Component is a self-contained unit
> that encapsulates the state and behavior of a number

> of /Classifiers/.”

I agree that this is poorly written and misleading ...

> For me, the use of the term /Classifiers/ implies that a Component
> is a /type/.

... but you are incorrect about your inference for the reasons explained
above.

> An important point here therefore seems to be: can I create /multiple
> instances /of a component? ...

Yes, of course.

You *need* to be able to define *both* Components and multiple Component
Instances to DYNAMICALLY SIMULATE any non-trivial UML2/SysML model. I
strongly recommend that you start Dynamically Simulating UML2/SysML
models as soon as practical, so that you sort out the basic similarities
and differences between Components and Component Instances. I know of no
more efficient or faster way to learn this. (Please keep in mind that
the first Object language was called Simula [1967] for good reason!)

Please confirm receipt and let me know your thoughts.

/Cris

_____________________________________________________________________

PivotPoint Technology - Model-Based Digital Engineering(sm) Solutions
_____________________________________________________________________

Cris Kobryn
PivotPoint Technology Corp.
Tel: +1.760.728.9747 (O) | +1.760.672.0862 (M)
Net: Cris....@pivotpt.com
Web: www.pivotpt.com
_____________________________________________________________________

CONFIDENTIALITY NOTICE
This e-mail is confidential and may also be legally privileged.
If you have received it in error, please notify us immediately by
reply e-mail and then delete this message from your system. Do not
copy it, use it, or disclose its contents to any other person;
to do so could be a breach of confidence. Please contact PivotPoint
Technology Corp. at in...@pivotpt.com if you need assistance.

=====================================================================

On 11/8/2020 3:37 PM, avi-mak wrote:
> Hi,
>
>
> I have been learning and using SysML for a while (BDDs, IBDs, and
> Activity diagrams). However, due to certain company constraints I might
> now have to move (“down”) to UML (i.e., use diagram types offered by
> ‘non-SysML, generic UML’).
>
>
> In general, I need to know what are the UML analogs of SysML BDD and IBD
> diagram types.
>
>
> However, it seems to be more correct to first ask about the UML
> Component diagram type: does the Component diagram type specify

> /types/ (like /classes/) or does it specify /instances/? Please forgive

> me for asking wat appears to be a UML question on a SysML forum.
>
>
> The OMG UML Spec v1.6, writes a lot of definition text to explain
> components. Some selected quotes:
>
> Section 11.6.1 writes: “A Component can always be considered an
> autonomous unit within a system or subsystem.” and “The Components
> package supports the specification of … physical Components.“

> For me, the use of the terms /autonomous unit/ and /physical/hardware
> units/ implies that the components are /instances/.

>
> However, section 11.6.3 writes: “A Component is a self-contained unit

> that encapsulates the state and behavior of a number of /Classifiers/.”
> For me, the use of the term /Classifiers/ implies that a Component is a
> /type/.
>
>
> So to repeat the question: is a Component diagram a /type /(like a
> /class/) or an /instance/?**

>
>
> To try to answer my own question: from the fact there exists the
> isDirectlyInstantiated property, it seems that a Component is both a

> class and an instance, and /by that same name/.
>
>
> An important point here therefore seems to be: can I create /multiple
> instances /of a component?  I get the feeling the answer is no, and in

> this lies the difference between a component and a class.
>
>
> Comments?
>
>
> Thanks
>
> Avi
>
>

> --
> --
> You received this message because you are subscribed to the Google
> Groups "SysML Forum" group.
> Public website: http://www.SysMLforum.com <http://www.SysMLforum.com>
> To post to this group, send email to sysml...@googlegroups.com
> To unsubscribe from this group, send email to
> sysmlforum+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
> <http://groups.google.com/group/sysmlforum?hl=en_US?hl=en>
> ---
> You received this message because you are subscribed to the Google
> Groups "SysML Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sysmlforum+...@googlegroups.com
> <mailto:sysmlforum+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sysmlforum/fbd2f7b5-a2e7-4770-8a7d-d9f32cecd010o%40googlegroups.com
> <https://groups.google.com/d/msgid/sysmlforum/fbd2f7b5-a2e7-4770-8a7d-d9f32cecd010o%40googlegroups.com?utm_medium=email&utm_source=footer>.

[avi-mak]

Hi Cris,

Thank you so much for your quick response.  

>  > does the Component diagram type specify /types/ (like /classes/) or does it specify /instances/? 

> Short answer: Both!

Great! So there is some logic there.

 

> Since SysML is a dialect (Profile) of UML 2, the same is true of a Block Definition Diagram (BDD): you can specify both a Block *type* and a  Block *instance* on a BDD.

When I first saw such an example where a BDD specs an instance, it surprised me. In books and articles, the general approach seems to be that BDD are the definitions – types (as implied by the name – def), and IBDs define the instance of one block (and often it is the only instance of the block that the system “uses”).

 

> Longer Answer:

> I hope your next questions have something to do with: "How are UML 2
Parts related to UML 2 Components and Instances? and

 

Almost. I wanted to see a full SyML-> UML mapping. But it is lacking. (Hence my first question is what is a Component: a class or instance.)  I saw https://sysmlforum.com/sysml-faq/what-is-relation-between-sysml-and-uml.html  but it says SysML is N/A to UML:

Indeed…?

Question summary:

       1.   My next question is indeed ... "How are UML 2 Parts related to UML 2 Components and Instances?”  

 2.  Classes and Instances:  (a) Are UML Component definition (class?) trees defined like SysML Block trees? And with the black diamonds for whole composites etc?  I have not seen that yet – but then again, I am a UML beginner. 

 (b) And if so, is a Component instantiated by representing it as a Composite Structure diagram (like an IBD)?

3. Is there a good article on UML Components: covering Component classes and Component instances?

   4.4. The MBSE  platform I use is Sparx EA. My next challenge obviously would be “so how do you do it in EA…?” But that is for a different forum…

Thanks

Avi

[avi-mak]

And by now, maybe the name of this post should be changed to 'On UML Component diagrams' and moved to the UML forum.   

  - Avi

On Monday, November 9, 2020 at 4:34:07 AM UTC+2, avi-mak wrote:

[James Towers]

Hi Avi,

So my first question who’d be why are you consulting UML v1.6, the current version is v2.5.1 (and SysML is built on v2.x), is this a tool limitation?

If you look at section 11.6.2, Figure 11.38 you will see that Component is a kind of Class , and it encapsulates a number of ComponentRealisations (kinds of Realizations) which are typed by a Classifier.

This is analogous to a SysML Block which encapsualtes a number of Parts (which themselves are typed by Blocks)

Neither of these things are instances, although you can have instances of a Component, and in fact you can have multiple-instances of a Component.

The name syntax follows the common format e.g. name : Component (underlined to distinguish it from a ComponentRealisation)

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com

To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en

---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/fbd2f7b5-a2e7-4770-8a7d-d9f32cecd010o%40googlegroups.com.

[Stephan Roth]

Hi Avi,

When I first saw such an example where a BDD specs an instance, it surprised me. In books and articles, 

the general approach seems to be that BDD are the definitions – types (as implied by the name – def), 

and IBDs define the instance of one block (and often it is the only instance of the block that the system “uses”). 

Also on IBDs you do not see any instances! An IBD is a diagram on the usage level, i.e. you can see how the types defined in the BDD are used, i.e. how they are interconnected, but nevertheless there are no instances. On an IBD, we speak of parts (if, for example, the block was subordinated to the whole on the BDD with a composition relationship) or references (if the block was assigned to the whole via an aggregation or association relationship).

Instance specifications (instances) play only a subordinated role in SysML and are, apart from some very rare and exceptional cases, usually never depicted. This is the reason why the Object Diagram of the UML is missing in the 9 diagram types of the SysML At the same time it is of course not generally forbidden (at least not according to the specification) to depict instance specifications if you want to, e.g. also on a BDD.

Best regards,

Stephan

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/39a1f896-a11a-4b96-8c5a-9583b48423f6o%40googlegroups.com.

[avi-mak]

Thank you, James. 

Avi

sysml...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sysml...@googlegroups.com.

[avi-mak]

Hi all, 

Since I am trying to find in SysML an analog to UML wrt the Component element (and more), I should have asked the question much more bluntly. Here goes: 

I have got the impression from a few resources I have looked at (but not from all of them) that maybe one could define one aspect  of the UML:SysML mapping as:

     "A UML Composite Structure Diagram is to a UML Component, as a SysML IBD is to a SysML BDD."

I will take the audacity copying here a Sparx EA definition (where EA is the platform I am using) of the SysML IBD concept I am thinking of when suggesting the above UML:SysML mapping, although I am not sure how much you will all agree with it: 

"The IBD is an instance of the Block element, and the Block is the classifier for the IBD."  (link: https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_domains/internal_block_diagram.html )

Please comment on the above mapping suggestion. If it is not true I would be happy to lay the idea to rest forever. 

Thanks

Avi

On Tuesday, November 10, 2020 at 9:57:36 AM UTC+2, James Towers wrote:

sysml...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sysml...@googlegroups.com.

[avi-mak]

Hi James, 

Thank you for your response. 

>> So my first question who’d be why are you consulting UML v1.6, the current version is v2.5.1 (and SysML is built on v2.x), is this a tool limitation?

I made a typo. I meant UML v2.5.1. I am more used to using SysML, which is at v1.6 and I did a mental copy+paste error.  

>> Component is a kind of Class , and it encapsulates a number of ComponentRealisations (kinds of Realizations) which are typed by a Classifier.  

>> Neither of these things are instances, although you can have instances of a Component, and in fact you can have multiple-instances of a Component.

Thank you for clarifying that.

And which UML diagram type is typically used to describe an instance of a Component ? (Is there an analog to SysML, where the BDD typically contains block defs, and the IBD typically describes an instance of a block from the BDD.)

Thanks

Avi

[dani.mannes]

Hi

In the context of discussion I would like to ask: what is the practical difference between instances (objects) and parts?

Cheers

Sent from my 📱

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to

sysmlforum+...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/1794bda7-e1ce-436d-8b80-9cb3bdcacdbcn%40googlegroups.com.

[James Towers]

Hi Avi,

UML has an Object Diagram which is specifically for instances, although I believe they can also be used on Class and Composite Structure diagrams, and presumably Component Diagrams 

SysML has no specific diagram, although instances may appear on BDDs and IBDs (and possibly others)

Regards

James

--
--
You received this message because you are subscribed to the Google
Groups "SysML Forum" group.
Public website: http://www.SysMLforum.com
To post to this group, send email to sysml...@googlegroups.com
To unsubscribe from this group, send email to
sysmlforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sysmlforum?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "SysML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sysmlforum+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/1794bda7-e1ce-436d-8b80-9cb3bdcacdbcn%40googlegroups.com.

[James Towers]

When you create an instance from a definition (classifier) the properties becomes slots which are “filled” with either their initial value, in the case of value properties, or instances of other Blocks, in the case of part properties. Similar transformations happen for other property kinds.

An instance can be simulated.

A Part is a definition in the context of another definition and called a usage. 

If Block A has a collection of 1..5 Block B’s (as Parts) then there are 1..5 possible configurations (which could be expressed on an IBD via multiplicity or on 5 different IBD’s) 

An instance is a single specific configuration with a current state and contents in it’s slots. 

Sent from my iPhone

On 12 Nov 2020, at 05:20, dani.mannes <dani....@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/5fab7f8f.1c69fb81.fa94e.197b%40mx.google.com.

[Stephan Roth]

Hi Dani,

instances – or more precisely: instance specifications – of a UML Class or a SysML Block are depicted with a rectangle notation and look somewhat similiar to a Class or Block, with the difference that the name of the instance and its type are underlined, like this: nameOfInstance : Type. Both, the name of the instance specification as well as its type, are optional, so a rectangle named with : is valid (an anonymous object of an unknown type).

Links, which are the instance specifications of the UML/SysML association relationship, are also displayed as a simple line, but do not have multiplicities, since they always connect a tuple of two instance specifications of classes or blocks.

A part in an IBD (SysML) is also depicted with a rectangle notation, but its name is not underlined, because they are not instances. The string in the front of the colon is the so-called role name: role : Type.

Best regards,

Stephan

[dani.mannes]

Hi James.

So if I would like to model that a car has 4 wheels how would I model that?

I would use a bed and draw a composition relation where the car is the whole and wheel is the part and specify a multiplicity of 4. I would them add an ibd to the car showing 4 what now? Parts or instances?

Would that be the same?

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/B908F18B-2EA1-4564-AE8F-73E1E7CA9F87%40gmail.com.

[James Towers]

Actually , you’ve highlighted a quirk in the language.

If you defined a Car with a single composition of Wheel with a multiplicity of 4, the IBD would have a single part (of type Wheel) representing a collection of Wheels, with a multiplicity of 4 (not 4 individual wheels) 

What you probably want is four compositions each to Wheel, the IBD would then have 4 parts on. They are still parts mind, not instances.

Any value properties however don’t have data in them, so if your Wheel (or rather Tyre which could be a part of a wheel) can have different pressures, there’s no way to record the actual pressure (for a particular scenario).

If you transform this car into an instance (and by implication the parts into instances) then you can populate the slots with actual values. 

N.B. There’s a bit of a fudge here where you can set an initial value for the value property (x : Integer = 7), but that doesn’t tell you what the current value is, just what it was when the object was created (You can also make it read-only but that just makes it a constant!) 

Sent from my iPhone

On 12 Nov 2020, at 15:06, dani.mannes <dani....@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/sysmlforum/5facfe9e.1c69fb81.b4b80.8430%40mx.google.com.

[Stephan Roth]

Hi Dani,

I've attached an image that shows the interplay between bdd and ibd. The elements that are depicted in an ibd are Parts, not Instances! I've highlighted a few things in color. Basically the Parts depicted in an ibd are more or less just a different representation of the navigable ends of the composition relationships in the bdd. The diagram frame of the ibd represents the context element whose parts are shown, in this case the whole system "Car".

The bdd is a diagram on the definition level, i.e. it shows the definition of, for example, blocks and how they are related.

The ibd is a diagram on the usage level, i.e. it shows how all the parts are used and interconnected to realize the system's functionality.

Hope that helps!

Best regards,

Stephan

[avi-mak]

Hi Stephan,

Thank you for your response.   

 

>> Also on IBDs you do not see any instances! An IBD is a diagram on the usage level, i.e. you can see how the types defined in the BDD are used, i.e. how they are interconnected, but nevertheless there are no instances.   

 

It seems I only partially understood the material in SysML Distilled (Delligatti) Sect 3.4 Blocks. As follows: 

        "Note the distinction between definition and instantiation (which SysML refers to as “usage”)."

 

From the above intro I initially made the assumption that SysML understands (somehow...) that "instantiation" is the same as OMG “usage”.   

And further on: 

        "You can easily tell the difference between elements of definition and elements of usage 
         in a system model. Elements of definition have a name only (e.g., DesktopWorkstation); elements of 
        usage have a name and a type, separated by a colon (e.g., SDX1205LJD : DesktopWorkstation)."

 

The above <name> : <type> notation is the notation  I used in some programming languages to program an instatiation: 
       <instance> : <type>. 

 

I only now notice a little later the (implied) contradiction where the book writes:

         "Some kinds of model elements (e.g., blocks, ...) represent definitions of types; 
          other kinds of model elements (e.g., part properties, ...) represent instances of those types."

 

 

Trying to find something positive in that misundertanding ... maybe it simplified things for me at the time and and so helped me put more time in other concepts.

 

Anyway, please would you comment on the statement above in  SysML Distilled, "Note the distinction between definition and instantiation (which SysML refers to as “usage”)."

 

Thanks

Avraham

 

   

 

     

On Wednesday, November 11, 2020 at 5:47:24 AM UTC+2 stephan....@googlemail.com wrote:

Hi Avi,

 

 

Also on IBDs you do not see any instances! An IBD is a diagram on the usage level, i.e. you can see how the types defined in the BDD are used, i.e. how they are interconnected, but nevertheless there are no instances. On an IBD, we speak of parts (if, for example, the block was subordinated to the whole on the BDD with a composition relationship) or references (if the block was assigned to the whole via an aggregation or association relationship).

[Stephan Roth]

Hello Avi,

> Anyway, please would you comment on the statement above in SysML Distilled,

> "Note the distinction between definition and instantiation (which SysML refers to

> as “usage”)."

In principle there are three levels: The definition level (e.g. the block definition diagram/bdd), the usage level (e.g. the internal block diagram/ibd), and the runtime level. For the latter, UML offers a dedicated diagram type: the object diagram. This kind of diagram does not exist in SysML, since the runtime level that deals with instances plays only a subordinate role. For example: that thousands of more or less similar copies of a car, a.k.a. instances of a car, can be produced...this is something that plays no important role in systems engineering.

I have attached an image to this posting that presents all three levels.

The lower diagram presents the runtime level, and thus instances – or more precisely: so-called instance specifications. Instance specifications represent concrete instances in the modeled system. These can be clearly distinguished from the parts in an ibd because the names are underlined! As you can see, three instances of the modeled system "System" are depicted, which can even be distinguished by a different serial number (a value property of the «block» System; see bdd).

I hope that the picture and my explanations will help you to understand these differences.

Kind regards,

Stephan Roth

Trainer, Consultant, and Coach