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.
Related
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.
hello, my first question is how I can place cases to better readability? I want to make this diagram fit on a A4-sized paper.
But I am aware that this diagram may be badly made, so I ask you to advice, maybe I should share on the smaller part?
You need to to connect a use case only to its primary actor. So eventually you have to create a common role where the UC is used by this common actor role. Then your specific actors inherit from this common one. Like in #Amir's example International Student inherits from Student.
I'd simply up-vote the latter example but it has <<include>>/<<extend>> which is no favorable with use case synthesis. Moreover it uses a generalization which is very bad practice with UCs since a UC represent an individual added value and inheritance from added value does not make sense (unlike in a class context).
I don't understood your language (In your use-cases). Generally most of time we have some common feature so You can use inheritance in UML diagram. For example if you have different kinds of students (or Actors) that have some common feature you can do something like below picture:
I think there is too many of use cases. I had the same problem. Try using CRUD - https://books.google.co.uk/books?id=gKHfVZn1CkgC&pg=PA367&lpg=PA367&dq=crud+use+cases&source=bl&ots=g7C2qnzunP&sig=F3OtpNWT29NFyqFvmO-MBtTG98k&hl=en&sa=X&ved=0ahUKEwjAmKifh9_OAhWpCsAKHV9pA344ChDoAQg4MAU#v=onepage&q&f=false
Also, you can divide your diagram into few use case diagrams for each actor. Or put all actors on the one side of the diagram and use cases on other. Hope this helps.
I completely agree with the given suggestions (CRUD, inheritance and responsibility by roles) and I additionally recommend not to try to create an overview about the whole universe. Instead, try to separate your use cases into groups based on similarities, differences etc. and explain your modeling on smaller pieces.
Avoid too complex structures and mutual/cyclic dependencies - they are almost always a sign of poor design. Remember, you have to implement and test every connection in your diagram somehow. Less connections, less effort, less errors.
I have seen many use case diagrams where a use case can be included to only 1 other use case, is this right or wrong? I have the understanding that in order for a use case to be included, it must be included to minimum 2 other use cases to be considered.
If this is true(minimum 2 use case to be considered an include), if its just linked to 1 other use case, do i just use a normal association? thank you
This is a recurring question and often interpreted the wrong way. Include does not mean "call" in a functional analysis sense. It means "this is a use case which can optionally be included". E.g. if you have a tool box you sell with different tool sets (different licensing for software). When you model use cases you synthesize single actions in a form so they build a set that returns some value to the actor. You will not divide pieces of value into smaller ones.
Use cases are about synthesis, not about analysis. When your use case diagrams start resembling spider webs then your design is broken.
i've been created the following diagram for forums system but i'm not sure if the relation between use cases and actors is correct.
so i want to know if my diagram is correct or if i've added too much complexity to my diagram. did i got my use cases relation with the actors correctly? well to better say, is it correct at all?
any help is really appreciated.
Not a bad effort for a first attempt, but I'd say it is a bit over complex. When you do analysis, using use cases or some other method, you really do want to keep it simple and avoid going into design mode, which is when you start thinking about relationships between things.
In my opinion, your actors should not be generalizations of one another. A "person who posts" on a forum is not a a more specific type of a "person who reads posts": they are different roles which the same person might take on at different times, not expansions on one another. So I'd advise you to drop those generalizations.
The same goes for the use cases themselves. Normally, use cases relate to one another by way of either the <<extend>> or <<include>> relationship, but generalizations or not normally used. Use cases aren't like classes and don't really have the option of being abstract, so the "manage" use cases need to make sense on their own, and they don't really do that. Your "concrete" use cases, on the other hand, make perfect sense.
In order to group related use cases together, it's a better idea to use separate diagrams and / or gather the use cases into packages called "post management", "site administration", etc. There is nothing which says you have to put all your use cases into a single diagram.
I support your method of use case diagrams. I struggled with this very issue a while back. To show each association from one use case to each of the actors was getting messy. By generalizing the actors, it consolidated the associations into a nice, easily readable format. Thus, the information is easier for others to consume.
I’m working on a USE CASE diagram but I’m having problems modeling the following:
A user wants to inquire his balance, but he can do it by phone, SMS or IVR. How should I represent the different ways? Each one has different flows. Should I model just one use case for each one, or should I represent the different ways as extended use case.
If the three cases share flow to a huge extent (say >70%) I would model them as one use case. Otherwise it would be better to model three different use cases.
The point here is understandability. Cramming three different things into one is confusing, repeating the same three times is confusing as well (although probably less).
There is no right or wrong answer to your question. UML allows the same situation to be modeled differently. It depends mainly on the level of abstraction you choose for your use case diagrams.
You'd have a common use case with 3 extensions. You'd then detail each extension with sequences diagrams.