Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - benc

Pages: 1 ... 11 12 [13]
General Board / Re: Release 607
« on: April 14, 2003, 06:00:12 pm »
Hello again Tjerk,

On the Properties window... we've seen this behaviour occasionally and it appears to be a 3rd party software issue.
We're hunting down a work around currently- other than restarting EA...


General Board / Re: Release 607
« on: April 14, 2003, 05:35:29 pm »
Hi Tjerk,

Thanks for the feedback.

  • The newline issue should be resolved as of build 609
  • We'll look at the logging in some more detail- the validation passes are performed until a valid set of classes is reached according the UML profile constraints.  So if you have an XSDchoice stereotyped class that has no containing
    class, it will discard it try again.
  • As regards namespaces- probably best to keep the prefixes as tagged values on the package.  This way you'll have a single point of control when the "prefix de jour" becomes "foo" instead of "bar".  Regarding the xs: prefix in particular- best to use the provided XSDDataTypes package.  That said, if many users prefer to include the prefix before each UML attribute, we might look at getting the schema generator to "make a guess" at what part is the namespace.  This approach could be messy though...
  • Quote
    Would be nice to include XSD as one of the languages, just as e.g. java and treat them the same. Maybe include an options window in the View/Options dialog for XSD generation.

    We'll have a look at this...
  • Quote
    I use the <<XSDSchema>> component as a representation of a schema, am I wrong in doing so? Otherwise, I would like the XSD generation to be possible on components as well (see previous issue).

    In a future release the <<XSDschema>> stereotype will be available on components- it is not currently.  Support for aggregation (and composition) connectors is coming also.
  • The classname prefix behaviour can be turned off by using tagged values on the package or on indivual complexType classes.  The prefix helps ensure uniqueness of element names within a schema.  Useful if the xsd ever gets generated in a "Garden of Eden" style, where all elements (from all class attributes) would be declared as root elements.
  • Quote
    I get a "failed class constraint" due to the default constraints in the UML profile!

    There could be lots of reason for a class failing constraints from the profile.  Eg an XSDchoice class that has no owner.
    Note the constraints specified in the help file are non-negotiable- they form part of the profile.

Bugs and Issues / Re: Cardinality between database objects
« on: June 12, 2015, 02:11:38 pm »
Hi Modesto,

I think this issue was resolved in Build 1213. The release notes for 1213 contain an entry like:
Foreign Key dialog now saves child cardinality

Can you please confirm that this addresses your concern?

I hope it helps.


Uml Process / Re: Independent class diagram
« on: June 15, 2015, 09:58:17 am »
Hi Lukis,

As you discovered, when you create a connector in EA, by default it will be drawn on all other diagrams where those two elements appear.

If you don't want the connector to be drawn on all other existing diagrams, after you draw the connector, right-click it and choose from the context menu: Visibility > Hide Connector in Other Diagrams. You'll get a list of diagrams where that connector appears. Clear the appropriate check boxes or just click "Suppress All". (If those other diagrams are open when you do this, you might need to reload/refresh them to see the changes.)

Hope that helps.


Hi Wolf,

Sorry to hear you had troubles getting this to work.

I am curious about the XML editing you did though. Was it actually the XMI you edited or the generated ArcGIS XML Workspace document? They are quite different things.

If the latter, after editing that autogenerated XML Workspace file you still would have the old values left in your original EA model. So upon discovering issues when importing the workspace document into ArcCatalog, you wouldn't be able to simply tweak the original model and regenerate. (Not without first making the same tagged value changes in the original model of course). I do agree that the XML workspace import errors can be too vague, which is why we programmed so many checks and warnings into the model validation script.

On the other hand, if you actually did export and edit the XMI file from EA (that is a file with complete model info, not the ArcGIS XML workspace document), you could reimport the edited XMI file back into an EA project. Then rerun the model validator and address any remaining warnings/errors to get the ArcCatalog import to succeed. I hadn't really considered this search-and-replace strategy using XMI at first, but it is a possible approach for others that wanted to do such an update on tags and not use a Model Script.

As for the model validation script, the code changes I mentioned have been included in the updated script linked from here:

So the model validator will more gracefully complain about very wide strings now. The same updates will be rolled into a subsequent Enterprise Architect release.

Thanks for posting your feedback.


PS: In case you haven't seen it yet, there is a introductory tutorial/webinar available here, with an example model and generated schema available for download:


I created an «ArcGIS» Workspace model from scratch (using the ArcGIS workspace extension/ pattern).  My model is quite extensive and now I realize that EA left virtually all 'tagged values' for attribute columns empty. Examples are "IsNullable" or "Length" etc.
Many of the ArcGIS tags for fields have a default value. For example IsNullable is a boolean value, set to true by default. Even though length has an empty/0 value by default, the exporter will insert the valid ArcGIS default of 50. You get a warning for that, which you can ignore if you're content with 50. Otherwise you should specify a valid length value for your fields.

