I want to make a sequence diagram of below scenario
User clicks 'Pay' button
X asks for card payment details.
Use enters card number, expiry date ect
(...)
X sends a request to the bank for payment authorization.
How can I name the object X, other than the system, because a system is in fact a whole in which a sequence diagram happens?
For school purposes, is it correct to assume in the scenario that the system I am creating asks for card details (i.e. stores them) and sends a request to the bank for authorization?
Not really. What you call system is actually an instance of a certain class dealing with the authorization. If there were only one class to handle it all you probably would not need any (UML) design at all. The X would probably be an instance of Authorization.
Related
I have a flow of events and alternative events for a Login use case.
Basic Flow:
The actor enters his/her name and password.
The system validates the entered name and password and logs the actor into the system.
Alternative Flows:
Invalid Name/Password: If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends.
I come up with this diagram:
I was said that there is no need for an intermediate Login Screen life line. How should I design the diagram now, according to conditions given above?
This diagram is not bad. It is however somewhat confusing, because:
Login is not really a use-case, even if it's a popular practice. This has however no impact on your SD diagram itself.
Showing actors in a sequence diagram is not formally correct, even if it's a popular practice.
Login Screen is in fact a part of System, which creates a kind of implicit redundancy.
Don't worry about too much about the two first points, if this is the kind of practices that your teacher showed you.
The last point could easily be addressed:
The last lifeline could be more specific about the internals (example here), or,
Keep only two lifelines, one for the actor and one for the system. THis is in my view the better alternative when you use actors in a SD.
I want to clarify one scenario in use-case diagram which involve in payment. There are 2 way of doing a payment.
Using card
Using mobile number
Here want to clarify about the second one. To do a mobile base payment first user need to add the mobile number when user try to do a payment in payment page. I put that as a extend relationship. Please tell me is this correct.
Formally, this is not correct. Use-cases could be associated with actors but not with other use-cases: the relationship between two use-cases may be «extend», or «include» or specialization. In consequence, Add mobile number and mobile can't be associated the ay you have diagrammed it.
Depending on what you mean, you may correct your diagram:
by showing that mobile includes Add mobile number (dashed line with arrow), if you mean that every time mobile is executed, add mobile number would also be executed.
by showing that Add mobile number extends mobile (dashed line with arrow), if you mean that in some cases where mobile is executed, add mobile number could need to be executed as well.
Other notation improvement coulb be to get rid of the arrows for associations wetween actors and use-cases. This is an obsolete notation.
Beyond these purely formal remarks, it's important to realize that use-cases should represent goals of value for users. While we would certainly agree that payment is a goal for the user, and we could certainly understand your desire to add extensions for different payment means, we would certainly not agree on the fact that Add mobile number is a goal for the user. It's either functional decomposition or user-interface details, both aspects that should in principle not be documented in a UC diagram.
I am trying to design a use case diagram for the following scenario.
I have a society that is distributing goods to clients based on their orders. These clients can be administrations, companies, or private individuals.
Depending on what the client is I want to know more or less of their info (name, number etc)
The use cases are different depending on whether the client is:
English
English and have used this service for more than 3 years
Foreign
For example:
The 1) English clients' orders are accepted only if they pay a small fee in advance.
The 2) English clients that have used the service for 3 years don't have to pay this fee but need to get approbation from a different actor (an Agent in this case)
The 3) Foreign clients' orders are always accepted no matter what.
This right here is where I run into trouble and need help with.
The orders from nglish clients that have a criminal record are always denied UNLESS they are an administration.
What are the most optimal actor choices here? I thought of going with English client, and Foreign clients but I don't know how to include the "Unless the client is an administration" in the use case.
The use case diagram is not the right place to put this information. As correctly pointed out by #Christophe, a use-case represents a goal for a user who is going to interact with the system to achieve the goal.
This means that there is only one single use case in your scenario: "Order Goods". However, it has a set of preconditions. You could list them as structured plain text. Since there is quite some complexity behind each of them, I recommend to put them into a separate decision chart. Then you have a nice clean separation of the diagram scopes, and they remain easily readable.
Sidenote: There could be a second one "distribute ordered goods" executed by a 2nd actor who is an employee who does fulfillment / routing / dispatching.
Actors in UML use-cases are classifiers. To decide about which actors to create requires to understand the actors their goals and behaviours and how they differ in the interaction with the system.
First of all, you need to clarify the super-ambiguous requirements:
"English client": is this a client with English nationality? Is it a client that lives permanently in the UK? Is this a client with an address in the UK? Is it a client with a +44 phone number?
"Foreign client": same kind of questions + can you define for sure the difference between Ensglish and Foreign? For example: what with bi-nationals? what with people having two addresses one being abroad?
"Using this service more than three years": what with a foreign customer who uses the service for 3 years and then settles in the UK?
Since you deliver goods, you might also need to consider a delivery address. What with an English client ordering on a foreign address or vis-versa ?
"criminal record": the criminal record might change over time: is it provided at each purchase? or is it part of the customer registration process ? In the latter case, is there a need to periodically renew this information ?
Use-cases should in principle be goal oriented. So a use-case represents a goal for a user who is going to interact with the system to achieve the goal. Use-cases are not meant to describe the detailed sequence of your process (if client is this, do that, etc...) and neither are actors meant for that purpose.
You should therefore consider reformulating the use-cases to represent how the actors would perceive them. If needed you may consider the status of the actor that could explain that an actor behaves very differently. Typically in your case, I could imagine :
New client: a new client may want to provide details (address, identification) or evidence that they are entitled to buy (criminal record - I suppose your activity is regulated if you request such details)
Public administration: behavior of administration in purchase is anyway different because of public procurement and legal constraints.
Privately owned company: behavior is different since it can involve several persons,
Private individual
The need to pay an advance fee seem to depend on the address, nationality, history. It's more related to the process (it's a part of it) than an independent goal for an actor. So I would neither show this as a use-case nor make different actors for this purpose.
The reason to deny an order is not something that is not relevant for the customer (no customer has a goal go get a purchase denied!). It's relevant to you and your system and is a consequence of the registration process. So no need to have a dedicated actor for that.
I'm trying to figure out how to specify an extending use case.
For example, suppose I have a use case Pay described in the normal flow by the point:
1. User select the product
2. User make the payment
3. System validates the payment
This flow is included in a specification table (that include actors, pre-condition, post-condition etc..)
Now I want to refer this user case in the specification of an extending use case like PayWithCreditCard without repeating all equal step; How can I do this?
In this case the only step I need to extend is step 2. and it is extended in someway like:
2.1 User choose payament with credit card
2.2 User insert credit card
2.3 User insert Pin
But how can I put this in a specification without to repeat step 1 and step 3?
Or there is another way to handle with this?
If use-case PayWithCreditCard extends use-case Pay, then Pay should identify explicitly extension-points where the extension will insert its behavior.
This is also (or especially ?) true for the tabular specification of a use-case: the specification shall list potential extension points and identify these in the flow of events. For example Spence & Bittner suggest to use curly brackets to identify the extension points (see their book Use-Case modelling, chapter 7).
In your case, this would look like this:
Use-Case: Pay
Actors: Buyer
Extension-points: Provide payment details
Validate payment
Basic flow:
1. Buyer selects the product
2. Buyer makes payment
2.1. Buyer selects the payment method
2.2. { Provide payment details }
3. System validates payment
3.1. { Validate payment }
3.2. Inform buyer that the payment was accepted
Pre-conditions: ...
The extension points would be defined in the extension. Dependeing on the selected payment method, the { validate payment } extension point could for example trigger an immediate credit card transaction with the bank, or wait for a delayed manual confirmation by an accountant that the incoming wire transfer was received.
For identifying the alternate flows, you could then use:
At { Validate payment }, if rejection or time-out: ....
It is important to be aware that an extension use-case, may need to know about the extension points of the use-case that it extends. This is different from an include relation, where the included UC is understood to be independent of the use-case that includes it.
Basically a use case shall only show added value a system under consideration delivers to one of its actors. Often people tend to start functional decomposition by misusing extends/includes. However, sometimes it's kind of useful to show variations like here when adding different payment methods that extend the payment procedure.
First of all "Pay" is no use case (it's verb only). Even "Pay product" is not a use case. I doubt the actor will see that as added value - it's more the opposite. The use case (I'd guess) is rather "Purchase product" which is a big difference. The actor wants to have the product and it's obvious that something in exchange is needed to get the product (in almost all cases that would simply be money). Now that you have this use case you want to show options (!) which you put into bubbles. These are basically no use cases per se. They just extend an existing use case. "Pay per credit card" and "Pay cash" are such extensions. (Unfortunately UML does not make a difference in the graphics for real and such pseudo use cases.)
Now, in your textual description you would have a decision at the point where you make the payment and where you would branch accordingly. Eg.
Select payment method
2.1 If credit card: Perform use case "Pay with credit card"
2.2 Else if cash: Perfom use case "Pay with cash"
Handling exceptions proves to be tricky here (in graphical as well as textual notation). So you might need to continue
If payment refused resume at ...
or the like.
A UC diagram would look like
I am trying to make a use case diagram with the help of my class diagram but the problem is i am here confused that what should i take as actors and what will come and what attributes shall i take and where to use <<extend>> ?
Kindly help. Thank you in advance.
As Thomas pointed out, there is no algorithmic way to go from a class design to a use case. In fact, for a given class diagram, it's not even granted that there is a use case at all (for example, if the classes represent only the relation between business objects and no actors).
However, by analyzing your specific diagram from a human point of view, you can very well infer a class diagram:
1) Identify candidate actors
An actor specifies a role played by a user or any other system that interacts with the subject. Candidates in your diagram are: visitor, admin, and registered user
The classes Movie, Book tickets, Make payment are obviously not representing roles of a user.
2) Identify candidate use cases
A use case defines the interactions of a system and an actor in order to achieve some goal. So let's brainstorm a little bit to find everything that looks like an interaction:
Very explicit candidate use cases: Book tickets (class and method of Registered user), Make payment (class and method of Registered user)
Less explicit candidate use cases or interactions: View movie (relation and method of Registered user), update movie (relation), Add movie record (method of admin), Update movie record (method of admin), delete movie record (method of admin), Confirm registration of visitor (inferred from relation), 'Get registered(method of a user),cancel ticket(and method ofRegistered user),Login(method ofRegistered user),Logout(method ofRegistered user),Update Seats available(method ofBook tickets), confirm transaction (method), refund money of cancelled ticket (method)
Implicit/inferred use cases or interactions : create and maintain admin , create a visitor, register and maintain a registered user account, anything else ?
3) Sort out the use cases
Among all the potential use cases and interaction identified, not all should get the use case status. You have then to find which are use cases and which are just interactions part of the same use case. For example:
update movie catalog would be composed of update movie, Add movie record, Update movie record, delete movie record.
Get registered and Confirm registration of visitor are obviously part of the same use case, because the goal is the same: registering a user.
...
I let you as an execise sort out the rest.
4) Review the actors
After having identified meaningful use cases you may want to review your candidate actors:
Some candidate actors might appear to be in fact only objects that are unrelated to users (it's not the case here, but it could be, for example, if you'd have a Movie producer, which is just an info related to a movie but not a user of the system).
Identify obviously missing actors for important use case that you have identified. Here for example, I first thought it was an internet movie business. But the method Update Seats makes obvious that we are talking of a real theater. So who would get the payment from the user, hand out the ticket, reimburse money in relation with the system ? If it's just the online booking system, we are fine. If the cahs desk operator shall use the system as well, then we should add this actor.
Find out relationship between candidate actors. A registered user was first a visitor. Shall we represent both of them in the diagram or not ?
5) Draw your use case diagram
Now you have all the elements, you can make your use case diagram. But you still have to decide on the level of detail you want to represent. Here a proposal:
You can not create a use case from a class design. Only the other way around. Form follows function, not vice versa.
Your class diagram indicates that you are not yet familiar with class modeling. Your classes Book Ticket and Make Payment sound like use cases rather than proper classes. A class is a container of data and functionality working on those data, whereas a use case is a piece of work that an actor performs with the help of the system.
Giving you the help you need might be too broad for this platform. Study introductory texts on UML modeling to get a feeling for what can be expressed by which type of model. And don't feel obliged to use all elements the language offers. There are plenty of use case models that don't need include and extend relations.