Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Thomas Mercer-Hursh on January 18, 2008, 03:08:01 pm
-
Does anyone have any material which talks about the contents of t_xref. The info in the help is pretty nominal.
-
Emmm. A little inf: it holds the Information Objects Conveyed. I asked for automation support but with no feedback so far :(
-
"Information Objects Conveyed" .... OK .... so this means what? What sort of object or linkage or annotation produces this?
-
Thomas(es),
Best guess...
I think this is what the Set Up Cross Reference page in the EA help is talking about. Said page being indexed not by its own name, but by Cross Reference followed by either Set for Element or Use for Element; it is in the contents under Modeling with Enterprise Architect | Work With Elements | Element Tasks.
If the above guess is correct then "Information Object" might be an unfortunate term, since (IMHO) it sounds like it should be some kind of formal element type or something. I suspect, without proof, that the term just means the 'thing' you cross reference an element with.
David
-
Hmmm. Well, that gives me a hint ... I'll poke around a bit and see what I can discover.
Of course, a documented schema would be nice ...
-
...
Of course, a documented schema would be nice ...
What?
That's the thin edge of the wedge! Perish the thought. What's wrong with the (wrong) way we've always done these things in the past?
Next thing you know they'll be telling us we should ask for maps when we're not even lost yet.
:D
-
I just had this peculiar idea that an EAP file for the repository schema ... there must *be* one, surely ... would be a lovely piece of documentation.
Shoemaker's children, I guess.
-
Very much so, it seems.
Many of us have attached to an EAP file or a repository via ODBC, then generated the model. Seems to work.
Still, there's little information to be had that way, just the skeleton. Enough to infer a great deal, but hardly the kind of thing we need to do substantive work.
Sigh...
-
I notice, though, that looking at a repository in Access, no relationships are defined for t_xref, so reverse engineering into a model probably isn't going to tell me a lot more.
-
No time... You can attach Classes to Information Flow. Create such relation one and search the context menu.
-
What I am seeing in my actual data for the sample repository I am working with is
Name = "Stereotypes" and Type = "element property" or "connector property" with an Description which looks something like @STEREO;Name=oeInclude;GUID={A10BA680-0109-45ab-AD7F-3B95AC6F801C};@ENDSTEREO; and there is a Client GUID, but no Supplier. The GUID in the description is the GUID of the stereotype. In this particular case, the Client is the GUID of the corresponding t_object. I suppose that I can tell which table to find the Client in by what the stereotype is a stereotype of?
or
Name = "Custom Properties" and Type = "element properties", "connector property", "connectorDestEnd property", or "connectorSrcEnd property" and the Description is something like @PROP=@NAME=isDerived@ENDNAME;@TYPE=Boolean@ENDTYPE;@VALU=false@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;
Again, a Client GUID and no Supplier. Again, I suppose that I can deduce the table of the Client GUID from the Type and the syntax of the Description seems apparent enough.
Now, all I guess I am missing, is why.
In the case of the stereotype, the object itself has the stereotype, so what is added by this additional connection?
In the case of the custom properties, where do these come from? Things missing from the schema? E.g., in this specific case, this is a foreign key association between two tables.
-
t_objectproperty (or ...ties) I think.
-
t_objectproperities has the property/value pairs for tagged values on objects. I'm not sure what that has to do with the properties found in t_xref. The ones in t_xref do not appear to be ones that show up in tagged values.
My guess is that these are properties which apply to special stereotypes, like foreign key relationships, which are not directly supported by the schema.