Hey there I'm trying to draw state machine diagram for this scenario but It's missing lots of information. If someone here could help out with it.
The Scenario
Tourists will start the journey by selecting the trip using the
Automated Ticketing system (ATS).
The Automated Ticketing System (ATS) will display the trip details.
This Trip details will include the seat-number and destination.
Based on provided trip details, the ATS will compute payment.
The tourist has the option to pay the payment by cash or credit
card.
If the tourist will insert a wrong amount of cash, the ATS will
display "Insert More Cash" message on the screen until the correct
amount will be inserted.
If payment by card was selected by the tourist, the ATS will perform
two parallel tasks. It will validate the expiration date of the card
and check the credit balance. If card is accepted, the bank will
authorize the payment and will update the account of the tourist.
However, if card is not accepted or invalid, the ATS will again ask
for payment option (back to step 5) from the tourist.
After payment is complete, the ticket and receipt are printed by the
ATS.
Cash payment might result in some change, so the change is also
dispensed by the ATS. The tourist will then get the ticket and the
change.
ATS will display the message "Transaction Complete" at the end of
the transaction.
My Drawing:
Ok, so I try to give you some hints. A state machine is always created for a single class, not the overall system under consideration. So let's assume the ATS is a single class (in reality it will probably be more a component consisting of several classes). Now this ATS will in the beginning be idle. It is triggered somehow when a trip is selected. It then has to complete the journey details. It waits for payment and finally it will spit out a ticket. Now (basically!) the state machine looks like this:
This is a scaffold and it was done without reading the details above. Note that instead of the cancel transitions you could use a general exception from an interruptible region which eventually clears payments. In practice you would likely do that since a cancellation should (from a user perspective) be possible at any point. A time out of course would also be possible (what if already some cash had been paid?).
Also I did not include the do/entry/exit actions. For the cash this would be something like add new cash sum so we know when enough money has been paid.
Related
I wonder to find a solution for payment using Stripe. My clients create an event and we split the bill all members who joins the event. Let's say a football game $100 / 10 players, we hold a place until cancellation term is expired, or the game is canceled. What I am looking for solution and if it is possible to make, for the same event, instead of 10 players, 15 joined or 5 only, which means the bill from each varies from $6.60 to $20. I want these players to see that range of the pricing from $6.60 to $20 and book their spot and agree that when event occurs, they will be charged anything between. I remember that was the same solution with Uber at the beginning. Can anyone share any ideas if it is still possible to create this way, maybe they are new legislation and we need to show the total amount. Thank you for any suggestions.
You can use Stripe to save payment info and then charge your customers later:
The Setup Intents API lets you save a customer’s card without an initial payment. This is helpful if you want to onboard customers now, set them up for payments, and charge them in the future—when they’re offline.
You may also be interested in placing a hold on a card and capturing funds later, assuming the time limits work for your use case.
I have an assignment in which the following conditions are set forth:
Brief Statement of Purpose:
An ATM is an electronic device designed for automated dispensing of money. A user can withdraw money quickly and easily after authorization. The user interacts with the system through a card reader and a numerical keypad. A small display screen allows messages and information to be displayed to the user. Bank members can access special functions such as ordering a statement
Brief Summary of Requirements: The ATM is required 1. To allow authorized card holders to make transactions
Card holders shall view and/or print account balances
Card holder shall make cash withdrawals
Card holder shall make cash or check deposits
Card holder shall quit session
To allow bank members to access additional, special services
A bank member shall be able to order a statement
A bank member shall be able to change security details (e.g. PIN number)
To allow access to authorized bank staff
Authorized staff can gain access to re-stock the machine
Authorized staff are able to carry out routine servicing and maintenance
To keep track of how much money it contains and alert bank staff when stocks are getting low
Additional Notes:
Users shall be able to access the ATM by punching in their account number and PIN. Once the system has verified that the account is active and the PIN matches with the account number, the system offers the users four choices. Users can withdraw money, deposit money, check balance or quit the session.
The user must have a minimum of $100 in his / her account. At the end of any transaction a printed copy of the transaction is provided to the user. A transaction could be - withdraw money, deposit money or check balance. Once the user has completed a transaction, the system offers the user the same four choices, until the user decides to quit.
The system shall interface with the device to dispense cash, the device to accept cash or check and the printer. Since we have not studied databases in this course, the system will keep all the information in two RandomAccess files. One file will hold the passwords and the other account balances.
I have built the following use-case diagram but am confused about how detailed it's supposed to be and what should be an extension/inclusion and what should just be a base case. Any feedback would be welcomed.
Should bank members and card holders be separate or together? Technically bank members can do more than a card holder like update security details or order statements, but aren't all bank members card holders?
Here is the other version I have, minus quit not being a use case, are there other factors that are incorrect?
Here are a couple of observations:
As commented, Quit is no use case as it does not add any value to the actor. Rather it looks like post-conditions for other use cases.
Generalizing use cases is a bad idea (although allowed per UML). A use case shows a single unique piece of added value for a actor using the system under consideration. In that context grouping serveral use cases under the hat of a "common" use case is not helpful. Rather connect the specializations directly with the actor and remove that Transaction.
Instead of duplicating the Bank Members's associations to Quit/Transaction you can draw a generalization to Auth Card Holders.
Better use the singular for an actor. It's a general role name and per se covers any amount of real persons/machines.
A part of the requirement/description are scenarios which go into use cases. It's common mistake to try to expose these in functional decomposition in use cases.
Your attempt is not bad. But creating use cases from requirements is not easy and needs a lot of experience. So (like always) I recommend to read Bittner/Spence about use cases. (Do not read the UML specs to get an idea of UC synthesis. They are at best able to give the syntax how to use bubbles and stick men.)
As commented by www.admiraalit.nl there "might be" applications for generalizing use cases and you can discuss that controversially. It's my own preference to not use them since using it wrongly is more easy than using it right. The same goes for export/import. Avoid it as long as you don't know exactly what it's good for. You tend to starting functional decomposition which is not what UCs are good for.
The Image below is a simple use case of a cashier System.
The flow is as follows for the general flow of a check-out
Cashier scans item(s)
Cashier select a payment method
2.A.1 Cashier select payment via credit card
2.A.1 Cashier swipe the credit card onto the reader
2.A.3 Payment is done
2.B.1 Cashier select payment via cash
2.B.2 Cashier input amount received.
2.B.3 System display the change to be given to customer.
2.B.4 Payment is done
Check-out completed.
The question i wish to know if it is valid for the extend to be used in this scenario, where either one of them will occur when a payment is made.
Based on my understanding is that extend means the base case has the option to call the extension. Does my use case model means that there is a possibility that both method are not called (which should not be the case)?
No. This is not correct. Payment via ... is not a use case. It's a constraint for Make Payment (either/or). You are trying to use include/extend for functional decomposition. And this is not right either. Avoid them. If you need to "order" use cases then use pre-conditions to control this.
See also here.
So, not really sure if this is the right place for this but I have this current Context level data flow diagram for the bellow specification extract and I have never done one before so I was wondering if it was correct or if it needs fixing? any help appreciated
This is a link to a screen of my current one http://i.imgur.com/S4xvutc.png
SPECIFICATION
Currently the office staff operate the following processes:
Add/Amend/Delete Membership
This is run on-demand when a new membership application is received or when a member indicates that he/she wishes to make amendments to their details. It is also run in those rare instances when a membership is terminated at the discretion of the manager. A new member has an ID number allocated (simply incremented from the previous membership accepted). A membership balance is also maintained for accounting purposes.
Another process operates in a similar fashion on data associated with transfer partners.
Monthly Maintenance
This is run on the last day of each month to issue requests and reminders for subscriptions due, and to remove memberships where fees remain outstanding. Standard letters are also generated. Membership balances are updated as appropriate.
Payment Updates
This is run prior to the Monthly Maintenance, with membership balances being updated accordingly.
Payments to partners are also disbursed at this time.
New Member Search
This is run whenever a new member has been added to the database. The partners are partitioned in terms of vehicle category and location. Normally, there is a limited choice of partner in a particular location (if, indeed, there is any choice) but for some popular destinations, several partners are involved in providing the airport transfer. Thus, a search is then made through the appropriate section for potential matches in the following manner:
A search is then made on the grounds of sex (many female passengers in particular prefer a driver of their own sex, especially if travelling alone or in couples).
Matches are then selected according to factors such as cost (if available), availability of extra requested facilities (such as child seats, air-conditioning etc.)
Existing Member - Additional Searches
These are run on-demand in the same fashion as for a new member's search. Members may of course request any number of such searches, but a separate payment is due for each.
All financial transactions (payments) are also posted to the separate Accounts file, which also stores other financial details relating to running costs for the consideration of the firm's accountants at the end of the financial year.
Thanks for any help, regarding this level 0 Context only DFD
It needs some fixing.
The most obvious flaw is that you use verbs in your dataflows. In some cases this can be fixed easily by just discarding the verb. Return balance and status is not a datflow, but balance and status is.
In others cases it is not so easy. Check Balance, is it outstanding? sounds more like a Process than a dataflow. It looks like Accounting is responsible for doing that job. So will Accounting produce a list of outstanding balances? Or will it return a single balance and status, and if so, based on what input? Will your Airpot Transport System send a list of balances to check to Accounting?
Take for example Monthly Maintenance. What matters is that you want
requests and reminders for subscriptions due
Standard letters
These need to be visible in your DFD
The fact that you want to remove memberships where fees remain outstanding, probably has not place in the toplevel diagram, because that looks like an internal affair.
In general, focus on what the System produces. Maintaining internal state is secondary, is is a necessity to produce the desired output.
Unsure if this is the right place to ask such question.
I have to define use cases for a Windows Service application and I have some issues.
It regards a Windows Service application that is programmed to perform some tasks periodically.
One of the use-cases is "The system looks up unpaid orders and sends reminder to customer".
Alistar Cockburn's definition of an Actor: "An actor is anyone or anything with behavior."
My questions now are:
1) In my scenario, who is the Actor or Actors?
2) Who are the stakeholders / interests?
I am not Mr. Cockburn, but...
Actor should be anyone (or anything) who comes into touch (/uses) with system. <= Easier definition for me.
1.) So in your case, customer should be actor.
2.) I was always creating use cases with just use cases and actors.. what are stakeholders and interests? They are imo just another actors. If not, it just adds complexity to tool, which should be simple. (IMO)
Btw: Is "The system looks up unpaid orders and sends reminder to customer". really a use case? Isn't that a scenario (part of a use case)?
Edit: Use cases should describe behaviour from end user point of view. So it really should be something like:
Scenario: Pay for order
Actor: Customer
Flow:
1. Customer requests unpaid orders from system (not specifing how).
2. System provides (shows) unpaid orders.
3. Customer chooses one order
4. System process selection and shows detail about selected order
5. Customer requests to make a payment (again not telling something like 'customer will click on button called "pay"')
6. System requests payment details from user
7. User fills details
8. System validates entered data
9. IF successful:
a.) Order payment is comleted, system redirects user to XXX.
10. ELSE go back to step 7
It might be a bit long... but that's basically how I am doing scenarios (which are grouped into one use case).