If you actually see an empty value for say IsNullable, please let us know which version of Enterprise Architect you are using. It would also be worth sending a note to Sparx support so they can investigate further.

The user interface to enter tagged values is what I consider somewhat "user hostile" meaning that if I have to enter these tags manually it will take me months.
There are two interfaces for editing tags. I find the dockable view handy (Main Menu | View | Tagged Values). It refreshes as you select another element or field (UML attribute). It can be handy if you need to edit a specific tag for numerous elements or attribtues - especially when the values for that tag vary per element/attribute.

Is there an automated way to do populate these tags (at least with default values?)
Yes you can automatically populate tagged values. A Model Script is probably the easiest/safest way. But if it is just to insert default values for the ArcGIS profile tags, you should not need to bother.

I am not sure which errors are show stoppers but when I run the validation script I get an error on line 1702
ArcGIS™.ValidateArcGISModel error: Overflow: 'CInt', Line:1702      
If CInt(length) > MAX_TEXT_LENGTH Or CInt(length) < MIN_TEXT_LENGTH Then
Here the validation script should definitely be improved by using CLng instead of CInt. I guess you inserted a length value greater than 32,767 and CInt blows a fuse over that. We'll get that corrected forthwith.

Now the script was in the process of reporting a warning. From memory, only file geodatabases allow you to have string lengths greater than 255 characters. So a schema with string fields above that limit probably won't work if implemented on other types of geodatabase. If you're ok with that and really want string fields wider than 32,767 characters, you can stop the validation script from complaining:

At line 1702, change CInt to CLng in both places (you could probably even do a global search/replace for this throughout the script)
At line 147, change MAX_TEXT_LENGTH from 255 to whatever limit you like.

You can get the script code here, along with instructions on how to import it into Enterprise Architect (so as to workaround the issue with the built-in script):

This is also where we will first post the updated script before it gets rolled into an Enterprise Architect release to update the built-in script.

Anyways I am somehow getting the impression that this extension doesn't get too much use.   Has anybody used this extension before and successfully produced an XML model?
Apart from myself, I know others outside of Sparx that generate ArcGIS XML Workspace documents and import them to ArcCatalog successfully. It gets a fair thrashing along the way, but we obviously haven't used strings wider than 32K yet. As with other types of automated schema generation, there is some set up and model config involved. So there's a learning curve, but hopefully not too steep.

I hope this helps.


You might have a look at another script that does the same kind of thing... From memory, it was written against EA 10.x or 9.x. Have a look at the function AddRelationshipClassTags starting at line 1802 here.

It adds a bunch of tags 'manually', but synchs the connectors against the profile all at once, right at the end of the script. (See the comments starting from line 1947 and the call to SynchProfile at line 468.)

I can't remember which release of EA it was fixed in, but the tagged value synch became smart enough to preserve existing values of the same-named tags and bring those 'unprofiled' tags nicely into the profile as part of the synch. This particular script works on EA's ArcGIS profile... Been a while since I used that script, but I think that's roughly how it behaved anyway.

Given that you haven't got SynchProfile available from the java API - could this be one manual step, after script is run, achieved via the UI?

I hope that helps.


Automation Interface, Add-Ins and Tools / Re: XSD generation problems II
« on: February 09, 2005, 04:52:18 pm »
Hi atingley,

Thanks for the note. As far as I can tell this a bug - schema A definitely shouldn't require includes, if the pacakge doesn't contain references to C and B.

We'll try to get this resolved ASAP. Thanks again for letting us know.


Hi Guys,

Does this thread help any?;action=display;num=1097227460

I believe charge's solution of referencing interop.dll is on the money. Let us know if this does not resolve the problem.


Hi Guys,

The documentation is certainly lacking for the XMIType parameter. Apparently the only recognised value is 2, which generates XMI using the Unisys/Rose format. All other values result in EA's default XMI. We've discussed the possibility of retrofitting a set of documented values to allow for exporting to the other supported XMI formats, 1.2, 1.0 etc. So you would call something like :

Code: [Select]
proj.ExportPackageXMI(Pkg.PackageGuid, EA12, ...)

Jens, thanks for your patience in this regard and my apologies for a delayed response. Hopefully the updated API will prove useful.


Automation Interface, Add-Ins and Tools / Re: Ordering elements in XSD
« on: February 09, 2005, 04:13:36 pm »
Hi atingley,

Try putting the position as a tagged value on the 'other' end of the association. (Probably your association Source end). It's counter-intuitive, but the schema generator expects the tags for the association to be on the source end.

