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 - Stephen

Pages: 1 2 3 [4]
Automation Interface, Add-Ins and Tools / Element Automation
« on: March 17, 2004, 01:47:01 am »
To add new Element's through the automation interface it is neecessary to supply a type (string).
Is there an enum of permitted types or does the string just get stored regardless?

Hi there,

I was highlighting the SQL script as the only "supported" or "official" data repository without any metadata.

You can set up your own profiles to determine your own, unique, set of stereotypes and custom extensions etc. So this route would provide a (version) indepedent way to manage your own model artifacts.

The "best" way forward is still likely to be to create your own base model. Sparx are very likely to support upgrading models across version changes - as we've just seen with the move to EA4. So your in-house empty model will just be upgraded by the system won't it?

The simplest thing is likely to be the best (and I find that intensely irritating most of the time too!)


You could always base everything on a completely empty database - from the server script file.

Then add all your metadata from a corporate profile.... Then you could control all datatypes, stereotypes etc.

Or, start from the base script and add all metadata through the automation interface, to again create your own corporate standard.

Might be quicker to strip out the base.eap file though!

Whilst we might all make suggestions about improving and extending the help file, there is a small omission in the Element documentation.

The Connectors collection is missing - but is refered to and used in the Connectors example


Got me trawling the context menus...

There is an option to "set run state" on components.

I've no idea if this has any impact on code generation (haven't dared try to get something useful out of my models yet!)


You may have me there - I suspect I'm a better hacker than I am a modeller.

I would have expected that building a class structure that controls the initial state of some (key) object requires some sort of external controller. [When I hack something together I might use seeding rules in a database to control the initial state of some object].

For a generic oo style approach you might review the Abstract Factory or Builder patterns. In essence I wouldn't expect to model attribute initialisation rules to maintain primacy without reference to some external state.

Perhaps the panel can teach us both something (Or I've misunderstood your problem...)


You're right with the table being a stereotyped element.
Columns in the table are created as attributes of the table's element.
Keys and indexes are created as methods.
The columns that participate in the index are parameters of the method.

Import a couple of tables using the GUI. Review the tables from within EA, then compare with the contents of the database - look in t_operation and t_operationparams. It should all start to make sense...

Automation Interface, Add-Ins and Tools / Source Code Automation
« on: March 22, 2004, 05:18:21 am »
Is it possible to import the source code, so that it will display in the source code window.

I'd like to import actual source for those "classes" that can't be code engineered

Automation Interface, Add-Ins and Tools / Automation for Dependencies
« on: February 19, 2004, 03:17:48 am »
I'm writing a utility to maintain the spec's for the views, stored procedures and potentially other objects of my data layer (SQL Server) within the "Deployment Model" for a system.

I have imported the table details by hand through the GUI, but will now want to maintain the information in a similar fashion.

For my initial stab at modelling (make that recording) a stored procedure I have created a class and included the appropriate procedure parameters etc.

To model the dependencies (in this case a table) I dragged the sp class onto a diagram and ctrl-dragged the relevent table class (held within another package), selecting to paste the element as a simple link. Then added a dependency connector, filled out the parameters etc. I think I can automate these operations...

This leads to the questions.

1. One for the jury - Does this seem a reasonable way to model sp's?

2. I have a diagram that displays the first-order dependencies. But is a diagram per database object a bit heavy? I'm anticipating drawing in dependencies between middle and presentation tiers also so there could be a lot of diagrams. Has anyone got any good pointers to diagram layout algorithms?

3. I don't see anything in my relationdship matrix. What have I missed?

Pages: 1 2 3 [4]