Can I use directed named association on component diagram to show fact that "sys A" sends data to "sys B"?
Example:
No, you should use general purpose dependency instead, with optional title.
However, the title is not very common in this context. Better use some other diagrams (sequence for example) to show the communication details (e.g. open connection, send data, close connection, etc).
If there is a well defined interface between those systems, you can indicate that as well like this:
Association is used between two classes to show that their instances are potentially connected (again, not for data flow indication).
In UML 2.0 the concept behind association is vague, read this article: http://www.uml-diagrams.org/uml-core.html (search for "Semantic Relationship"). Association denotes a "semantic relationship" between two components, and I think it wouldn't be appropriate for data flow.
I think that even dependency isn't appropriate for data flows: maybe the client depends from the supplier, maybe the opposite is true... so the arrow can be very confusing.
The lollipop notation is the best, IMHO: it shows clearly that there is a component providing an interface, and another one requiring it. You can use stereotypes on the interface to show the type of communication/data transfer, and labels to make clear what data is transferred.
The book "Documenting Software Architectures" adopts another style, using prevalently associations: see p.145. It's similar to your initial proposal, but with explicit roles and without arrows. I think isn't a really satisfactory solution, without stereotypes...
If sys A sends information to sys B and you're not interested in how exactly the transmission takes place, then that is a classic application of the Information Flow connector.
A Dependency would in this case say that sys A needs (is dependent on) sys B for something. An Information Flow often (but not always) goes in the opposite direction of a Dependency, since it is typically the receiver that needs the sender.
There are many different ways of showing these types of relationships, and the best one depends on the situation. If your focus is on the type of information being transmitted, then Information Flow is the best fit. If your focus is on the way the transmission takes place, something with an Interface, possibly an Assembly, is better.
EA actually allows you to specify an Information Flow over an Assembly, so you could even combine the two. It's all down to what exactly you want to express.
Related
I am new to object oriented design and I wanted to do my first ever UML use case Diagram on a simple application which contains toolbar on the top left corner. The toolbar is called files and when the user clicks on it,a drop down menu is opened with options to open a slide,save slide,make new slide and exit the application.
My question is, am I doing it correct with Use-Case inheritance(Generalization) ?
This is my diagram.
I am sorry to disapoint you, but I have to tell you that this practice is just plain wrong:
From the point of view of the semantics, the use-case specialization means that Open presentation is a special form of Check file, and Save file as well, and that the actor could use them interchangeably and independently. But this cannot be what you mean: exiting a presentation is at best a sub-part of checking a file
From the point of view of the purpose, a use-case should represent a user goal. It's part of the problem space, i.e. what the user wants to achieve. It's not part of the solution space, i.e. how the user will achieve it. A toolbar is not a goal: it's a user-interface element.
From the engineering practice perspective, use-case should not be used for user-interface design. It's not my own statement, but that of Jacobson, Booch and Rumbaugh, the founding fathers of UML:
The problem is that the [use-case] descriptions often contain implicit decisions about user-interfaces. Later, when the user interface designers suggest suitable user-interfaces for the use-case , they may be limited by those decisions.
in The unified software development process, page 164
So in conclusion, it's a bad idea to start use-cases from the user-interface. It locks you into your own design and ignores the user experience. You should focus instead only on the user needs. THe same use-case could then be used whether you'll implement it using a GUI interface, a chatbot interface, or a a voice-based interface.
While drawing Use Case diagram, one thing you should focus on is, the actual meaning of it and the purpose of drawing it.
A Use Case refers to what the users in respect of their type are able to do in your System... Anything inside the boundary is what system is capable of doing or what it can provide as a service to its users.
While naming the use cases, you should only use verbs and actions, for example:
1- Login | 2- Submit a Request | 3- Update Profile Description
You should avoid any nouns in them.
There are several relationships that exist in a Use Case Diagram among use cases, and a relationship among actors and use cases of the system, And They are as follows:
Association: the only relationship that can exist between an actor and a use case; Which says the actor is initiator of this use case, or is the one who is caple of operating the use case.
In the example above, User is caple of loggin in and submitting a complaint.
Include: Use Cases can include one or more use cases. When a use case includes another use case, it means the included use case or use cases happen all the time and are part of the initial use case.
Paying fees is included, because user has to pay the fees in signing up process, it has to be done, and it's part of the baseline path of the scenario.
Extend: When a use case is not happening all the time, and is part of your alternative path ( Alternative path of the complete scnario for this use case ), the use case should be extended to the base use case.
Forget password is extended to Login use case, because it doesn't happen all the time, and it's part of a alternative path of Login scenario.
Generalization: When there exist several different ways that a use case can be performed and completed, we use generalization. The inheritent use cases should all be of the same type as the inherited use case.
Submitting a complaint can be done in several different ways, in this case, we need to seprate each use case and inherit from from the submit a complaint use case which includes paying fees, this shows that, paying fees is a part of every type of complaint which is submitted.
in uml - system sequence diagram, can the system ask input from the actor (see attached picture)
In my example, the scenario is: system is prompting a confirmation input from user and user is to enter in the input.
Wondering if this is the correct representation for it? I asked as usually I have done it the other way round, in which actor gives input to the system and system return the output based on input...
Preliminary remark
The practice of showing an actor in an interaction diagram is well accepted and quite common.
Nevertheless, in principle, an UML interaction diagram such as a sequence diagram, should show interactions between lifelines within an enclosing classifier:
The actor being external to your system, it’s not a part of any enclosing classifier in your system.
As a consequence, this is valid UML only if the scope of your model is larger than the IT system, i.e. you model the organisatiin that uses your IT system.
Moreover the message semantic is not clearly defined for human participants, which is exactly the issue behind your question
Be consistent
If you choose to go on with your modeling approach and consider the actor as any other classifier, then your actor instance should behave as any other object.
The flow of messages shows which object is the sender of the message and which object responds. You should consistently keep this logic, as you did in your diagram. It will be btw one of the rare place on your model where you can show that the system is at the origin of this specific interaction and not the user. (hint: don’t forget the execution specification on the lifeline: it’ll increase the readability)
If you would materialize the free-will of the actor by an arrow/message in the opposite direction, you would only increase the ambiguity further: this would give the impression that the actor is at the initiative of the message, and that the actor could send a completely different message instead. And I’m not sure that your system is designed for responding to arbitrary messages from the user.
Another alternative?
A less ambiguous alternative could be to show the interaction between a system core element and an element that represents the UI: the UI element acts as proxy for the user, but since it’s an object like any other, the interpretation of message flows is unambiguous.
This is one of the idea behind the ECB decomposition, the C being a use-case specific controller (so it links this interaction to the requirements) and the B being the UI boundary exposed to a specific kind of actors (without entering into UI details).
Short Answer: Yes
Of course, the context of this interaction cannot be the system, since the actor is outside of the system. However, it is allowed to not model the context and let the interaction be its own context. Or you could introduce a Context Class, that contains the Actor and the system. But these are only formal considerations.
More important is, whether it is useful to do this. I would say, it can be. Describing how an actor will interact with the system is one outcome of analysing the use cases. Many people will use text to describe this, but in complicated cases, UML behavior diagrams, like activity diagrams or sequence diagrams can be used.
I would reconsider using a synchroneous message here, though. Communication with a human actor is by nature asynchroneous. You never know, whether the message arrives, whether the actor understands it and whether the actor responds with the appropriate reply message.
PS: The reply message should show the name of the message it replys to, not some arbitrary text. If you want, you can show the return value after a colon (confirmationInput():Answer)
Confirmation is vague.
As a response to user input this part would be missing in your SD. Being incomplete would not be wrong. In that case you just describe that part which starts from the confirmation.
As part of some system activity (e.g. you have a control process which detects over-heating and asks the user to continue with a shut down or so) that part would not show the start of the use case being likely something like "Observe XY".
In any case using system as life line to the right seems pretty much pointless. One would be interested in which object of the system is asking for confirmation.
The question is always: what does the editor of the diagram want to tell someone else.
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
Edit:
Final outcome based on suggestion given by #qwerty_so
This is my use case diagram for View Repository in Source Code Management System.
This system is part of Project Management System.
The system is similar to GitHub, user can select project.
And it will display a list of repository for the project.
User can click a repository to view its details such as file tree and repository information.
Finally, user also can click the file in the tree to view its content.
Is my use of use case generalization correct?
Below use case is the previous version, I learnt that using use case diagram to model process is incorrect (Seidl et al., 2015, p. 37).
Seidl, M., Huemer, C., Kappel, G., & Scholz, M. (2015). UML # Classroom: An Introduction to Object-Oriented Modeling. Cham: Springer International Publishing.
Well, let me just ask a question: can you abstract added value? The only case where that is true is called franchise. So what you did is to introduce a new abstract bubble to connected three concrete use cases with your actor rather than connecting the concrete bubbles directly. What for? Where is the added value for "View repository"?
For the abstract actor it's similar. There is no need to make User abstract since it's already abstract. All actors denote roles, not real things. You can just leave that abstract keyword away and it would not change any semantics.
What often happens (and you are on that way) is that people start functional decomposition rather than synthesizing use cases. Use cases are about added value a system under consideration delivers to its actors. That's just it. Just present these added values. I know it's difficult for techies, but stick to that.
As always I recommend to read Bittner/Spence about use cases.
in my opinion, one use case is one scenario. since we have to make a scenario for every use case model drawn in the diagram, so one use case must have specific pre-condition and specific post-condition but only have one main or basic flow. Use case might have few alternative flows, that are illustrated in extends relationship. while include relationship is used to avoid repetition in several scenarios in main/basic flow of several use cases.
Is This use case is correct/proper according to UML? if not please give some input to improve it..
The ways we can look on it as the boundary value "Use Cases" can be described something as "Release Phase 1"?
Writer Module/Reader Module should be proper Ator?
alt text http://img190.imageshack.us/img190/6708/usecaseh.jpg
This diagram is telling me that there is something external to the system you are developing called a "Writer Module". The Writer needs three Use Cases, for example Initialization.
Similarly another actor needs Check Status and StackUp.
If that is what you intended to say, then this diagram works. Do you really mean it? Does only the Writer module Initialise the system? Or does the system initialise itself? Can the Reader check whether the system has been initialised, before it has been initialised? Is there another Use Case?
Small improvement: make the Use Case names match in their parts of speech. Initialisation is a "Thing", Check Status is an "Action". Perhaps Initialize System might be better? "Stack Up" not "StackUp", be consistent.
Normally the reason you group the use cases using a box is to show what system is helping meet or realize the use case. It is formally known as a system boundry ("The system you are building". Normally the systems, modules, etc that are actors are more black box, existing, or use only. If there are many new or modified systems this definition gets confusing.
The other comments are semantics of what you are showing, but are not sytax, still important.
Page 103 of Martin Fowler has a diagram and discription that uses the system boundry concept and system actors.
To pick on an example: this diagram says that Check Status is a scenario with two participants, a Writer and a Reader. Is that what you want to say?
Also, I don't remember seeing boxes around (sets of) Use Cases in general.
Use cases are meant to show how someone uses a system to get something of value. Actors always represent persons, in the sense of an independent being who has goals and is capable of seeking something of value.
Actors are represented in one of several ways, either directly by name, or by inclusion through a role, or by proxy in the form of an agent acting on behalf of a person or role (the "system" actor). Regardless of the form, the actor is always independent, and always capable of "acting" upon the system to achieve its own ends.
The diagram you have here is NOT a use case diagram. "Modules" are not independent, goal-seeking entities, they appear to be simply components of some system. They are not capable of "seeking" anything, they are just implementation details.
The diagram you are probably looking for is the Deployment diagram (if you want to model how specific components are wired together), the Activity diagram (if you want to model application logic), or the Class diagram (if you want to model the formal relationships between components).