3

I have two components A and B. I want the model to show that they both <<include>> and <<use>> the third component. Which picture is correct, the top or bottom one?

enter image description here

Gangnus
  • 24,044
  • 16
  • 90
  • 149
Marcel
  • 164
  • 1
  • 11
  • 2
    I really don't understand the close votes here. How can a question that poses two (!) concrete alternatives and asks which one is correct be "too broad" or "unclear"? – O. R. Mapper Sep 14 '15 at 12:08
  • @O.R.Mapper Well, you have 10k rep and still not learned that down-votes / close requests do not follow any rules but (best) that of the large number? Though I did not down vote I understand the "unclear" since the question IS unclear. – qwerty_so Sep 14 '15 at 18:56
  • @ThomasKilian: If you find the question to be unclear, please point out *what* in particular is unclear. Just claiming a question is unclear when the question is as straightforward as showing two UML diagrams and asking which one is the correct one doesn't exactly help to improve the question. Also, it seems to me that either the question is unclear, or it can be answered. Both at a time seem rather contradictory ;) – O. R. Mapper Sep 14 '15 at 19:10
  • @O.R.Mapper You have read my answer, haven't you? – qwerty_so Sep 14 '15 at 19:16
  • 1
    I consider the question clear and concrete. +1 – Gangnus Sep 14 '15 at 20:30
  • @Gangnus Then answer it. – qwerty_so Sep 14 '15 at 21:18
  • @ThomasKilian Done. A comment and a vote take less time, you see :-) – Gangnus Sep 14 '15 at 21:50
  • I came to the conclusion that the question is not formulated well in regards to include/use and so I now voted to close it. – qwerty_so Sep 15 '15 at 05:24
  • @ThomasKilian The author formulated what he wants. It is absolutely clear. I see the problem elsewhere - his wishes to have a component in two different components are in contradiction to the nature of components. It is very possible, that if he would tell us about the subjects of these components, we'll see that they should be not components, but collaborations or packages. ... But this cannot be the reason of closing the question. – Gangnus Sep 15 '15 at 06:44
  • @Gangnus As soon as this is being clarified in the question I'll take my closing vote back. But only then. – qwerty_so Sep 15 '15 at 07:49
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/89696/discussion-between-gangnus-and-thomas-kilian). – Gangnus Sep 15 '15 at 14:22
  • Ok. I retracted my closing vote. I don't want to be too picky since "which is the correct one" now does no longer make sense as the top shows the `include` and the bottom one shows the `use` correctly. The OP's intention was (if I guessed right) to know which one to use to show a possible outsourcing of `C` (comment in my answer: "What i want to show is that now both contain c. But when i outsource C into a Service only the Service contains C... "). Anyway let's leave it this way since your answer is fine anyway. – qwerty_so Sep 15 '15 at 16:33

1 Answers1

2

Often, when you have two possibilities in UML, both are correct. But not here. I am afraid, both are bad.

According to the current standard 2.5 :

A Usage is a Dependency in which one NamedElement requires another NamedElement (or set of NamedElements) for its full implementation or operation. The Usage does not specify how the client uses the supplier other than the fact that the supplier is used by the definition or implementation of the client.

So, in UML <<use>> means "must have for some use". And notice, it is absolutely independent on the containment/inclusion relationship. The object we are depending on can be even contained, for it is not said we need it for creation of the dependent object.

We can use a component that belong to anywhere. But in the including (top) diagram we can't show the usage. So, it won't pass.

As for the second sort of relationship, including, there are greater problems here.

The standard UML component diagram has no "include" stereotype. But it is allowed to use elements of other diagrams.

But the component is not a class, it is an object. So, your component C simply cannot belong to both A and B. The other diagram fails, too. And if you want to have two different objects/components based on the same class or package, absolutely different diagram appears.

correct comp diagram

So, either A or B has its own instance of C and uses this instance. It is clean, without peeking into the other component.

If you use the tool that has not that containment connection, use the "include" association from the use case diagram.

I have also a strong suspicion that you could need not Component, but some different diagram, for your wish to put one box into different ones is unnatural.

Gangnus
  • 24,044
  • 16
  • 90
  • 149