New answers tagged

0

You show in your UML diagram as much detail as you need. Do you need inheritance or dependency relationships? If you do, you add them. I will not tell you that must omit things either. However, adding stuff you do not need is not required, and usually counterproductive. In UML, diagrams are additive. For example, if you have the same class in multiple ...


0

With reagrd to the life cycle of the objects, you can regard the composition as a "lives at most as long as the containing object" whereas aggregations are more like "lives as a shared resource and is not owned by a specific instance." This is helpful if resources must be released explcitly, for example where you have to delete or Dispose() the objects and ...


3

In your design, a WirelessNetwork can have one or more WirelessRepeater, and the WirelessRepeater is itself a WirelessNetwork. There is no UML issue here, except that your diagram would be easier to read if you would keep the inheritance and the composition graphically distinct (e.g. 2 parallel lines). The consequence of your design is that the ...


0

This is redundant. When you inherit you construct your parent anyway. If you also compose yourself of that parent you just end up with a second instance of your parent. Inheritance gives you an instance of your parent, their interface, and the wiring between them for free. Composition (and delegation) gives you all the same stuff but costs you extra ...


0

Your first UML model says that a complex number is composed of 2 doubles. This is definitively an acceptable way to it. Your second UML model does not represent the corresponding code: you don't show inheritance but a navigable association, and you forget to tell about the additional member. The following would more accurately represent the code: ...


2

The connector you are referring to is a package merge. P. 276 of UML 2.5: A package merge defines how the contents of one package are extended by the contents of another package. The rules behind that are detailed (in length) in UML 2.5 p. 240. The circle-plus notation is an alternate to the dashed open triangle (dependency) relation with <<merge&...


3

There is a lot of confusion about the terms, not all definitions you may find will align. Containment means the containing object does not directly expose the contained object. It exposes its own interface and may call on the contained object on behalf of the client. So there is no way for the client to mess with the contained object. The containing object ...


0

To add to the discussion above, you need to be clear whether you need a "merge" node or a "join" node. Every path through the activity diagram follows a token flow. if A and B are inputs and C is an output: Merge Node: every time an input appears on A or on B an output token will be generated on C. That is, neither input waits for the others. Join Node:...


1

The question is tricky, because an or-gate processes two concurrent input signals to produce one output signal. But in the activity diagram you manage control or object flows: the semantic is different. So the answer depends a little bit of what you try to represent: Option 1: the sequential or If you mean to say that some flow A or some flow B could ...


2

Your diagram corresponds to an abstract factory according to the GoF. In the original GoF, the diagrams did not use UML but a slightly modified version of Rumbaugh's OMT, which did not make difference between class inheritance and interface realization. From an UML point of view, the dotted arrow already represents the interface realization. There is no ...


4

The issue that you have is that you merge the concept of user and the concept of role. So if the same person is head of procurement in several tasks, that person would have several unrelated objects. A first step forward would be to use sound separation of concerns, for example as follows: As you see, I renamed your initial "User" into "Contributor" to ...


3

The second diagram may represent an abstract factory. However you shall not see it as a reference diagram for this pattern: According to GoF, the AF client uses the factory. It does not tell more. In your second diagram the client is associated to the factory. This allows its use (compliant to GoF) but is much stronger (so all GoF factories do not match ...


3

It's the same pattern, and the two diagrams are practically the same, it's just that some of the details of how the pattern is actually used are somewhat obscured, and this makes them look superficially different. The dashed arrows represent a generalized dependency - meaning that one type somehow depends on the other, but it doesn't necessarily imply that ...


2

Issues in your diagram You use the ECB pattern with «entity», «control», «boundary». This approach is meant to map classes to a use-case: «control» would be a use-case, so a user goal. But CLientApplication does not represent a goal at all: it represents a component. «entity» would be the domain objects (in general persistent). This would be ok for ...


3

1. Multiple associations: It is normal that the actor Member has association with several use-cases. However each association is usually shown as a straight direct line since associations are binary. The "multiplexing" of a part of the line looks confusing IMHO. It is also normal that several actors are associated with the same use-case: it means that ...


2

Both diagrams express different things: the qualified association expresses more accurately a complex association. The qualifier has a value semantic: it is made of one or several properties that allow to select the relevant association instances. Everything told about the qualified association is true but only if taking into account the qualifier. For ...


0

The difference depends on the level of abstraction you are aiming for in your model. In the first the association is qualified (named) without providing details of what the association is. If the details of the attribute in your class which will hold the association object (or a reference to it) is not important then go for this approach. In the second you ...


1

In short Your diagram is interestingly confusing. If you want to model the user interface scenarios, better go for some annotated wireframe scenarios. These are more expressive for that. More arguments Left side of the diagram The first question is whether or not put the user (i.e. the actor) in the sequence diagram: In reality the actor does not ...


3

There are a few things "wrong" with the diagram, but nothing major. It is mostly that you have used elements with a particular meaning in UML where that meaning does not match with what you want to express. As a sketch on a whiteboard with some verbal explanation, your diagram will do fine. If you want to use it in a document, where you may not be around to ...


Top 50 recent answers are included