Re: UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- From: Matthias Kaeppler <nospam@xxxxxxxxxxxxxxx>
- Date: Sat, 28 May 2005 12:01:13 +0200
H. S. Lahman wrote:
Responding to Kaeppler...
we had the problem to model a Java 5 enumeration in a class diagram in UML, and our approach was to just model it as a usual class and put a {enumeration} after the class name.
Is that okay? I know UML knows such things as {abstract}, but is it okay to shamelessly plug in your own stereotypes?
No, it's not OK but for an entirely different reason. B-)
Java 5 enumeration is a specific OOPL feature. It has no business being in an OOA/D model. The goal of OOA/D modeling is not to reduce OOP to such a rote exercise that it can be done by a reasonably intelligent orangutan if one has a large bag of bananas. The OOA/D model should be an abstract solution that is independent of particular OOPL syntax and semantics. One /implements/ such a model at the OOP level using the language features at hand.
But how should I model it then? Like a normal class with only public static members?
The Java 5 enumeration feature provides a convenient implementation at the 3GL level for something in a UML OOA/D model. As I originally indicated, I don't do Java, so I can't answer specifically. So I don't know enough about the feature to know what sort of UML model elements I would use it for.
What you need to model in UML is the problem space without worrying about such implementation details. After you have the problem space modeled, THEN you think about where the Java feature might be useful. IOW, don't let the Java tail wag the OOA/D dog.
We also did this with methods:
Since we use a very limited modelling tool, which had no means of modelling methods as abstract or even static, we e.g. modelled a static method like this:
+ foo() : void {static}
Is that okay?
If the tool does not allow one to distinguish class methods from instance methods or virtual methods from concrete methods, then one has to cope somehow. However, I would try to use a more abstract description since the notion of 'static' is very OOPL-specific. The real issue insofar as OOA/D is concerned is whether the method is associated with a specific instance.
Yes, that's what static means in Java and other OO languages in the C family, it's a class wide method, in that it's not associated to a specific instance of a class.
I realize that. But if you were to implement in a dynamically bound OOPL the notion of 'static' would not exist per se. However, one still usually has a notion of class-based methods vs. object-based.
The point is that the UML model should be independent of the 3GL. [One does not even need to implement in an OOPL at all. Translation tools auto-generate straight C code from OOA models routinely for performance reasons.] So one should try to capture essential invariants in the qualifier name that do not dependent on specific language implementations.
What term do you suggest instead?
How about {class method} and let instance methods be the default (no qualifier)?
That's a pretty good suggestion. Thanks again for the insightful read.
-- Matthias Kaeppler .
- References:
- UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- From: Matthias Kaeppler
- Re: UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- From: H. S. Lahman
- Re: UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- From: Matthias Kaeppler
- Re: UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- From: H. S. Lahman
- UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- Prev by Date: Re: Full life cycle development
- Next by Date: Re: Pattern for data conversion between versions
- Previous by thread: Re: UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- Next by thread: Re: UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
- Index(es):
Relevant Pages
|
