Instances - an example to talk about

8 views
Skip to first unread message

nsowatsk

unread,
Nov 6, 2009, 9:50:58 AM11/6/09
to sysml...@googlegroups.com
Hi all

I am, for my night job, working on a dissertation aimed at creating a
Network Design Modelling Language (NDML). Some of you have seen my earlier
posts about instances, and no doubt enjoyed the related discussions :-)

I felt that it would be useful to anchor such discussions with an "real
world" example, so I have created one using MagicDraw and attached it, and a
write up explaining it. It is based on network designs which enough of us
probably know enough about to find useful.

At this stage the first observation I make is that there appears to be a
conceptual anomaly where the contents of the ibd are contained by the Block
that contains the ibd, with the exception of the Ports.

I have also noted other issues, not really about instances yet, but which
might make for interesting discussions also.

Please feel free to comment in any way you want. I have a thick skin ;-)

Regards

Nathan

--
Nathan Sowatskey (nsow...@cisco.com) - Technical Leader, NMTG XMP -
+34-638-083-675

Basic Profile.docx.zip
nathan_model.zip.zip

Ralph N Hains

unread,
Nov 11, 2009, 12:43:35 PM11/11/09
to sysml...@googlegroups.com
Hi Nathan,

I haven't looked at your model (I don't use MagicDraw) but I can comment on
"appears to be a conceptual anomaly where the contents of the ibd are
contained by the Block that contains the ibd, with the exception of the
Ports".
There is no anomaly here - you have used the word "contains" to cover three
different concepts. Think of it like this:
- a Block is *composed* of its parts
- a Diagram *contains* symbols, but not model items (the symbols typically
represent model items - in this case the parts in question). "Ceci n'est pas
une pipe" to quote Magritte (and my apologies to any Francophones if I got
this wrong)
- a Block scopes its IBD - it isn't composed of it - but this is not the
key relationship - which is that the block internals are documented by its
IBD. Really the IBD could be anywhere (conceptually, I'm not arguing that
the SysML way is wrong, scoping it by the block is very sensible if for no
other reason than if you delete the block you want the diagram that shows
the block internals to go with it, rather than to hang around being
useless),

Cheers,

Ralph

nsowatsk

unread,
Nov 12, 2009, 5:56:03 PM11/12/09
to sysml...@googlegroups.com
Hi Ralph

Many thanks for getting back on this.

The anomaly, if there is one, is that the model elements in question appear
in different places in the containment tree.

The parts of the Block representing the network are within the scope of the
network. I appreciate that they could be anywhere, but the convention puts
them there, which is a useful thing as you say.

When I create a Switch part, it also has Ports. Those Ports are not really
part of the Switch Part though.

I can define property values of the Switch Part that are not property values
of the Switch type.

I cannot create property values of the Ports on those Switch Parts that
differ from the property values of the Ports on the Switch Type.

Indeed, since the meta-model containing the Switch Type would be a read-only
library by convention, I can't change anything on the Ports on the Switch
Type, but I can on the Switch Parts that the Ports are part of.

Hence the seeming anomaly, I think :-)

Regards

Nathan

nsowatsk

unread,
Nov 12, 2009, 5:58:05 PM11/12/09
to sysml...@googlegroups.com
Apologies, I should have mentioned that the attached Word document contains
the images of the models and containment tree that I am discussing, so you
don't actually need to open the model.

Regards

Nathan


On 11/11/2009 18:43, "Ralph N Hains" <ralphno...@physics.org> wrote:

>

Ralph N Hains

unread,
Nov 16, 2009, 5:39:54 AM11/16/09
to sysml...@googlegroups.com
Ah, a much harder question. What you see is support for shallow structure
(redefinition at a shallow level), with the exception of connectors (by
drawing a connector between two ports on parts in a block you are,
*conceptually*, changing the port in the context of the block, albeit in a
limited way).
If you want a deep structure capability you should really look at Artisan
Studio.
I will say though that if you use this capability (your choice after all) it
can result in conceptually difficult models, an issue that can only be
partly mitigated by tool mechanics (for example Studio provides separate
browsers for scoping relationships and part/port/redefinition
relationships).

nsowatsk

unread,
Nov 17, 2009, 4:25:59 AM11/17/09
to sysml...@googlegroups.com
Hi Ralph

Many thanks for getting back to me on this.

I would like to look at Artisan, but the Uno edition doesn't support import
of models, and I didn't get very far with a conversation with the support
people at Artisan about what version I would need to support that.

I also couldn't get any support from Artisan on some simple features like
setting classifiers on types. So I am afraid that I gave up on Artisan :-/

In your explanation below, I think that you are saying that Artisan supports
a different structure, but that if I use that different structure with
Artisan I may encounter conceptual difficulties, is that right?

Regards

Nathan
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "SysML Forum" group.
> 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
> -~----------~----~----~----~------~----~------~--~---
>

Reply all
Reply to author
Forward
0 new messages