Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: kiwi on February 27, 2002, 10:09:03 am
-
I know the idea comes from the competitor, but Domain-Neutral colouring of classes is a great idea... Here's Peter Coad's PDF file on it:
http://www.togethersoft.com/files/services/jmcu/chapter1.pdf
The idea for those who aren't familiar: Coad proposes four domain-neutral class 'archetypes': moment-interval (time), role, party/place/thing, and description (seems to be like a metadata class).
For a better definition of what he means by the 'Description' archetype I found this link:
http://www.togethercommunity.com/coad-letter/Coad-Letter-0082.html
Coad proposes that with just these four you can colour-code your designs and complex diagrams suddenly make a lot more sense, and in fact you start seeing architectural patterns appear with the colour arrangements.
Fascinating stuff.
This would require that EA add the four archetypes to the 'stereotype' list.
PS relating to stereotypes, is there more documentation on what each of those stereotypes should in more detail?
-
Hi,
Thanks for the link, I have had a quick read of the material and see what you are asking for.
Thinking about this, all that is really required is to have a facility to associate a color with a stereotype - in much the same way you can now associate a metafile with a stereotype. If the color field has a value, EA will fill with that instead of the default.
I think an additional flag would be required to allow the stereotyping of the classifier to affect instances (ie. objects) derived from the original stereotyped class. You may not always want this behaviour.
You could then define whatever stereotypes you like in the Stereotypes reference screen - and set the associated color and domain neutrality.
Be aware that the UML spec allows color as a tool specific extension that is not necessarily portable to other tools. I have included some notes from the spec on this topic below.
In the meantime I will look at how this could be added.
Geoff Sparks
From the UML 1.4 spec (about page 3-32)
********************************
To permit limited graphical extension of the UML notation as well, a graphic icon or a
graphic marker (such as texture or color) can be associated with a stereotype. The
UML does not specify the form of the graphic specification, but many bitmap and
stroked formats exist (and their portability is a difficult problem). The icon can be used
in one of two ways:
1. It may be used instead of, or in addition to, the stereotype keyword string as part of
the symbol for the base model element that the stereotype is based on. For example,
in a class rectangle it is placed in the upper right corner of the name compartment.
In this form, the normal contents of the item can be seen.
2. The entire base model element symbol may be “collapsed” into an icon containing
the element name or with the name above or below the icon. Other information
contained by the base model element symbol is suppressed. More general forms of
icon specification and substitution are conceivable, but we leave these to the
ingenuity of tool builders, with the warning that excessive use of extensibility
capabilities may lead to loss of portability among tools.
UML avoids the use of graphic markers, such as color, that present challenges for
certain persons (the color blind) and for important kinds of equipment (such as
printers, copiers, and fax machines). None of the UML symbols require the use of such
graphic markers. Users may use graphic markers freely in their personal work for their
own purposes (such as for highlighting within a tool) but should be aware of their
limitations for interchange and be prepared to use the canonical forms when necessary.