I'd like to represent a loop in a UML activity diagram. Here's my situation:
For each folder, I check each document within that folder
For each document I check its content:
If it's invalid (based on keyword searching), do action X and pass to next document.
When all document are verified, continue to the next folder.
Can anyone show me what this should look like?
There are 3 different notations that you can use.
As your loop is based on some elements (folders, documents) the most convenient way is to use Expansion Region (of iterative type).
Second option, that is a preferred choice when you have some guard based loop is a Loop Node.
The last possibility is to simply build correctly structured decision/merge structure.
The benefits of the first two are that they are compact and clear. It is also easy to have nested loops. Neither of this is true with the last option. Yet if you present your diagram to someone who is not familiar with UML (especially if you have no chance to explain a meaning of particular structure), the last approach usually is most widely recognized and understood.
Related
I want to create a very basic sequence diagram for the first iteration of my app. I have a database of exercises, and I have a use case for creating, another for editing, and another for deleting an exercise. They are all very simple, and use the same elements and actors, like User, DAO, and Database. What I want to do is to create a single SD, that begins with the user asking to create an exercise, followed by the user asking to edit that exercise, and then asking to delete it. My question is: is this considered correct in a sequence diagram? I don't want to create 3 SDs almost identical to one another, and this seems like a simple way to represent all the information, but I don't know if this is correct by UML standards. Thanks.
From a standards conformance point of view, there is nothing in the UML standard, that imposes a relationship between your use case models and sequence diagramme models. So, no matter how many use cases you want to reflect in a sequence diagramme, it would be neither "correct" nor "incorrect".
From a personal point of view : What you are asking about is a question of modeling style, not conformity. As long as the people who are reading your models understand them, you can do whatever you want. So, something like this would be perfectly fine :
For example, the user can perform action A, action B or action C in a tool. Whether they choose A, B or C, the order of these actions and how many times they are repeated is up to the user and the reason why they choose A,B or C and why they are chosen in a particular order isn't clear. Also any action can be repeated again after another action has been done by the user.
EDIT: A more concrete example would be the creation of an image. The user can draw a shape, choose a new shape, choose a new colour and save the image. While drawing these 4 actions can be performed intertwined in any random order and in any random quantity, only guided by the whims of the user.
There is also the choice of creating a new image from scratch or editing an existing image to create a new image.
Very simple solution to you question is below.
Please do not omit the guards after decision node if you don't want to have an undeterministic behaviour of your activity. Decision node offers a token to the first flow that have true guard whereas the order of evaluating of the guards is not defined.
When modelling anything using any notation, it is important to remember what the purpose of is in creating the model, and who is going to use it.
If you simply omit the guards on arcs, then the model has no information describing how the system behaves. It cannot guide another developer to create the software, it does not record the intent of the designer.
The user is outside the system boundary, so the decision as to what action to perform is elsewhere. The system behaviour should be modelled as a condition of its state, inputs or events - these are what the system can operate on, and what developers expect to find in the UML model to guide them.
The exact UML construct used will depend on how that choice is communicated across the system boundary - an activity diagram may well not be the best way of communicating that, or you might use multiple diagrams for each interaction
The software being modelled does not make an unconditional choice, and the information in the model should reflect that with enough detail to be useful to the next person viewing it.
Normally a loop node should help you to solve your problem. If the flag isTestedFirst, the loop node is a while-do loop.
However this is not the easiest node of activity diagram.
It has three part : the setup part, the test part which is test at each iteration and the body part.
Maybe this image extracted from sparx documentation may help you :
Hope this help and maybe someone else may provide more details.
Well, you just leave away the guard:
Now the path can take any way. However, since there is a choice, it's the user taking the action and choosing the path he likes.
Edit Thinking a bit about the "natural" control flow it seems obvious, that preceding the ConditionalNode you find an action like Offer choice (e.g. in the concrete example of the OP: "draw", "choose shape", "choose color", etc.). So the outcome of the ConditionalNode is one of the users choices which in turn should have an appropriate guard. So the above is merely a sketch and can be regarded as incomplete. However, presenting this sketch to a reader would either make him "aha" or ask the question that came up my mind after thinking a while. Regardless of this, there will be just one path been taken after the ConditionalNode.
What I am doing is get the marks of each and every student for a course, here I have created an explicit lifeline for students (the student list in the course object) and then even added a "get(indexValue)" method to show that it is iterated over to get each student.
The issue is that I wish to be a bit less detailed and more conceptual, how should I structure my diagram in order to show that there is looping over all the students in the course without explicitly defining it by using a studeentList lifeline and using a "get(indexValue)" method as seen in lists in Java.
Additionally is this representation correct if having a more detailed diagram was the objective as well. Also regarding breaking a loop I have used a return statement in a loop (as seen in programming languages), I have also seen some versions on the internet use "break" fragments to highlight this, is there a need to be specific for that either
You can put a loop box around the parts of the lifelines involved in the loop. In notes for the loop, you enter the continue/exit conditions. There are no "break" or "return" UML constructs. That is an implementation detail.
That said, if you want to get information for each student, I believe you'll have to use the studentList class to get info for each student in the loop. However, you can have one sequence diagram for how you handle each student and then the loop and the list are not necessary.
Remember that each sequence diagram has a precondition, a single scenario, and a post-condition. You can combine diagrams to show more complex behavior and decisions.
Can anyone tell me if I have to use the include dependency or the extends one?
Use_case A : Select and load a file
Use_case B : Show waveform
Whenever the user selects and loads an audio file, immediately a waveform is displayed.
I think that Use_case A and Use_case B should be connected by extends ....
am I right?
Thank you
I'd say include not extend.
Reason: Purpose from User's point of view is Display Waveform. Selecting and loading a file is a means towards that end, not an end in itself. It's difficult to see Select and Load file as ever having use on it's own: it doesn't represent valuable end-user functionality. It would only ever exist as a UC if a common step in more than one 'real' UCs.
hth.
In my opinion these two are not necessarily separate use cases. When identifying use cases, try to consider the viewpoint of the user. Showing the file to the user could be one step of the whole process of opening the file.
If you only have one file type and this is what always happens, one use case is good enough. If you have different file types that the user can select and load and every time something different happens, it could be a good idea to extract the first part to avoid repetition but it depends. In this case, use extend. (even this could be handled with alternative flows though)
A few points:
1- Please note that include and extend are not dependencies, dependency is another relationship in UML.
2- Good use cases are those that are UI independent. Focus on what the user wants to achieve. Do not make UI related decisions when writing use cases.
3- When "A" includes "B", "B" happens every time "A" happens. It is like an unconditional function call from "A" to "B". So "B" could always be part of "A". We separate "B" for re-usability and modularity.
4- Some pros recommend to avoid extend when possible. Having extends and includes does not necessarily imply professional UC diagrams. They could reduce readability and clarity.
suppose you have to do a Use Case Diagram for this simple problem (that is part of a much bigger exercise i am doing):
a registered user (of a web application) can search for tourist attractions in two ways: by category (for example: museums, parks, theaters, archaeological sites) or by location (city, county).
How should i model this UCD?
The most simple way would be: the actor (registered user), two use cases (search tourist attraction by category and search by location), the secondary actor (the server of the web application, which would process the query and send back the results).
My concern is that in this way the four categories and the two type of locations would not be present in the use case.
I was thinking of using the "extend" relationship. For example, i would add a use case named "Search parks" that extends the use case "Search by category". The extension point would be the event that the user chooses to search for parks.
Or i could use an inheritance relationship between the "Search by category" and "Search parks"...mmmm...i am a little confused...
How would you model this little problem using USD??
Thank you,
Luca
First of all you have to realize, that Use Case Diagrams aren't substitute for actual (written) Use Cases. Use Case descriptions contain many important details, which are omitted in Use Case diagrams. Use Case diagrams are good for depicting hierarchies of actors, associated use cases and relationships between use cases, but nothing more.
Another important thing is to realize what an use case actually is. Good way to think about them is to find a goal of an actor, which he/she wants to achieve with help from the system. Achieving this goal should give the actor some business value. My point is, that from what you described, registered user might want to search for a sightseeing and/or buy entry tickets. So this is his goal and this should be a an use case, don't confuse use cases with functionality/features like different ways of searching etc.
In your first suggestion you have two use cases, which differ only in data (e.g. it might be just different choice from a combo box in a form). Such differences, if they don't influence the way the system and actors interact, are described separately from the use cases in a data glossary, which you reference in your use case. This way you avoid many unnecessary details in use case descriptions. If on the other hand, the steps in the description change (e.g. when registečred user chooses location system gives him/her an option to select another registered user as a friend and pre-selects favourite locations of both or something like that...), you can capture this by using alternatives/extensions.
You mention the system you are developing as the secondary actor. Don't forget, the system under development is an implicit actor and is not shown diagrams as a separate actor. Use boundary box (rectangle encompassing use cases excluding actors) to depict scope of your system.
Finally to your concern. These are all just details about the data, which are not part of an use case. You can capture those details in text (by namicng all categories etc.) using the data glossary as mentioned above. If you think the structure and relations between data is important and needs to be captured using diagrams, you can use class diagrams to create data/domain models.
Last note about use case relationships - don't use them if you don't have to. They are often hard to understand and vaguely defined. Never ever use them to decompose the functionality, that is up to design, not analysis with use cases.
I hate depicting Search in a use case. There are simply too many variables. It's like trying to write a use case for using a browser.
Search is a good candidate for early prototyping supplemented with business rules.