Changing multiple diagram types at once

[Martin Terreni]

I tried to find a way to change multiple duagram types at once through DB, so I don't need to write automation, but the only types there are the basic types (in t_diagramtypes).
How can I change a diagram from BPMN to some type I created? both of them are base on the same type...

[«Midnight»]

Hi Martin,

This one gave me grief too.

You need to look at the StyleEx field. If the diagram is created by an MDG Technology there will be information there. It will look something like a qualified UML metaclass name. Well sort of.

Look for something in this format: MDGDgm=<DiagramTypeID>::<DiagramName>;

The diagram type ID will be the identifier you gave that diagram in your MDG Technology file. The prefix (before the equals sign) should be exactly as I note. There should be no spaces - except any embedded spaces in the diagram type and name; those should be rendered exactly - and capitalization is significant. The semicolon at the end is required, even if there is no other content in StyleEx.

HTH, David

[Martin Terreni]

Thanks.
This would be a hard one for and update query, maybe I'll just code it...

[«Midnight»]

You pretty much need to. I've certainly tried to find a graceful alternative, and I've certainly failed.

Depending on the DBMS you use this would work as a stored procedure. Still, you'll end up with some chunky code.

As EA evolves these things are showing up a lot. I've been saying for some time that we have to steel ourselves for a (completely) new schema, but as yet there's been no move in that direction. As each major build comes out I am half hoping this will happen. Yes, we'd be in for a big learning and upgrade curve, but (IMHO) it would be well worth any pain.

David

[Martin Terreni]

I agree. I do not expect sparx to negotiate the DB structure with the users (though it would be nice  [smiley=rolleyes.gif] ) , but I'm sure thet could figure out quite a lot improvements to it.
One of them could be to make operations/attributes objects (so it is possible to link to them). Though more expirienced people may have more important things...

[«Midnight»]

Well Martin,

As far as linking, if you mean linking connectors you might be out of luck. UML does not allow very many forms of links directly to features, which attributes and operations derive from.

You can get around this in several ways, at least for some connector types. [Hint: look into composite structure diagrams in UML 2.x; the seeds for this were in UML 1.4.2, but have since sprouted.]

The whole EA API could do with a (massive) refresh. This would be a disaster for legacy code of course. What I'd love to see is a new, clean, engine written in .Net. If they did this they could retain the old COM interface as a compatibility tool.

[Sorry Java guys, this is not related to preference or capability. COM to .Net is a far easier port, and could be done within the time and risk constraints of a major EA version. With the current (and far too slow Sun-MS work on interoperability there's good potential for a clean Java interface down the pipe. Ideally this could be done simultaneously. The way that Sparx did the current Java API may irk some, but it turns out to be an excellent first step for the upcoming Sun-MS stuff.]

So, depending on whether I think this will ever gain traction, version 8 seems too long to wait, or so soon we'd better start pedaling harder.   :-/

Sigh...

David