Just wondering what's the correct UML Diagram type to show Service Connection? Essentially saying that "Client A needs a function GetFoo that needs to return items whose quantity is bigger than 20" and "Client B needs a function GetFoo that returns all items"?
A Component Diagram looks correct, but already very concrete in terms of types and very vague in terms of single functions. Composite Structure maybe?
Eventually this is used during planning to decide which functions a service actually needs to have (e.g., an inner GetFoo and two outer GetHeavyFoo/GetAllFoo functions)
I think the composite structure diagram will work for you. However, in my opinion you should combine it with sequence or communication diagram or both - whichever works best for you. I also suggest you check all the uml diagrams and compare them and then decide which ones are best suited for you.
Component diagram is a good solution as well as Sequence.
If you are a beginner in UML you can also just create a class diagram and add a constraints on a method. It would do the job and be easy to understand by the developer team.
It used to be OCL in UML 1.X but now with UML2 direct access to the metamodel you can just create any constraints directly in the model without any transformation. I use EclipseUML Omondo and don't want to use OCL because too complex for a very limited return on investment. My workaround is also better because I can write whatever I want and directly put it inside my class diagram without having two different models (e.g. one for UML and one for OCL).
Related
I would like to to create a sequence diagram to show some interaction, and then use that sequence diagram as an interaction occurrence (sub-sequence) on other sequence diagrams. The point is I would like to apply the sub-sequence each time to a different object instance that is involved in the interaction in the sub-sequence. In my case the instances are simply various file artifacts. Is there any legitimate way of doing this prescribed by UML?
EDIT: some more clarification of my context:
I have 2 main sequence diagrams where I want to reuse the sub-sequence as an interaction occurrence
on the 1st main sequence there is one file for which the sub-sequence has to be applied 3 times
on the 2nd main sequence there are 3 different files for which the sub-sequence has to be applied 3 times
the files are read by the same object instance
I model reading from a file by a call arrow stereotyped as <<read>> to a on object instance which represents the file.
I need to reference the file somehow in the sub-sequence, but I haven't found a good and simple way of doing this.
Complicated, but formally (almost) correct solution with Collaborations
Just using InteractionUses is not enough, because this doesn't allow you to assign the actual roles in the main interaction to the generic roles of your used interaction.
Collaborations, CollaborationUses and Role Bindings can be used for this.
See my example here:
This defines a Collaboration with generic roles sender, relay and receiver and shows the interaction between them.
You can now use this collaboration in a concrete situation:
Class S uses the Collaboration two times with different role bindings to its parts (A, B and C are assumed to be able to send and receive Sig1).
With these definitions you can now create your main sequence diagram:
Unfortunately, this is not correct UML, even though there is an example in the specification (I filed an Issue https://issues.omg.org/browse/UMLR-768). You will have to fake this notation until the taskforce comes up with a fix. How to fake it, depends on how strict your tool implements the specification.
Advantage: formally correct and versatile solution, backed by an example in the specification
Disadvantage: complicated and difficult to explain, not completely usable, because of a bug in the specification
Basically there are three different ways to specify such situations.
Using a gate. Whith gates you specify the sequence with messages that start or end at a gate that is defined and in most tools (if usable at all) not shown explicitly. Instead it is modelled with messages starting or ending at the interaction border.
Similar as gates are lost and found messages. These are special messages that pass out the control to another sequence or returns from one. Such as in the case before you can define a set of further diagrams specifying the interaction in more details.
Using abstraction, which is my favorit for most of the cases. This means you extract the common interface from the classes and specify the interaction against the interface instead of the concrete classes.
Use an Interaction with Parameters:
Now we would like to reference the Lifelines of the main Interaction in the arguments of the InteractionUse. Unfortunately, in UML this is not possible, since arguments are ValueSpecifications and they cannot reference another modelelement.
However, NoMagic suggested and implemented an additional ValueSpecification, called ElementValue, that does exactly this. I think this would be a valuable addition to UML and hopefully it will be added some day. Up to then, only MagicDraw users can use this solution (as far as I know).
With this non standard element, we can model this:
The connection between the lifelines is now via the arguments for the parameters of the generic interaction. Technically the lifelines would not need to be explicitely covered by the Interaction Use, but I think that it makes sense to do it (shown in my tool with a non standard circle on the border of the Interaction Use).
Advantage:
compact and versatile solution, almost conformant to the standard
Disadvantage:
uses a non standard model element, currently only available to MagicDraw users.
pragmatic non conformant solution with covered lifelines:
The collaboration and parameter solutions allow to specify it (almost) formally correct. However, in many cases, a simplified model would be sufficient. In your case, for example, you only have two participants and they have different types. So, even though there is no formal connection between the lifelines of the used interaction, and those of the main interaction, there would be no ambiguity. You could use the covered attribute of the InteractionUse to specify, which of the lifelines (files) you are targeting at a specific InteractionUse. Could that be the pragmatic solution, you are looking for?
Advantage:
compact solution
Disadvantage:
not conformant to UML, ambiguous in more complicated situations
I have several use cases I have to represent in a UML class diagram. Apparently repeating classes is not encouraged, and several of my use cases reuse the same classes. I've one particular use case that reuses several classes I have already drawn up, without any unique new classes: does that mean I can leave that particular use case out?
Thank you.
Any diagram you create from a UML is an aspect of the whole model. To transport the whole picture you take many pictures from several aspects. Choosing the right number is an art as well as designing the model. A single diagram will in almost all cases not fit. So break them down and create e.g. a single or multiple diagrams per use case (one to highligh requirements, one for the actions, another one for the classes collaborating).
Further it is advisable to create a collaboration that realizes a use cases which holds and separates the realization of the requirements/descriptive part of a use case.
The core difficulty you have stems from an unclear understanding of the UML constructs and their interdependence.
A use case describes an interaction between an actor of the system to achieve a specific purpose. A class is a collection of system data and functions. Of course, different use cases make use of the same classes. Imagine a shop system. The class Product describing the products offered by the shop will be used by use cases like Show all products of a specific category, Show product details for a specific product, Order product, Generate bill for delivered product.
Fortunately, this repeated use of a class won't clutter your diagrams. In a use case diagram, you don't describe classes, and in a class diagram, you don't describe use cases.
A good approach comes from two directions. Use the input coming from your users to describe use cases: situations when they want to use the application, and the behavior they expect from it. Use your domain knowledge to describe data structures and operations to support these use cases, and describe these in a class model.
What is the best way to represent a "mixin" using UML?
As documented in this article:
In object-oriented programming languages, a mixin refers to a defined
amount of functionality which can be added to a class. An important
aspect of this is that it makes it possible to concentrate more on the
properties of a particular behaviour than on the inheritance
structures during development.
I will give more details about my particular use case.
I have a collection of classes that model different types of objects. Because all of them can be stored on a storage, I want to use a mixin to implement all the functionality related to "being stored".
Of course, I can use abstract classes but I do not like it because these classes should be part of a different hierarchy of classes and the fact that they can be stored is only a secondary property.
Another option can be to use composition and add the "storage node" as a field of this classes. I do not like this option either for the same reason: I do not want to create any dependency between the classes and the storage.
I have already implemented the solution in Java using a mixin based on dynamic proxies and I would like to document the solution with a clear UML class diagram. Is there a standard way to represent this mixin?
I am also wondering whether it is a good idea to model also how the mixin has been implemented (using proxies) or it is better to use a more abstract representation.
Thanks
Actually there are many ways to model this in UML:
One approach could be to stereotype the operations and properties with <<mixin>> or the like and then use tagged values to describe where you got them from.
Another (I'd prefer) is to actually use a <<mixin>> stereotyped Generalization and attach a note to that telling which operations/properties should be mixed. That would give the implementer a guide to just "lean implementation of the general class".
Eventually you could create <<mixin>> sub-classes with subsets of the ops/props you want to mix in the final class and then Generalize from those.
Probably one could come up with more solutions. Use an approach which suits you best. There is not generic mixin pattern in UML (to my knowledge).
Looking at below UML diagram (decorator pattern), what is the name of relationship between Decorator and component? Is it Association?
The two relationships between Component and Decorator constitute another pattern - Composite.
Decorator is a subtype of Component (rel with triangle)
Decorator aggregates (includes) many Components (rel with diamond)
It allows recursive tree structures to be created. Operations called on the aggregate Decorator are delegated to its contained elements. Hence, in your diagram, the behaviour of Decorator.Operation() is to call Component.Operation() on each of its aggregated Components. Since one or more of thpse could themselves be a Decorator, the call to Operation() propagates through the tree structure.
One is an extension the other one aggregation (that's the one with the small nob at Decorator).
Meaning that a Decorator can contain 0 or more Components.
hth
Mario
It's aggregation. Decorator has many Components.
Aggregation. Easiest way to see the difference is with "to be" and "to have".
An object Component "has a decorator". An object Decorator "is a component".
You are describing an aggregation.
The problem is that this diagram should be reversed from your code or you should get a code from your diagram. Just graphical UML designs are not enough for me.
When I use tools with no code mapping to UML then my modeling is sooner or later horrible !!
I create nice diagrams but except for presentation nobody really use them. I have realized that it was a waste of time for everybody in the team.
I have switched to a professional tool then my project was really used by the team and not only a graphical view used once during a story board.
What surprised me is developers have also corrected my diagrams because at implementation stage what was good in UML was impossible in the code :-)
This is why UML as standalone has no value for me if you use the class diagram. I did this mistake using open source graphical tool but will not do it again !!
extends relationship
Can anyone tell which UML diagram I should change if there is a slight change in the design of application.
The change is -> Earlier the application was using Active directory for authentication now I want to use the Membership provider instead.
I want to keep the change minimum in diagrams.
Thanks
Sounds like component diagrams or class diagrams. Check out the following topics and illustrations for VS 2010 Ultimate RC:
UML Component Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409390%28VS.100%29.aspx:
A component diagram shows the parts of a design for a software system. A component diagram helps you
visualize the high-level structure of the system and the service behavior that those pieces provide
and consume through interfaces.
UML Class Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409437%28VS.100%29.aspx
A UML class diagram describes the object and information structures used by your application, both
internally and in communication with its users. It describes the information without reference to any
particular implementation.
It will surely depend the diagrams at your disposal. Sound like a correction in one of the static diagram types, like the component diagram ...
This of course depends on how you structure your documents and your uml-diagrams.
In general I have a Conceptual model, Class Diagram and a Design Diagram which are diractly linked to the architecture. And then you should in most cases have System Sequence Diagrams and more. However, depending on how your structure is and to minimize the "changes" required.
I would suggest that you use something more generic for the parts that might be changed. Active Directory Authentication and Membership Provider Authentication is both Authentication methods, which means that you can, instead of displaying the whole sequence at the Authentication step, just use "Authentication".
Now, in the conceptual models and in the design + class diagrams, you will need to change and add some fields, tables or whatever is added. But it shouldn't matter if you need to add more or less, because the documents need to reflect upon your software as accurate as possible.
So, to minimize changes, use more generic types.