I have one use case "Transfer request" linked to two Actors (Analyst and Inspector). The scenario/exceptions/alternate flow are essentially the same, but for each actor the pre-conditions and post-conditions are different. The request has different states, and that final state and previous states differ depending on the actor that's calling the use case.
How can I resolve this issue efficiently?.
It sounds to me like your use case might be too abstract to be useful.
Sure, at a very high level of abstraction the steps might look the same, but if you have a different set of pre/post conditions, different states etc.. then maybe you should be using different use cases.
It could be something like "Transfer payment request" and "Transfer inspection request"
If indeed there is a similarity in steps of the execution then you can still, at the locical level, create an Abstract class "Request" that takes care of the common parts. The subclasses PaymentRequest and InspectionRequest can then take care of the particulars of their own context.
Just remember that use cases are primarily meant to agree on the requirements with the business. So for the sake of clarity it is often better to avoid all too abstract use cases.
You simply formulate those conditions as constraints in the pre-/postcondition. (It's simple like that.)
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.
[Original Title] : Does an actor need to point directly in use case diagram?
or can I do it like this?
in this Use Case Diagram, I want to say that actor can use any use case in the pointed group-of-use-case.
does this kind of thing allowed?
Edit #1
The reason why I ask this question, is because when I create this use case there's a lot of line intersecting each other that makes me confuse.
And there's a comment :
It would be better to split that into smaller diagrams
does it mean like this?
Edit #2
after reading comment :
A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject.
so I decided to change to this :
is this how a use case diagram should be?
Edit #3
CONCLUSION
An actor should point directly to use case
Read more the detail about how a Use Case Diagram should be in comment on this question
To be UML compliant you can not do that. But I guess one can understand what you are trying to communicate.
As a side note: Login is not a business use case. It is a constraint. Also with CRUD use cases I would not separate them but have a Maintain <object> instead (which itself is some borderline use case since maintaining something is not directly business relevant). You can constrain maintenance operations to certain actors separately.
Edit Regarding Login (one of my favorites): Use cases are most commonly used to describe business context (exactly as you are doing). So when looking from a business perspective, a Login is not a use case, but a simple constraint (you can do the business relevant things only when you are logged in).
Now for the Manage/Maintain use cases. They are on a similar level. Usually the "managing" itself is not directly business related. In many cases the focus on the real business was lost. So instead the reason why you manage something is the real use case (e.g. Correct User Data, Collect User Data). This is quite challenging and I confess that sometimes I also fall back to Manage. Most people don't bother but doing a good job requires to think over basics and not adopt bad habits.
UML Use Case Diagrams allow for two seemingly equivalent ways to show that a given use case might be realised in several different ways namely use case generalizations as opposed to use case extensions. I have seen the following basically example modelled using either approach with equal frequency, sometimes within a single source.
To my mind an extension is a weaker relationship than generalization as a direct substitution of the specialised use case for the base case must be possible in generalization but not necessarily in extensions.
It seems to me that generalisation implies a polymorphic implementation is desired while extension implies some branching structure is to be used.
void makePayment(const PaymentDetails* pd)
{
pd->pay();
}
as opposed to
void makePayment(const PaymentDetails* pd)
{
switch(pd->type)
{
case EFT:
payViaEFT(pd);
break;
case PAYPAL:
payViaPayPal(pd);
break;
case CREDITCARD:
payViaCreditCard(pd);
break;
}
}
Isn't the Use Case stage far too early for such implementation specific concerns to be modelled? There are much more appropriate UML diagrams for that. Is there a hard and fast rule regarding which of the two to use and if so what is it?
To my mind an extension is a weaker relationship than generalization
as a direct substitution of the specialised use case for the base case
must be possible in generalization but not necessarily in extensions.
That is true.
It seems to me that generalisation implies a polymorphic
implementation is desired while extension implies some branching
structure is to be used.
The diagram does not dictate any implementation.
You can interpret a hint from the diagram for yourself, though. UML remains independent of language and solution there.
Isn't the Use Case stage far too early for such implementation
specific concerns to be modelled?
Well, as indicated above, UML does not enforce any specific kind of implementation.
However, you are gathering some important functional requirements here that might greatly influence your time schedule and workload. ("Pay with credit card" is way more complex to handle than "pay in advance by bank transfer"). So you'd strive to capture that but remain open to different solution approaches.
There are much more appropriate UML
diagrams for that.
You can really use them in parallel :) as they are different views on the same subject.
Is there a hard and fast rule regarding which of
the two to use and if so what is it?
I prefer the generalization in this case because the extensions falsely suggest there could be a way of paying without using any of the three named options. As you indicated yourself.
Addendum (as per comments): The high-level purpose of the example diagram is to outline the foreseen payment means. A payment needs at least one means (unless payment is cancelled), just like "print" is too vague without clarifications such as "what" and "where". Hence my preference for using the generalization, despite "make payment" being a valid use case in itself.
When modelling with an extend relationship, the extending use case (pay via xxx) is executed when the extended use case (make payment) is at a precise location (given by the extension point, payment type) if the condition for such extend relationship holds (e.g. for "Pay via Paypal", the condition would be payment_type=PAYPAL). In this model, "Pay via Paypal" does only deals with the details of completing a payment transaction with Paypal, while "Make Payment" specifies all the behaviors that are independent of the payment method (such as computing the total amount, and saving the result of the transaction once that it was performed).
On the other hand, generalization (which is defined not only for use cases, but also for any classifier) is a broader concept, since it do not detail (at the diagram level) the details of when and how the specialized behaviors are executed. If "Pay via Paypal" were a specialization of "Make Payment" it would redefine the behavior of "Make Payment", which could be substantially different from the behavior of "Pay via credit card".
Being an extending use case does not means that the alternatives have to be hardcoded. Indeed, your first example is also a valid implementation of a extend relationship, since pd->pay(pd) will invoke different behaviors depending on the selected payment type. Actually, use case diagram models what a system is supposed to do, while low-level implementation details are better specified in activity diagrams.
An example of an extension would be a "Discount Payment" use case. Discounting a payment has to do with making a payment, but you don't have to discount a payment in order to make the payment.
You can look at the "is a" relationship to make the determination of which to use. Pay by PayPal "is a" make payment, a specific way of making a payment. Discounting a payment isn't. It's something additional you can do while making a payment.
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.