MetaCase Homepage
Forum Home Forum Home > > MetaEdit+
  New Posts New Posts RSS Feed - Thousands of Objects in a Graph
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Thousands of Objects in a Graph

 Post Reply Post Reply Page  <123
Author
Message
janne View Drop Down
MetaCase
MetaCase
Avatar

Joined: 25.Mar.2008
Points: 58
Post Options Post Options   Thanks (0) Thanks(0)   Quote janne Quote  Post ReplyReply Direct Link To This Post Posted: 02.Dec.2009 at 08:54
Hi,

Please try following:


Or by using the form based metamodeling tools structure like:




Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 643
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 02.Dec.2009 at 12:03
I'm not sure Janne answered your question, so I'll have a go too. Pick whichever answer you like :-).
 
It's generally not a good idea to make Datatype or Item type = Object, because that would allow absolutely any kind of object. If you need to do it, hold shift down while opening the dialog from which you choose the object type, and Object will magically appear in the list.
 
The best way is probably to make a common supertype of Entity and Attribute, and mark it as abstract (start its name with an underscore), e.g. _Content. The property type then has Datatype = Collection and Item type = _Content.
 
Looking at the names you use and the examples, I wonder if you might actually want something else. If Entity_With_Attributes only ever has one Entity, then make that a separate property, of Datatype Entity, and you can have the second property, a Collection of Attirbutes, without needing to allow contents of different types.
 
Alternatively, if what you really want is to draw the Entity_With_Attributes as a big box that contains attributes, you may want it not to have properties, but to simply visually contain the Entity and Attribute objects that you put in the graph. You can then use the MERL commands, contents and containers, to access this information both for rules (making the symbol show an error if the enclosure is wrong) and generation.
 
What is the semantics of ER diagram (type B)? And why do you want two different graphs showing the same thing (in this example at least)? Think about whether the objects in the lower graph are identical to those in the upper graph, or are themselves new objects that refer to the objects in the upper graph. Think about whether you can use 'convention over configuration', e.g. if the default situation is that a Type A graph has a roughly isomorphic Type B graph, then you don't need to draw the Type B graph, since it adds no information: you can already generate what you want directly from the Type A graph.
Back to Top
sap630 View Drop Down
Contributor
Contributor


Joined: 22.Sep.2009
Points: 10
Post Options Post Options   Thanks (0) Thanks(0)   Quote sap630 Quote  Post ReplyReply Direct Link To This Post Posted: 03.Dec.2009 at 00:44
Thanks Steve and Janne - "Collection" was the key.

Originally posted by stevek stevek wrote:


Looking at the names you use and the examples, I wonder if you might actually want something else. If Entity_With_Attributes only ever has one Entity, then make that a separate property, of Datatype Entity, and you can have the second property, a Collection of Attirbutes, without needing to allow contents of different types.

^ This was what I was after.

But I can see how the first thing you mentioned would also work:
Originally posted by stevek stevek wrote:

The best way is probably to make a common supertype of Entity and Attribute, and mark it as abstract (start its name with an underscore), e.g. _Content. The property type then has Datatype = Collection and Item type = _Content.


Where you mention:
Originally posted by stevek stevek wrote:


e.g. if the default situation is that a Type A graph has a roughly isomorphic Type B graph, then you don't need to draw the Type B graph, since it adds no information: you can already generate what you want directly from the Type A graph.

Correct, however, the problem isn't generation but modeling without cluttering the screen. As the thread title mentions, we would eventually have thousands of objects in a low-level graph (similar to subgraph of type A) with "chunks" or "views" of those objects as groupings in another subgraph (similar to subgraph of type B). We would like the modellers using the type B subgraph to have direct access to the underlying object from the type A subgraph (to avoid duplicating information).

Cheers.


Edited by sap630 - 03.Dec.2009 at 00:47
Back to Top
 Post Reply Post Reply Page  <123

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.05
Copyright ©2001-2022 Web Wiz Ltd.

This page was generated in 0.029 seconds.