Showing Persistence on class diagrams

[mhyde]

Hi,
Is there an easy way to visually show in class diagrams whether a class is marked as persistent or transient? Currently we've resorted to using different colours, but I'm sure there must be a more automated way!

Any suggestions would be gratefully received.

[KP]

Isn't a persistent class usually denoted by the <<table>> stereotype? If that isn't suitable, how about inventing your own stereotype, e.g. <<persistent>>.

[mhyde]

Thanks for the advise. We've created a new stereotype and this works well. It does beg the question of why have a "persistence" field for a class though. I would of thought that, having provided it, we should be able to use it and have the differentiation shown on a diagram. Oddly enough, when I press the Help button on the Class properties window, the screenshot omits the Persistence item. Is this a fairly new addition that perhaps isn't fully developed yet?

[thomaskilian]

The persistence field can be evaluated for example during model transformation (generate table only for persistent classes). OTOH it is a legal question why these properties do not appear. Might be that a more flexible compartment approach would be a benefit here.

[KP]

It does beg the question of why have a "persistence" field for a class though.

Is there? I didn't even think of looking for it

Well, you can use that property in shape scripts. Give this a go:

Code: [Select]

decoration persistence
{
 print("{#persistence#}");
}
or how about this one...

Code: [Select]

decoration persistence
{
 if(HasProperty("persistence","persistent"))
 {
   setfillcolor(0,255,255);
   rectangle(0,0,100,100);
 }
}
UML doesn't have any suggestions on a notation, so feel free to invent your own.

[sargasso]

Object persistence has nothing (little?) to do with databases and tables.  It is used to indicate that the state of the object is rendered stable between, possibly asynchronous, invocations of the object reference.  The mechanism of persistence may be anything - as an example, consider a cookie.  UML persistence says nothing about the mechanism or the location of the persistence.

I have of late been getting somewhat dismayed that lower forms of UML life consider that there is a one-to-one relationship between an instance of a class and a "record" (tuple) in a database.  This is patently not so and reeks at least of bad practice but probably moreso bad data design.

regards
bruce

[mikewhit]

"...lower forms of UML life..."

Would that be pondlife, or just higher invertebrates ?

Me, I'm a slug.

;-)

Mike

[sargasso]

  If the suit fits ...


btw Mike, I didn't consider you at the shallow end at all ...