(Actually, it relates to a bug that we'll need to fix in a backward compatible way for existing schema models - ie. make the generator look first for the tags on the target end, then check the source end if not present.)

You should be able to set any other tags that apply to class attributes to association ends in the same way. For example form=unqualified, anonymousRole=true etc.

I hope this make some sense.


Automation Interface, Add-Ins and Tools / Re: Behavior
« on: January 31, 2005, 04:49:04 pm »
Hi Roy and Olaf,

The original intention behind the behaviour field was to document some implementation/algorithmic notes about the operation and optionally display this info in diagrams. In the context of code gen - the behavior info is generated as comments in the operation body for inital generation only - ie. not round tripped.

On a related note, I believe EA 4.51 will introduce an "Initial Code" field in the same dialog for writing a code stub - again not round-tripped currently, but we're working on it.


Automation Interface, Add-Ins and Tools / Re: XSD Generation Problems
« on: January 31, 2005, 04:39:38 pm »

Thanks for the note.

First Problem : Is this what you are after :

<xs:complexType name="MyType">
  <xs:element name="MyType.Kind" type="myns:MyEnum"/>

where the reference to MyEnum is prefixed by the targetnamespace prefix "myns"? You should be able to achieve this by creating MyKind as an enumeration stereotype (available from the XSD profile) and ensuring that its pacakge uses "myns" as the targetNamespacePrefix tagged value. Let me know if this doesn't work for you, or if I have misinterpreted your intention.

Second Problem : As atingley mentioned - it's because you referenced types from another package. To specify the schemaLocation put a tagged value on the referenced package called "schemaLocation" with the appropriate value. This is mentioned the xsd doco, but is not defined in the profile - I'll add this.

(Note you can also use the targetNamespace and targetNamespacePrefix tags on the external package, to affect the import statement and xmlns attributes)

Third Problem (re: xs prefix) : Fair comment, I think ideally users should also be able to choose the prefix for the xsd schema elements (eg xs or xsd). In general though, it's probably best to avoid using these for your own namespaces ...

Fourth Problem (re: full namespace prefix) : The schema generator appears to be at fault here- it shouldn't be inserting the full namespace path. I think the only valid options for qualifying the types in the schema are :

a) use a targetNamespace prefix based on a defined targetNamespace. In EA, use the targetNamespace and targetNamespacePrefix tagged values on the schema packages.

b) Use no prefix (which means the default namespace for the schema must be set appropriately). In EA set the defaultNamespace tagged value on the package being generated.

I hope this helps/explains.


Hi Sergio and Gary,

Currently EA's code template framework does not directly support generation of ports and parts. We are aware of this limitation however, and will be adding this functionality to the code template framework. One possibility that may interest you for now- you can make a call to an add-in function from within the code templates. For example you could provide an add-in with the details of the class currently being generated and have the add-in deal with generation of the ports and parts- then pass this back to your code template. I have used this approach in the past to overcome certain limitations in the code template framework.

This involves use of some undocumented features,  but you can check this related thread:;action=display;num=1088595585;start=3#3

Basically your class body code template might contain something like :

$result = %EXEC_ADD_IN("MyAddIn","MyFunctionToGeneratePorts",classGUID)%

Your addin function would be dealing with the Element.EmbeddedElements collection. (Note we will be adding "Part" as a member types for this collection in EA 737)

As regards code generation of state machines and other behavioural aspects of the UML model, we are currently doing some preliminary development in this area and plan to support this in future. However, this functionality won't be available in the short term.

Gary, in response to your note : EA does have a useful profile mechanism which can be used in conjunction with code templates. (Tagged values and stereotypes provide the primary extension mechanism for profiles and code gen). If you care to elaborate further on the your specific needs, that would be great. We always appreciate the feedback and try to respond as best we can :)

I hope this is of some help.


Automation Interface, Add-Ins and Tools / Re: New Language Support
« on: September 29, 2003, 07:57:10 pm »
Hi Devin,

You can add a new Product/Language under EA using the Configuration | Langauage Datatypes menu option.  
This does not however, facilitate reverse engineering of that language.

(For Code Engineering purposes, the new product can be combined with EA's code Templates for forward generating code.  That is, you can create a set of php templates in EA and generate your code base using them.)

Your strategy of using XMI in round-trip engineering sounds inventive, though I think what's really missing is a "php2xmi" tool.  Then the approach might be:
1.  Forward generate PHP code in EA
2.  Modify PHP code outside EA
3.  Generate the equivalent XMI using "php2xmi"
4.  Import the generated XMI into EA.

Unfortunately, I don't know of a tool converts php code to XMI.

We have had several requests to natively support PHP in EA.  It is certainly our intention to do so, but it won't be in the immediate future.

Sorry I could not be of more help at this stage.


Pages: 1 ... 11 12 [13]