I am working on a project where there are 2 actions that will happen at the same time (simultaneously: stream video via pi-camera and take measurements via sensors).
And I intend to draw the use case diagram of this project.
To my knowledge, the concept of parallelism does not exist in use case diagrams.
But just to make sure: Is it possible to draw synchronous use cases in a use case diagram?
A use case is defined from a users perspective. So if it is the same thing the user wants,it is the same use case. Further, use cases have no notion of execution, thus also no synchronous or asynchronous behavour. Thus this cannot be expressed by use cases intentionally.
As sim says, use cases have no notion of execution, so no notion of synchronous or asynchronous behavior.
However, it's not clear to me that you really need two separate use cases for these two actions in the first place. If they both always occur together, and never individually, they are really one use case, not two, and should be modeled as such.
If you have several other use cases that take sensor measurements, then it might make sense to have a use case for taking the measurements, and have all the other use cases include it (using the «include» stereotype). That would be the way to associate them.
Related
Little background
I'm new to writing use cases and representing their scenarios.
I'm dealing with a complex system. In the first step of analyzing the system, I created a use case diagram where each use case represents a distinct goal or value for the system. I have tried my best to keep the use cases independent. All these use cases require the initialization and activation of the system, so I decided to take out this common part and link it to the main use cases using include relationship.
I understand that include and extend relationships need to be used only when necessary.
Now I'm lookin into defining scenarios for each use case and then developing user stories and requirements based on scenarios.
Main issue
The use cases are very complex and the easiest way to analyze it seems to be mapping it into a sequence of steps/activities where each activity contains several scenarios and each scenario is represented using a sequence diagram.
I understand that an activity cannot be a use case which is related to the main use case using include relationship; but having sequence diagrams for activities seem wrong too.
What is the best way to represent a use case where each step of the main flow is complex and can have several interactions between actors and systems as well as having error scenarios which can result in termination of the sequence at that step or possibility of the user cancelling/aborting the sequence?
I have attached a simplified version of the activity diagram for "Initialize" use case.
As I mentioned, each activity can have many scenarios. For example
"Perform Self check" has many steps and each step might result in a failure that can terminate the sequence and alert the user (via a HMI). The user then can either terminate the initialization or retry.
"Validate system configuration" include steps for obtaining the reference config versions and comparing that to the system config, then download the new config files if necessary and then update the system configs. Each step might have a failure resulting in some sort of message to user and termination of the sequence. In some cases user should be able to skip the failed steps and proceed without doing that activity.
Same goes for every other activity in the diagram; many steps with exception or alternative paths.
Can I map these on one sequence diagram for the "Initialize" Use case?
My attempt to put all these on one sequence diagram failed.
I tried putting all these interactions on an activity diagram with swimlanes but things got so complex that stakeholders have a hard time understanding what is going on.
Maybe I'm trying to put too much details at the system level. Should I leave all these interim steps and interaction for the lower level of design? Should I create a hierarchy of use cases and roll down the complexity? I'm confused. :(
What is the best way to deal with such level of complexity? Could you provide some good examples.
The only way to represent a complex use case, where every step of the main flow can have multiple scenarios, is fortunately very simple:
The complexity of the scenarios does not change anything to the simplicity of the actor's goals. And if the goals are not sufficiently simple, you'd probably looking at too much details. Or the things are not as clear as they should.
The scenarios are often represented with a set of sequence diagrams. But if it gets really complex you'd better show the flow with an activity diagram.
By the way, you do not need to create an artificial extending or included use-case for the sake of modelling common steps. You may just create a separate activity diagram for the common part. Then, in each of your use-case activity diagram, you'd insert a call action of the common activity. This also avoids to misleadingly include the common part in the description of one UC and forget it for the others.
Last but not least, you also want to develop user-stories based on the use-case scenario. This is a mixed approach that requires some more thoughts:
user-stories are generally used without use-cases. Complex erquirements are described as an epic. The epic would then successfully be refine it into user-stories, that fit in an iteration;
it is possible to structure such user-stories according to stakeholder goals and tasks. THis approach is called user-story mapping. This is closer to the use-case, but there is no term to describe the higher-level goals.
use-case driven development is generally used without user-stories: the scenarios and activity directly lead to development without intermeriate user-stories.
Fortunately, the Use-Case 2.0 approach allows to combine both ways. Read the linked whitebook: it's short, it's free, it's written by the inventor of use-cases together with leading authors of use-case methodology; it offers a reegineered appraoch that allows agile developments, using use-case for the big picture and using use-case slices to break it down dynamically into units that can be developped in one iteration.
A complex use case can remain a single use case, but it may need multiple diagrams to specify its flows.
Your activity diagram (although not 100% UML compliant) gives a good overview of the flow of the use case. Keep this as the main diagram. I would decompose the complex steps in separate diagrams. To indicate that a step is decomposed in a separate diagram, you can display a rake symbol, as follows:
See UML 2.5.1 specification, section 16.3.4.1 for more information.
I have a question about uml and extend notation of use-case.
How I can extend all use case.
For example if I created a connection down use case that extend almost all use case, but I don't want to connect all with the notation on the use case diagram cause is very orrible to see. How can I do?
First of all: the importance of Use Cases
Modeling Use Case Diagrams (Use Case Modeling) is SO important step in Software Analysis and Use Case Modeling should be performed by professional Analysts:
All estimations (Time, Budget, Resources and etc.) are performed based an Use Cases.
In some Use Case Driven Methodologies, all subsequent steps are based on Use Cases.
and etc.
Secondly: Knowing Use Case Modeling Traps.
In Use Case Modeling there are some traps that we need to conside related to your question:
(Trap #1: Use cases that users don't understand.) (see reference 1)
Use cases are a way to represent user requirements, which describe
what the user needs to be able to do with the product. Use cases
should focus on tasks a user needs to accomplish with the help of the
system, so they should relate to the user's business processes.
Your users should be able to read and review use cases to find
possible problems, such as missing alternative flows or incorrectly
handled exceptions. If users cannot relate to use cases, there's a
problem. Perhaps they're written too much from a technical, rather
than business, perspective.
(Trap #4: Describing specific user interface elements and actions) (see reference 1)
Write "essential" use cases that describe the interactions between the
user and the system at an abstract level, without incorporating
user interface specifics. The use case description should not include
a screen design, although simple user interface prototypes can be
valuable to facilitate the use case exploration.
(2. Not having clear business goals for every use case) (see reference 2)
(6. Specifying use cases in too much detail) (see reference 2)
Thirdly: Use Case Modeling is in the Requirement phage of methodologies.
We should not put common implementation methods in Use Cases. Common methods in implementation handled by other diagrams in next steps of methodology. (maybe in Design Model) So, if we put all common methods in Use Case Model, the number of use cases increases a lot. (and our estimation as mentioned in first part goes wrong)
You can't - and it's nonsense. A use case shows added value for an actor. Extensions to use cases are very rare. In most cases people try to apply functional decomposition and mistake a step of actions recurring in multiple use cases as "partial" use cases. They aren't! If you are trying to do what you describe you went the wrong path. You should instead think why and where your use case synthesis broke.
I strongly recommend reading Bittner/Spence to get the right idea what use cases are all about.
You can use use inheritance.
Something like this, use cases B and C are extended since this is inherited.
But as #Kilian said, it would be interesting that you explain why you need a such model.
I am working on a use case diagram of a fully automated system. An external system will trigger just one use case of this system. Most of the other use cases are scheduled tasks and invoked by the timer. I have a use case that is invoked by the timer and it includes and extends two other use cases.
When I write the use case discriptions, who will be the actor for UC-2 and UC-3. Can a use case exists without an actor? I have seen lot of use case diagrams which has included or extended use cases without directly conneced to an actor. Please clarify this. Thanks in advance.
EDIT:
My system is connected with a DBMS. My system will analyse the database workload time to time and check whether any tuning can be done. That's all about my system. UC-1 is Analyse DBMS, UC-2 is Check Performance statistics and UC-3 is Tune the database. So timer is the one which invoke the use case. DBMS gets the benefit.Steps in Check Performance (UC-2) are repeated in another use case. That's why I put it as a separate use case. On the other hand Tune database(UC-3) will be performed only if there is a need for tuning after analyzing the database.
Officially this is correct. An included use case is a mandatory part of the including use case and an extending use case will optionally extend some use case. As #Ister notes in the comment, the actor for the included/extending use cases will be that of the main use case.
But, and this from my experience, you best avoid the use of those include/extend relations. In most cases, people tend to use them for functional decomposition which is plain wrong. A use case shall show an added value for its actor, not how a piece of functionality is used somewhere. In most cases a structuring of added value is not present and you can well show each bubble as a stand-alone use case or integrate it into the main use case. I recommend reading Bittner/Spence to get into matters.
Edit1: I just realize the sentence
trigger just one use case of this system
This rather sounds like you mix use cases with activities. It's not a piece of functionality. A use case is added value. There is a scenario (set) for a use case which has a trigger. But saying "a use case is triggered" sounds just wrong. You trigger the activities of a use case (where it starts getting technical). Most techies have difficulties making the cut and abstract to use cases. One more reason to read Bittner/Spence.
Edit2: In your comment you are talking about technical use cases. I admit that I had intensive discussions about this in the past. But you need to differentiate between technic and business. Your business use cases are Analyse DBMS, Check Performance, and Tune database. As such they are no UCs for a Timer but for some institution that cares about performance. The only UC for Timer is Trigger task (or something like that). There is a cut. The Timer does not care about business. It will happily trigger the shutdown of the system in the same way. It does not become a business actor only for that fact that it is technically used to start some business relevant process.
And not to forget: read Bittner/Spence. For me this book was an eye opener since I also had no idea about the intention of use cases.
It is likely that UC2 and UC3 are not really use cases but in fact steps/actions within the UC1. A good way to check to see whether you have real use cases is to ask your self if there is any actor (human, system or time etc.) that would have that use case as a complete goal. In other words would any actor initiate this use case. In addition to this - Occasionally you may have a use case that has no actor initiating. This should occur only in the case that there are multiple other use cases (i.e. at least 2)that will either include or extend that use case. In this case the use case is there for the purpose of facilitating reuse in your model and simplifying the model - in particular when you write your use case narrative. Don't go out of your way to create include and extend relationships always double check - if no actor is using the use case you are including or extending and no other use case is using it then you absolutely don't need it.
Use case is always a scenario executed by actor(s). In your situation primary actor is the system under discussion.
Technically you can introduce a timer as an actor who executes first UC-1 step, but better KISS. Just add a line before UC-1 steps via common convention:
Trigger: timer according to [Link to requirements about timer schedule].
If you have to write something beyond this line (for example timer checks conditions before triggering UC-1) then timer must become an actor.
Overall your use cases structure looks very valid for me, just don't forget to connect UC-1 to some higher goal anyhow. And please remove extends/includes as already mentioned.
I'm using PowerDesigner and I have a use case diagram with one actor and 28 use cases, I'm looking for the best way to represent it in one paper.
I tried the vertical center alignment of use cases, but it takes a lot of space.
Can I split them in two or three packages or something like that ?
I have a use case with one actor and 28 use cases
What do you mean by this? A use case "with" 28 use cases?
In UML it is not valid for a use case to "contain" other use cases. If you did it like this, simply convert the containing UC into a Package with the same name.
Are these 28 UC maybe included in the first one ("include" relationship)? If so, this already seems to be strange. We should know more in order to eventually fix this.
There are several ways you can visually simplify similar modelling situations. In general, you should not have more then 6-8 elements (UCs) in one diagram, simplicity reasons.
Make several diagrams and show only related use cases on each one, with corresponding (in this case always the same) actor
Are all use cases on the same level of abstraction? If not, consider restructuring them in terms of converting high-level ones into packages which would in turn contain corresponding low-level use cases
Are use cases maybe too atomic (too low-level)? If so, group several related ones in a higher-level use case. This would reduce the total of UCs
Do you have some relationships between them?
If you post your current diagram, we could probably help you further.
I'm starting to learn UML and I'm a little confused. I have the following use case diagram:
I'm asking this because I want to draw my diagrams correctly in order to anybody with correct knowledge of UML can understand and not just draw the diagrams in a way that just I understand.
Now for the reason I used Use Case Generalization here is why;
After reading the section 5.3 of the book UML 2 and the unified Process, I think that what I'm trying to do is use case generalization, specially after looking at the example in page 100. This example shows a use case called FindProduct that as stated in the page 101 is an abstract use case.
We read that
the FindBook use case is much more concrete. It specializes the more abstract parent to deal with specific type of product, books. If the parent use case has no flow of events or a flow of events that is incomplete, it is an abstract use case. Abstract use cases are quite common because you can use them for capturing behavior at the highest levels of abstraction. Because abstract use cases have a missing or incomplete flow of events, they can never be executed by the system
And that's what I'm trying to represent in my diagram. I have an abstract use case Turn ON and this use case is never going to be executed as it is. It needs child, or in this case, children to specialize it because the system is going to turn on by IR or by KNOB and never just turn ON, that's abstract.
So the thing here is that I'm not sure about the multiple generalization and If doing this is correct. Or shall I change for example the Turn with IR and Turn with KNOB use cases for Turn ON with IR and Turn ON with KNOW use cases and make these the children of Turn ON and add Turn OFF with IR and Turn OFF with KNOB use cases and make these the children of Turn OFF, and so on?
Thanks!!
About you question: the most common approach I have seen, is to have one activity diagram per use case.
A few points about your use case diagram:
1- I have never seen multiple specialization in use case diagrams. you may want to reconsider that. When use case A (child) specializes use case B (parent) it inherits all the preconditions, post-conditions, main flow and alternative flow steps. I can guess that this features are not the same for your parent use cases (for example turn volume up and turn on); therefore multiple specialization does not makes sense here, to say the least.
2- Use case generalization should be avoided unless it adds real value to your model. It is not very intuitive and makes your diagrams vague.
3- This use case diagram seems to have the tendency to view use cases as classes and generalization as inheritance; which is not correct.
4- You may want to reconsider the level of granularity of your use cases as well; turn on with IR/Knob and turn off with IR/Knob may all be integrated in one reasonable sized use case with some alternative flows. But this is a choice you make as a requirements engineer, anyone may do it differently.
I recommend you take a look at section 5.3 of UML 2 and the Unified Process book which is about use case generalization.
Suggestion:
Let's assume you want to keep separate use cases for turning on and off and focus on one use case (turning on):
1- If the steps for turning on with IR are totally different from turning on with knob, make the turn on use case abstract and do not write any spec (text) or draw any activity diagram for it. Then specialize two use cases called turn on with knob and turn on with IR which are concrete with separate specs and/or activity diagrams.
2- If the steps for turning on with IR are almost the same as turning on with knob except for one step where the user chooses IR or Knob; you could use alternative flows. In this case you can have only one use case with one spec and/or one activity diagram.
Do the same for other three use cases.