Re: native arrays in class diagrams
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Tue, 25 Apr 2006 15:37:01 GMT
Responding to Karl.wettin...
Not sure how to model
class This {
Map<Key, Value[]> valuesByKey;
}
I can only think of
[This](key)<#>--- {0..1} ->[Value[]]
or stretching it out to
[This](key)<#>--- {0..1} ->[<<array>>Value]- - <<implies>> -
->[<<class>>Value]
but I don't like it and can't explan why. How do you do it?
When I first saw this I was about to whip off a Don't Do That missive. Then I remembered that you are not doing specific customer applications but are developing a model compiler/transformation engine. So I decided not to respond because the problem space was unique. However, upon thinking about it, I believe my original instinct still applies: the tail is wagging the dog.
Just because an OOPL provides a particular syntax or idiom does not mean that one needs to employ a specific notational element in the OOA/D model to represent that OOPL feature. (Sadly, UML already has enough of this with things like 'protected' and composition associations that usurp the prerogatives of OOP.) If you look at the MDA profiles for translation methodologies (e.g., "Executable UML" by Mellor and Balcer), they only use a smallish subset of UML. Yet they are rigorous enough that one can do full automatic code generation unambiguously from an arbitrary OOA model that employs that subset.
In this particular case trying to capture Find semantics in a Class Diagram is redundant. The actual key (or attribute) value used during a specific collaboration will have to be defined at the exact point where the relationship will be navigated. To do that one is effectively repeating the same specification as in the Class Model. So the modern approach is to use a simple abstract action language construct to describe the whole thing in the method dynamic description where the collaboration actually takes place, such as:
R1Set = this -> R1 WHERE (color = "blue")
FOREACH member OF R1Set
// do something with the blue object.
where the first line captures the relationship navigation across the R1 relationship. The WHERE syntax provides exactly the same semantic baggage that the Class Diagram representation does. It is also more general because it is not limited to identity keys. Yet the AAL also captures the dynamics of specific selections in an elegant fashion. (The transformation engine can also unambiguously figure out what sort of collection it needs to support the WHERE.)
An added advantage is that one is free to navigate the R1 relationship in different ways based on different dynamic contexts without touching the basic Class Diagram semantics. IOW, the definition of dynamic collaboration context is exactly where it should be rather that being shoehorned into a static representation in the Class Diagram. (More specifically, one does not need multiple relationships in the Class Diagram between the same two objects to describe collaborations based on both direct and serial access.)
My point here is that I don't think you should waste time trying to represent every UML model element or every possible OOPL construct. Instead, select an MDA profile subset of UML and build your transformation engine around that. Then select a reasonable suite of 3GL constructs to address nonfunctional requirements and provide a mapping form the limited UML element set to those 3GL constructs.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
.
- References:
- native arrays in class diagrams
- From: karl . wettin
- native arrays in class diagrams
- Prev by Date: Re: Question on LSP
- Next by Date: abstract factory -- a doubt ?
- Previous by thread: Re: native arrays in class diagrams
- Next by thread: Performanz of CORBA
- Index(es):
Relevant Pages
|
