Shape script for all

[Martin Terreni]

I think it would be helful if it was posible to create shape scripts for all types of entities, bit only stereotyped ones, thus change the default EA look for whatever entity required.

[thomas.kilian]

I would vote for just the opposite: ban ShapeScript in favor of default icons from UML. If you can't live without it, switch to Visio.

[Frank Horn]

If shape scripts were banned, I would at least request options for everything to be shown or not shown for an element, connector or feature in a diagram. Without shape scripts there would be no way to see things like e.g. tagged values for connectors in diagrams.

[«Midnight»]

I would vote for just the opposite: ban ShapeScript in favor of default icons from UML. If you can't live without it, switch to Visio.

Sorry, but I cannot agree to this one.

One of the great strengths of UML is extensibility. Alternate shapes can be used, and are encouraged - look at robustness diagrams for example, or BPMN, or SysML...

What we do need to do is beef up shape scripts to the point where we can think like we would when using 'default' behavior in UML and get analogous results.

Another 0.02 CAD. This is beginning to add up...

David

[thomas.kilian]

It all ends up in having custom icons for everything. Then you need to tell every reader: the circle on my diagram is a triangle and the square is triangle too but with different flavor. And, the triangles are of course all square circles. Or red=blue and blue=red. Extensibility in UML sense (to my understanding) should not be over-used by custom icons. Superstructures is already thick enough with a few icons. I just start screaming "Indians!" when I see these awkward Visio and Powerpoint drawings.

[«Midnight»]

Yes, I agree with you about the proliferation issue.

But there are still well-known and documented sets of conventions, and these can be created in future. Some will be scoped to an enterprise, some to a domain, but they are consistent withing their bounds.

Of course these have specific purposes. The framers of UML provided for this by making the provision for special-purpose notations, and through the extension mechanisms of UML itself.

One of these extension mechanisms - the most powerful for those of us who are not in a position to develop an entire new metamodel - is the concept of a profile. And that's just where EA comes in; profiles are an excellent way to introduce shape scripts, and to manage the features you want displayed, and how.

David

[Eve]

After posting something related to this in another thread I thought it would be best to echo those sentiments in this thread.

IMO Shape scripts are ultimately there to provide for models not covered by UML.  There are plenty of standards out there covering all sorts of domains, many have their own special notations.  Plenty are so well known within the domain that changing the shapes used to match with UML would destroy all meaning to the majority of users.  Some domains are so alien to UML that representing them using standard UML shapes wouldn't work.

Ultimately, there needs to be the capability to extend the drawing of EA.  It needs to be extended and made more powerful as EA is.  At the same time, the shapes used should always be the standard shapes for your domain.  If that domain is UML, skip shape scripts and just use the standard EA shapes.  If that domain isn't UML, use the standard shapes associated with that domain.  Don't try to use UML for everything.

[Frank Horn]

If that domain is UML, skip shape scripts and just use the standard EA shapes

Unless you want to display things in your diagram for which EA offers no option (like tagged values of connectors or the versions of elements).

Here's an example where shape scripts come in handy in a strict UML domain:

We keep overview models of our projects with component diagrams showing the dependencies of exe/dll libraries. These models are being tagged and branched (in a version control sense, which is a PITA by the way cause EA doesn't support it and we have to fiddle with the xmi files to switch the stubs of nested controlled packages to a branch) and of course we want to see on the diagrams which version of a component references which version of another one.

So we introduced a stereotype "versioned" with a shape script:

Code: [Select]

decoration version
{
   orientation="S";
   println("#version#");
}

We would have preferred to generally define this for components instead of using a stereotype. This is why I'm all for Martin's suggestion.

As to abcde's qualms: you may as well ban violins cause people who can't play will make an awful noise.

[thomas.kilian]

Don't try to use UML for everything.

Absolutely.

I would like to add: Don't try to use a UML modeling tool for everything.

[thomas.kilian]

As to abcde's qualms: you may as well ban violins cause people who can't play will make an awful noise.

No. Just don't try to make a piano out of a violin.

[«Midnight»]

...Just don't try to make a piano out of a violin.

Of course not. There's not nearly enough wood!

[Thomas Mercer-Hursh]

While my tuppence USD is no longer worth as much as your tuppence CAD, I'd like to weigh in on the side of more capability rather than less.

Without going so far as to turn circles into triangles, a wee bit of decoration can be a very useful way to add information to a diagram.  Coloring a boundary line red to highlight a particular type of component doesn't change the overall appearance and intuitive nature of the component in standard UML notation.

I would like to see three things in particular:
1. Shape scripts for standard objects so that one could modify them as needed.
2. Shape scripts based on tags, especially if they would supplement rather than replace the normal shape script for the object or connector.
3. DOCUMENTATION WITH EXAMPLES ... not that using shape scripts is obscure or anything.

[«Midnight»]

Well said Dr. T!

[KP]

2. Shape scripts based on tags, especially if they would supplement rather than replace the normal shape script for the object or connector.

Just to be clear, what you want is to define a tag that has its own decoration shape script and can be applied to any kind of element. For example a tag named "Urgency" which would display a red exclamation mark when its value is "High" and can be applied to a class, use case, requirement etc etc.

That's an excellent idea, but seriously non-trivial...

[Jan ´Bary´ Glas]

a tag that has its own decoration shape script and can be applied to any kind of element

That seems helpful and powerful. Is a feature request applied?