6

^ e.g. is it allowed to link directly from a use case to an activity diagram - or- from a class diagram to a use case by connecting them with an association note -or - form a component diagram to a object diagram? also, if it's allowed, and I firmly believe it is since I saw such diagrams, where does it say so in the omg formal/15-03-01 document?

Edit: For example where does the specification say something like this is even allowed? enter image description here

migrated from stackoverflow.com Apr 21 '16 at 19:06

This question came from our site for professional and enthusiast programmers.

  • Interestingly, during collaborative "informal" design (e.g., on paper or whiteboard), it is extremely common to mix UML types and even borrow notations from different diagram types. IMHO it's a pity that the "official" spec doesn't make concession towards mixed-type diagrams. (Old academic paper on the topic: dl.acm.org/citation.cfm?id=1297047 with direct pdf at cs.cmu.edu/~udekel/papers/udekel_oopsla07.pdf) – Uri Apr 21 '16 at 22:04
3

I'm looking at what is currently the latest UML specification, the Unified Modeling Language v2.5, released in June 2015. It is specified in an English language specification and four XMI documents.

I think there are two things to consider to provide a complete answer.

The first thing to keep in mind is the difference between a "model" and a "diagram". Annex A defines models and diagrams. Elements, such as classes and nodes and associations and actors and use cases, are part of a model. Different models have different valid elements, which are described in the standard. Diagrams are graphical views of the model. A repository contains one or more models of a software system.

The second thing to consider is the usage of UML. UML is a language, a set of standard notations with defined meanings. Martin Fowler identified different UML modes, such as sketch, blueprint, programming language. Sketches and blueprints are designed for human consumption. They take advantage of the defined notations to reduce ambiguity in a diagram and make it easy to communicate ideas in a shared language. UML as a programming language is a mode designed to be consumed by a tool, such as for autogenerating code.

The combining of models is not allowed by the formal specification. The definition of an Activity model doesn't allow for the inclusion of elements such as actors, lifelines, and objects. You can see this in the XMI documents, or in Section 15 of the English-language standard. There's simply no concept of this.

However, when creating a diagram (either by hand or with a software package), there's nothing that precludes this. For example, Figure 18.12 shows a use case diagram that is associated with a state machine diagram. Tools may show these in different formats. I'd have to dig deeper to see if it's possible to link all of the diagrams that you mentioned, but it is possible to associate an element of one model with an element in a different model, so that the output diagram may contain visual representations of multiple models in one view.

Annex A specific supports this:

This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.

  • Annex A explicitly tells the reader that he has (almost) absolutely freedom on what to put in a diagram. As long as it helps communication any diagram can show almost any combination of UML elements. The diagram classifications itself are more for convenience to ease handling of the different modeling domains. – qwerty_so Apr 21 '16 at 19:57
  • @ThomasKilian I believe I said this. There's a difference between a "model" and a "diagram" in UML. A diagram is the graphical representation, which may include one or more elements from one or more models. I'll clean up a few parts that may be confusing. – Thomas Owens Apr 21 '16 at 19:59
  • I was not criticizing your answer Just confirming. I meant this NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced. – qwerty_so Apr 21 '16 at 20:01
  • @ThomasKilian Ah, OK. I thought there was something factually wrong in my answer and I just couldn't see it. Thanks. – Thomas Owens Apr 21 '16 at 20:02
  • You could add the citation. It's one of the few points where superstructures is rather clear in what it says ;-) – qwerty_so Apr 21 '16 at 20:05
3

Your example looks a lot like one of the example diagrams in the official UML 2.5 specification:

enter image description here

So I guess if it is in the specification we can be reasonably sure this is valid UML.

0

I didn't really expect a nitpicking about what a diagram and what a model is.

Nevertheless I think I found one notation that does the trick flawlessly. It is known as 'Information Flow' and uses the dependency association and the keyword flow in double chevrons/guillemets. A book in my hands says: "An information flow specifies that one or more information items circulate from its sources to its targets. Information flows require some kind of 'information channel for transmitting information items.'"

So this is what it looks like enter image description here

And the official formal/15-03-01 document says in

20.1.3 Semantics (about InformationFlows) :

In practice, a constraint on InformationFlow requires that sources and targets must be one of the following types: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition, Behavior, and InstanceSpecification.

..so perfect, that's exactly what I was looking for. Well there might be other ways to link models directly, but I had to find something in the official OMG docs.

  • This doesn't "link models directly". An InformationFlow represents the flow of information between two entities in a model - two actors in a use case model, for example. It refers to information flow within the system being modeled, not linking two models together. – Thomas Owens Apr 22 '16 at 1:14
  • In my eyes it does. It even says there in the quote. Everything else wouldn't make much sense since it is redundant. You could use regular associations in your example. – kitty Apr 22 '16 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.