-
Key: UMLR-20
-
Legacy Issue Number: 6927
-
Status: open
-
Source: Simula Research Laboratory ( Dr. Bran Selic)
-
Summary:
Diagrams have a frame and a tag that describes the kind of diagram. Most diagrams correspond to a portion of the metamodel, and in most cases there is a one-to-one correspondence between metamodel chapters and diagram types, although variants are allowed for special cases (such as 'package'). There are four kinds of diagrams showing interactions, each with its own unique contents and syntax: sequence diagrams, communications diagrams, interaction overview diagrams, and timing diagrams. Unlike the difference between class diagrams and package diagrams, for example, each of these is very different in appearance and content from the others, even though they allegedly all map to the same interaction model (which might be dubious in practice, given the very different content, but that's another matter). However, the examples all use the same tag, 'sd', for all of the kinds of interaction diagram. Clearly 'sd' is an abreviation for 'sequence diagram' and it is inappropriate for the other types. (The fact that it is an English-language abreviation is another problem that we will let pass for now.) It would seem that each kind of diagram should have its own tag, given that they have different syntax and usage. For example, we could use 'sd', 'cd', 'iod', and 'td' if we wish to keep the same abbreviated format. But in any case the tags should be different and they should be descriptive of the diagram, not the underlying modeling chapter. (The official tag for interaction diagrams as a group is 'interaction', not 'sd' (page 589), so 'sd' is already descriptive of just one variant.)
If the argument is that you can tell apart the different variants of interaction diagram by looking at them, that argument would apply with even more force to the diagrams for different kinds of models, such as class diagrams, state machine diagrams, etc., so we wouldn't need tags at all. (Which may be true, and users will probably not bother most of the time, but let's at least get it right in the standard.)
-
Reported: UML 2.5 — Fri, 23 Jan 2004 05:00 GMT
-
Updated: Fri, 6 Mar 2015 20:57 GMT