I have a web page with a graph made up of many nodes inside. The user can obviously view the graph (use case: preview the graph). It can also filter the nodes of the graph based on the argument and the difficulty and in that case the graph updates itself highlighting the nodes of interest (use case: filter nodes).
My problem is: does it make sense to insert an «include» like the one in the figure? I think so, since when the graph is updated the user displays the preview of the graph that has been updated again.
EDIT: This is the graph; on the right there is the FILTER panel to be able to filter by difficulty and topic.
UML semantics
«include» means that a use-case is ALWAYS included in another.
We therefore understand from your diagram that Preview graph is an independent set of behaviors but that it can also be included in Filter node. In consequence filtering always implies previewing.
It's formally correct and the meaning seems to match your narrative. Moreover it highlights the reuse of set of behaviors.
Use-case logic
However, use-cases are in principle user goals, not features or functions that are decomposed in more an more details. And your narrative seems to describe features and user-interface much more than goals.
Moreover, an «include» does not represent a sequence. If Filter node includes Preview graph this does not mean that filtering leads to previewing, nor event that filtering happens before previewing.
Take a User perspective
While we could argue that previewing or filtering could be user goals, it is clear that previewing is not a subgoal of filtering.
So what is the real goal for the user here? Could it be to Navigate in the graph? How it is done, is user-interface detail: do we just browse through a picture? do we offer filtering to facilitate the navigation? do we use coloring to highlight some parts ? do we zoom-in to see more? All these are (interesting) features but not independent use-cases.
Edit after your edit
Your screenshot reinfocres what I said before: filtering is just a mean to navigate more easily in the preview. I'd recommend not to consider it as a use-case.
If despite my advice you want to show the filtering on your diagram, then you should use <> to show that the filtering behavior may enrich the navigation behavior:
<<extend>>
actor --------- Previsualize/Navigate graph <-------------- Filter interests
Related
I am to create a UseCase diagram for an existing web program. Unfortunately I am very unsure about UseCase, I like to mix it with other UMLs.
For this purpose, I have picked out the order page.
There are 3 different users, the admin, driver and customer.
The admin can view all orders and has the ability to create a new order.
The driver can see his own orders, as well as orders he can accept.
The customer can see his own orders, as well as place a new order.
There is a possibility to choose between the standard view (row view) and a widget view of the meta information of the order.
Last but not least, there is the possibility to click on one of the orders and a single order overview will open.
Based on this I have now created a UseCase diagram, my first question would be: Is this all correct, with the informations i gave?
Will this then become a huge UseCase diagram? Or should this rather be done page by page for web applications? For example, if this is the order overview and I now have the use case that I change the page (In this case, when I go to the single order overview). And is there a way to make this look cleaner? All these extends/includes on 1 place looks confusing.
I'm afraid I don't know if I'm doing this only partially right, or completely missing the point.
What you need to remember is that Use Cases are about added value and not about technical realization. That's really hard for tech people and that's why they always start functional decomposition. So looking at the above, the only use case is Show Order and nothing else.
Login is no use case from that perspective. It is just a constraint you apply to certain use cases.
You just have focused on the Show aspect but likely there's also add/edit/delete. Such CRUD can be dealed with in variuous ways and there's no general rule. There might be a Manage and a Show or what ever combination along with constraints.
Basically, when your UC diagram resembles a spider web your design is likely broken.
I’m trying to prepare UML model for my project. It’s quite complex however I focus on one of use-case. In short term, use case name is “Edit patient results” and actor “Doctor” uses it. In fact, entering results triggers always the set of following actions:
List item
Normal Ranges calculation
Related Expression calculation
Interpretation merging
Assuming that I have my use-case diagram prepared as follows:
My questions are:
How shall I draw actions that are triggered automatically? As extended use-cases like this?
How shall I draw “Edit patient results” use-case realization? Each edit operation involves several software components interactions, shall I use collaboration diagrams? (how to join my main use-case with them), maybe something else?
How to draw sequence diagrams to show actions sequence and parameters passed? How to join these diagrams with my use-case.
What is the best way to show use-case realization
I'm using Enterprice Architect.
Thank You !!!
No. These are just activities which are part of scenarios inside the use case. Trying to make the use cases is functional analysis the wrong way. A use case synthesizes a number of steps under a common goal/added value.
A use case realization is a collaboration (bubble with dashed line border; along with the UC in the toolbox). The collaboration contains diagrams which show how the single classes communicate/collaborate to realize (parts of) the use case. Use a Realization from Collaboration to Use Case.
Put the SDs inside the collaboration and group/name them reasonably.
see above
As to your comments:
Edited 2.
I never found a good use for Collaboration Use and I've done a lot of successful UC modeling. So you can probably live without it as well.
Put Actions inside an Activity representing a scenario and connect them as desired. You might look into BPMN as well.
Should activity diagram include detailed information about how the system functions from the start of the application?
Say for example i am making a swing application in which the app loads a JList with images when the application opens, so should i specify that in activity diagram even though user isn't himself performing the task of loading the images in the JList.
Also should swimlanes in activity diagram be divided according to the possible classes my swing application might have.
For example having 1 swimlane for model, view and controller each in a simple swing application.
Below are the Image's that I made,
OR
I feel that even though the first image is correct,the second one helps me visualize how the class diagram is going to shape up in a much better way.
So should I use the second Image?
As always, the answer is "it depends." The level of detail is not dictated by the type of diagram, but the context in which the diagram is used.
If the diagram is intended to show the flow through a use case, it should probably restrict itself to showing the activities performed by the actor(s) and the system as a whole, rather than the parts of the system.
If on the other hand the activity diagram shows the flow through a use case realization, it should definitely show the different parts of the system.
Let's say that halfway through the project you decide to change the design and not use MVC. This means the diagram needs to be redrawn. If the diagram is part of a use case realization, that's to be expected (because that's what you've done, you've decided to realize the use case in a different way). But a diagram that's part of the use case itself shouldn't need to be redrawn just because you've changed the design; the flow of interactions between the actor(s) and the system-as-a-whole shouldn't change.
That said, MVC is such a well-known way of breaking down a user interaction that it may be permissible to go to that level of detail even in a use case. So, assuming that you're documenting a use case and not a realization, if in your project or company user interactions are always designed as MVC, then I say go right ahead -- but keep it strict and use "model" rather than "image service". If the decision to use an MVC design cannot be taken during the use case analysis phase, I'd advise against it.
Swim-lanes have absolutely no model meaning. They are just a line. I recommend to use pools/lanes which are (BPMN stereotyped) UML elements. They are classified accordingly (usually with an actor) and the single actions go into each of those. This gives the activity a clear structure and it also shows responsibilities.
I came across a situation where a use case has two options to choose from.
Example: Use case "Process data" has options like "Approve" and "Decline"
If approve, update the inventory.
If decline, file the information.
I know how to represent this in an Activity Diagram but I have no idea of showing it in Use case diagrams.
There are two choices here.
A) You make two use cases instead of one. Approve Data and Decline Data
B) You make one use case Process data. In the main scenario you describe the steps for Approve Data and in the exception or alternate scenario you describe the steps for Decline Data. In this case the difference is not visible on the use case diagram, but that is OK. Use case diagrams are meant to give you an overview of the big chunks of behavior in your application, not of the details.
The choice for alternate or exception scenario depends on your post-condition(s). If the Declinescenario meets the post-condition then it is an alternate, else it is an exception scenario.
The term Data is not very specific. I would prefer something more meaningful then data like Order, Application,...
I can't know for sure without knowing all the details, but option B) is probably the best.
A usecase has a specific goal for a specific actor.
Identify the Actor for the usecase(s).
Identify the Goal of the Actor.
Define the usecase with a strong specific verb, process is weak unspecific verb.
I find the requirements ambiguous, it seems you may be conflating two separate Actors.
See the Uml Style Guide : Usecase
You create two views of the same usecase. In the first view you create Process data with Approve and a second one with Decline. Each view is a different usecase diagram but using the same usecase.
It is important to make a clear differentiation between graphical views and model view. I mean that graphical usecase diagrams should be a view which is extracted from the UML model.
if not then use this link http://msdn.microsoft.com/en-us/library/dd409427.aspx
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.