Pierre, Yves,
UML modeling tools, like Rose, can be used for different purposes. The correct answer
depends very much on how you see Rose.
<Therory ON>
A mechanism (an instantiation of a pattern) has three important aspects: Services,
essential design decisions and implementations. The services provide value to the
clients of the implementation. These are the API's or operations defined by the
mechanism. To a programmer on a team, the word "Singleton" or "Persistant Class" or
"Memento" is shorthand for a whole list of expectations, usually operations.
Secondly, the designer thinks of the design decisions that mold the existance of the
mechanism. The designer may simply say that this mechanism exists or he may have to
add a few details as appropriate - "this print spooler should be a Singleton" or "the
many-to-one association between Client and Claim has a smallish many and is additive"
whereas "the many-to-one association between Client and PolicyProduct is largish and
volatile". The designers think of the mechanism as a packet of essential decisions
that reflect their understanding of the model of the real world. They are just as
happy not thinking about the gory details of the implementations or the services.
(you would prefer your designers to thinking that the country-state relationship is
"static" rather than that it should be implemented with an array). They give the
designer the most leverage because they are the most expressive.
Thirdly, the implementation is the embodiment of the structure and the behaviour of
the services. Mechanisms are often a collaboration between several classes so they do
not fit well with traditional OO modeling. You tend to see bits of different roles
within several collaborating classes. Since inheritance is such a strong concept in
OO, the pattern literature has tended to favour it over spreading services around.
Moreover, the method bodies likely change in the face of the different essential
design decisions and other structure defined by standard UML..
The architecture team should decide what essential design decision are appropraite to
a system. They can simply state that the mechanism is one-size-fits-all or determine
all the essential design decisions that drive it. They define the services that are
available to the programmers and the implementations of each of these in the various
contexts.
It is important to keep these concerns separate - APIs from services and essential
decisions. Each has a different consumer and evolution. If the technological layer
changes, the modeling doesn't.
<Theory OFF>
Now what does this have to do with Rose? Well, I see two main ways to use Rose.
As a modeling tool, the designer constructs a design that will be hand implemented.
In this case, the designer wants the highest leverage. He should simply not the
essential design decisions and go on. The coders will work it out. It is clear to me
that the limitation of one Stereotype per element is much too strict. Everyone and
their dog has seen the stereotype as a cool place to put "just that little thing
that's meaningfull to me right now". But darn, you only get one of them.
A stereotype allows an arbitrary number of associated tagged values with it. These
are the essentail design decisions. It is my understanding that UML 1.4 supports
multiple stereotypes per element. That's good because, just as I am a father, an
employee, a citizen and a son, many of my classes have mutually exclusive but equally
important and repetative roles, plus their own identifying behaviour.
As a modeling tool, I would put the "stereotype" and essential design decisions in
notes. You are using the tool for its visual qualities so there is no use in burying
the decisions behind the diagramme in little dialogue boxes. If you use SoDA or some
report writer then you can do put them in the documentatation. You might even be able
to get away with stereotypes since you may have a closed universe. But since Rose
itself uses stereotypes to control presentation it's a little iffy.
As a code generation tool, you have to be a little more rigorous. We at Codagen
(http://www.codagen.com) have developped our own add-in to get around the single
stereotype problem. You can do your own if you like writing RoseScript. Once you
have the essential design decision, though you still have to convert them to services
and implementations. Again, you can do this through RoseScript or REI. This can get
to be a job in itself. You can compare this to our implementation.
Neil Pitman
Vice-President of Research and Development
Codagen Technologies Corp.
+1.514.288.4802 x 233
[EMAIL PROTECTED]
(BTW, you can prepend "I my opinion," to any of the preceding sentences, but I guess
you knew that already)
Yves Stalgies wrote:
> Hi,
>
> I have a rather trivial suggestion: take a sterotype <<singleton>>.
>
> regards
>
> yves
>
> >>> Pierre BEZENCON <[EMAIL PROTECTED]> 12/07/00 10:21AM >>>
>
> Hi,
>
> Is there a way to describe a class as singleton (instance) in UML (in Rose
> actually) ?
> ************************************************************************
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
>http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> *************************************************************************
>
>
>
>
>
>
>
>
>
>
>
>
> !
!
> !
> !
> !
>
>
>
>
>
>
>
>
>
>
>
> !
!
> !
> !
> !
>
> ************************************************************************
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
>http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> *************************************************************************
--
Neil Pitman
[EMAIL PROTECTED]
+1.514.863.5465
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
