I am working on a project to see if I can use SysML/UML to define network elements, and then use instances of network elements in a network design.
Creating network elements as blocks with ports with types like "Switch" and "Ethernet" port is relatively straightforward.
I then create instances of those Switch types, expecting to see aninstance of the Switch that has the Ports (defined on the Switch type) to which I can connect Associations representing cables.
What I have discovered, with help from my colleagues at MagicDraw, is that Ports are not instantiated, so they do not appear in the instances, so I can't do what I want.
If that doesn't work in this case, then I expect that others will have similar examples. Lots of things have connections/Ports to which specific kinds of connectors should attach, and to which other types of connectors should not.
If we can't actually create instances of such things it would seem that SysML/UML has a hole in it when it comes to representing such physical things.
You certainly can do what you want in an "Internal Block Diagram".
See <http://www.realtimeatwork.com/?page_id=683> (or slide 10 on the same page) where there is such an example of electronic network.
Indeed it is not an instance of flow port but a flow port again. Still you can represent what you seem to want.
> I am working on a project to see if I can use SysML/UML to define network
> elements, and then use instances of network elements in a network design.
> Creating network elements as blocks with ports with types like "Switch" and
> "Ethernet" port is relatively straightforward.
> I then create instances of those Switch types, expecting to see aninstance
> of the Switch that has the Ports (defined on the Switch type) to which I can
> connect Associations representing cables.
> What I have discovered, with help from my colleagues at MagicDraw, is that
> Ports are not instantiated, so they do not appear in the instances, so I
> can't do what I want.
> If that doesn't work in this case, then I expect that others will have
> similar examples. Lots of things have connections/Ports to which specific
> kinds of connectors should attach, and to which other types of connectors
> should not.
> If we can't actually create instances of such things it would seem that
> SysML/UML has a hole in it when it comes to representing such physical
> things.
Have you seen the SysML FAQ (http://www.sysmlforum.com/FAQ.htm)? As Cris
Kobryn has explained in an earlier email, there is a lack of complete
Instance semantics in SysML. As a matter of fact, if you look in the SysML
specification you will not find (I didn't in any case) information about
instances of blocks. In SysML these instances are called Parts and they are
used in IBD to define the internal composition of a block. This way you can
use the ports to connect the Parts with Connectors and not with
Associations. You can even use FlowPorts and ItemFlow to define what you are
sending between ports.
In my opinion, you must define the switch block and then you have to
specialize this block in 4 ports switch, 8 ports switch, etc., and to
describe for each switch the ports (4 ports, 8 ports, etc.). After this, you
only have to reuse the specialized switches in your architecture and to
connect the desired ports between them.
What you describe is more related to the modeling tool. Normally, because of
the lack of instances, the modeling tool, MagicDraw in your case, should not
let you use instances of a block in a diagram. Other tools do that so you
couldn't mistake with the SysML semantics.
Best regards,
Dragos DOBRE
Doctorant - Nancy Université - Université Henri Poincaré Centre de Recherche en Automatique de Nancy - CRAN Faculté des Sciences, BP 70239
54506 Vandoeuvre-lès-Nancy
Tél: +33 (0) 3.83.68.40.00 P81450
Fax: +33 (0) 3.83.68.44.59
-----Original Message-----
From: sysmlforum@googlegroups.com [mailto:sysmlforum@googlegroups.com] On
Behalf Of nsowatsk
Sent: mercredi 21 octobre 2009 18:44
To: sysmlforum@googlegroups.com
Subject: [SysML Forum] Ports and instances
Hi all
I am working on a project to see if I can use SysML/UML to define network
elements, and then use instances of network elements in a network design.
Creating network elements as blocks with ports with types like "Switch" and
"Ethernet" port is relatively straightforward.
I then create instances of those Switch types, expecting to see aninstance
of the Switch that has the Ports (defined on the Switch type) to which I can
connect Associations representing cables.
What I have discovered, with help from my colleagues at MagicDraw, is that
Ports are not instantiated, so they do not appear in the instances, so I
can't do what I want.
If that doesn't work in this case, then I expect that others will have
similar examples. Lots of things have connections/Ports to which specific
kinds of connectors should attach, and to which other types of connectors
should not.
If we can't actually create instances of such things it would seem that
SysML/UML has a hole in it when it comes to representing such physical
things.
This looks to be a similar question to that just asked by Paul, and I
suspect has a similar answer - these are tool issues (or tool usage
issues?), rather than holes in SysML or UML per se. However, you should be
careful of using the word "Instance" with respect to SysML, as much
discussed!
You can, in SysML, define a blocks with ports as you did.
You can give the ports types as you did.
You can then, in SysML, create another block "System1" and define parts of
it typed by the blocks defining your network elements. These are parts, not
instances!
Similar to my explanation in my earlier post, the ports on the network
element parts will not necessarily (tool dependent) show by default, but any
proper SysML tool will provide a mechanism to show them on request. In
Artisan Studio you would right click a part and select "Populate>Ports" if
you want to show all of them, there are other mechanisms that are more
selective (see my earlier post - the same applies here). I am surprised by
your comment re your colleagues at MagicDraw, I'd double check if I were
you. You can then join the ports using Connectors (not associations - to a first
approximation associations join classifiers, connectors join parts and
ports, links join instances and so can be directly modeled in UML but not
SysML - though their existence outside of the modeling environment is
implied by both connectors and associations)
The following diagram from Artisan Studio shows the effect (I think) you are
after - two parts in my system, both typed by Switch (defined outside of the
System so reusable between and within systems), both with the ports defined
on Switch, being used in different ways (so whereas the ports come from the
Switch definition, the connectors are specific to System1 context). Here is
the diagram but I don't know if this will make it to the group (posts are
usually plain text):
Notes:
1. This shows SysML/Studio capabilities - I know it isn't a real network
2. I usually use nice engineering straight lines but am feeling arty today!
3. Consistency checks will tell you if you connect incompatible ports -
though it is possible to customize Studio so it prevents this in the first
place.
-----Original Message-----
From: sysmlforum@googlegroups.com [mailto:sysmlforum@googlegroups.com] On
Behalf Of nsowatsk
Sent: 21 October 2009 17:44
To: sysmlforum@googlegroups.com
Subject: [SysML Forum] Ports and instances
Hi all
I am working on a project to see if I can use SysML/UML to define network
elements, and then use instances of network elements in a network design.
Creating network elements as blocks with ports with types like "Switch" and
"Ethernet" port is relatively straightforward.
I then create instances of those Switch types, expecting to see aninstance
of the Switch that has the Ports (defined on the Switch type) to which I can
connect Associations representing cables.
What I have discovered, with help from my colleagues at MagicDraw, is that
Ports are not instantiated, so they do not appear in the instances, so I
can't do what I want.
If that doesn't work in this case, then I expect that others will have
similar examples. Lots of things have connections/Ports to which specific
kinds of connectors should attach, and to which other types of connectors
should not.
If we can't actually create instances of such things it would seem that
SysML/UML has a hole in it when it comes to representing such physical
things.
Nathan, it seems to me that we are running into the same problem - in your
case with ports and in mine with composite parts. The question seems to be
if these aspects of a block are treated as part of the block (class)
definition and, therefore, are included when an instance is created. It
seems to me to be a significant flaw if this is not how it works.
Is it only block attributes and operations that are included in
instantiation?
On Wed, Oct 21, 2009 at 12:44 PM, nsowatsk <nsowa...@cisco.com> wrote:
> Hi all
> I am working on a project to see if I can use SysML/UML to define network
> elements, and then use instances of network elements in a network design.
> Creating network elements as blocks with ports with types like "Switch" and
> "Ethernet" port is relatively straightforward.
> I then create instances of those Switch types, expecting to see aninstance
> of the Switch that has the Ports (defined on the Switch type) to which I
> can
> connect Associations representing cables.
> What I have discovered, with help from my colleagues at MagicDraw, is that
> Ports are not instantiated, so they do not appear in the instances, so I
> can't do what I want.
> If that doesn't work in this case, then I expect that others will have
> similar examples. Lots of things have connections/Ports to which specific
> kinds of connectors should attach, and to which other types of connectors
> should not.
> If we can't actually create instances of such things it would seem that
> SysML/UML has a hole in it when it comes to representing such physical
> things.
Many thanks for your help here. Hopefully you will see my other post where I have submitted a worked example of this in MagicDraw, and a write up also.
I would have liked, and still would like, to try this with Artisan also. Unfortunately the free Uno edition is not really supported, so I couldn¹t even get off the ground with Artisan :-/
Regards
Nathan
On 22/10/2009 12:59, "Ralph N Hains" <ralphnoel.ha...@physics.org> wrote:
> This looks to be a similar question to that just asked by Paul, and I suspect > has a similar answer - these are tool issues (or tool usage issues?), rather > than holes in SysML or UML per se. However, you should be careful of using the > word "Instance" with respect to SysML, as much discussed!
> You can, in SysML, define a blocks with ports as you did.
> You can give the ports types as you did.
> You can then, in SysML, create another block "System1" and define parts of it > typed by the blocks defining your network elements. These are parts, not > instances!
> Similar to my explanation in my earlier post, the ports on the network element > parts will not necessarily (tool dependent) show by default, but any proper > SysML tool will provide a mechanism to show them on request. In Artisan Studio > you would right click a part and select "Populate>Ports" if you want to show > all of them, there are other mechanisms that are more selective (see my > earlier post - the same applies here). I am surprised by your comment re your > colleagues at MagicDraw, I'd double check if I were you.
> You can then join the ports using Connectors (not associations - to a first > approximation associations join classifiers, connectors join parts and ports, > links join instances and so can be directly modeled in UML but not SysML - > though their existence outside of the modeling environment is implied by both > connectors and associations)
> The following diagram from Artisan Studio shows the effect (I think) you are > after - two parts in my system, both typed by Switch (defined outside of the > System so reusable between and within systems), both with the ports defined on > Switch, being used in different ways (so whereas the ports come from the > Switch definition, the connectors are specific to System1 context). Here is > the diagram but I don¹t know if this will make it to the group (posts are > usually plain text):
> Notes:
> 1. This shows SysML/Studio capabilities - I know it isn¹t a real network
> 2. I usually use nice engineering straight lines but am feeling arty today!
> 3. Consistency checks will tell you if you connect incompatible ports - though > it is possible to customize Studio so it prevents this in the first place.
> Cheers,
> Ralph
> -----Original Message----- > From: sysmlforum@googlegroups.com [mailto:sysmlforum@googlegroups.com] On > Behalf Of nsowatsk > Sent: 21 October 2009 17:44 > To: sysmlforum@googlegroups.com > Subject: [SysML Forum] Ports and instances
> Hi all
> I am working on a project to see if I can use SysML/UML to define network
> elements, and then use instances of network elements in a network design.
> Creating network elements as blocks with ports with types like "Switch" and
> "Ethernet" port is relatively straightforward.
> I then create instances of those Switch types, expecting to see aninstance
> of the Switch that has the Ports (defined on the Switch type) to which I can
> connect Associations representing cables.
> What I have discovered, with help from my colleagues at MagicDraw, is that
> Ports are not instantiated, so they do not appear in the instances, so I
> can't do what I want.
> If that doesn't work in this case, then I expect that others will have
> similar examples. Lots of things have connections/Ports to which specific
> kinds of connectors should attach, and to which other types of connectors
> should not.
> If we can't actually create instances of such things it would seem that
> SysML/UML has a hole in it when it comes to representing such physical
From: sysmlforum@googlegroups.com [mailto:sysmlforum@googlegroups.com] On
Behalf Of nsowatsk
Sent: 06 November 2009 14:59
To: sysmlforum@googlegroups.com; ralphnoel.ha...@physics.org
Subject: [SysML Forum] Re: Ports and instances
Ralph
Many thanks for your help here. Hopefully you will see my other post where I
have submitted a worked example of this in MagicDraw, and a write up also.
I would have liked, and still would like, to try this with Artisan also.
Unfortunately the free Uno edition is not really supported, so I couldn't
even get off the ground with Artisan :-/
Regards
Nathan
On 22/10/2009 12:59, "Ralph N Hains" <ralphnoel.ha...@physics.org> wrote:
Hi Nathan,
This looks to be a similar question to that just asked by Paul, and I
suspect has a similar answer - these are tool issues (or tool usage
issues?), rather than holes in SysML or UML per se. However, you should be
careful of using the word "Instance" with respect to SysML, as much
discussed!
You can, in SysML, define a blocks with ports as you did.
You can give the ports types as you did.
You can then, in SysML, create another block "System1" and define parts of
it typed by the blocks defining your network elements. These are parts, not
instances!
Similar to my explanation in my earlier post, the ports on the network
element parts will not necessarily (tool dependent) show by default, but any
proper SysML tool will provide a mechanism to show them on request. In
Artisan Studio you would right click a part and select "Populate>Ports" if
you want to show all of them, there are other mechanisms that are more
selective (see my earlier post - the same applies here). I am surprised by
your comment re your colleagues at MagicDraw, I'd double check if I were
you.
You can then join the ports using Connectors (not associations - to a first
approximation associations join classifiers, connectors join parts and
ports, links join instances and so can be directly modeled in UML but not
SysML - though their existence outside of the modeling environment is
implied by both connectors and associations)
The following diagram from Artisan Studio shows the effect (I think) you are
after - two parts in my system, both typed by Switch (defined outside of the
System so reusable between and within systems), both with the ports defined
on Switch, being used in different ways (so whereas the ports come from the
Switch definition, the connectors are specific to System1 context). Here is
the diagram but I don't know if this will make it to the group (posts are
usually plain text):
Notes:
1. This shows SysML/Studio capabilities - I know it isn't a real network
2. I usually use nice engineering straight lines but am feeling arty today!
3. Consistency checks will tell you if you connect incompatible ports -
though it is possible to customize Studio so it prevents this in the first
place.
|
