I have the following scenario that i would like to make it into a use-case called CallHelp:
The patient needs assistance from a nurse.
The patient presses on the Force Sensitive Resistor (FSR) at the bedside.
The signal light at the bed side will be turned on.
The alarm will sound at the counter.
The web application will show indication of the bed number that calls for assistance.
nurse attends to the patient’s request.
The nurse clears the request on the web application.
However I only manage to get to this point so far and I am confused by the actor for the next few cases which i marked with ??
Use-Case: CallHelp
Primary actor: Patient (or Care system and Nurse too???)
Goal in context: To call for assistance from the nurse in duty.
Preconditions: The FSR is located at somewhere accessible by the patient.
Trigger: The patient needs assistance from the nurse in duty.
Scenario:
1.Patient: presses on the FSR2.
2.Care system: turns on signal light at bedside ??
3.Care system: sounds alarm at counter??
4.Care system: show indication on web app??
5.Nurse: attend to request??
6.Nurse: clear request??
Frequency of use: Many times per day.
Channel to actor: Via FSR sensor.
Is this allowable? Or how should I do this?
That's because they are three separate use cases in (parentheses) with three actors [in square brackets].
[Patient] -> (Request Assistance) -> [Care System] -> (display alert) -> [Nurse] -> (Respond to alert)
A use case is always triggered by an actor action.
Also note that the middle three are sometimes not shown on diagram to simplify the view. You could have a full scenario diagram named "Patient Assistance" that would just contain the two border use cases from above.
[Patient] -> (Request Assistance)
[Nurse] -> (Respond to alert)
However, your use case realization diagrams (sequence, collaboration) would show the complete interaction between all the design elements.
Related
I'm trying to draw UML state diagram for vending machine, maybe its basic but im a beginner and havent found the appropriate solution on internet
Task: - the vending machine receives 1,2 and 5 $, the price of drink is 2 $
- it dispenses the drink if enough money is entered and refunds change
- machine has power on and power off)
I marked each state and transitions the numbers (STATES = s1,2 ..., TRANSITIONS = p1,2 ...), to make it easier to answer without drawing
(e.g. "p1 is wrong, there should be written this" etc)
Here is my diagram:
Questions:
Does it eventually return to IDLE - which seems to me more logical -
or it must go to the final state (rounded black point) as power off?
Or can there be two final states, so the S5 goes to another final state?
should it be after P3 or P4 maybe two branches?
maybe a new branch where the exact price amount is inserted (so there is no need for refund )
if so, where to put it?
If I understand the principle, on the arrows there should be written in this form - correct?
trigger event
[condition if it exists] /
action
Is there any basic errors I made?
Thanks in advance, I appreciate any feedback.
You can have as many finals as you need.
I'd make Dispensing an optional state after Waiting (for the > case) while the = case will directly go to selection. Just from a logical perspective. Of course you can make machines do dispense and change in parallel. In that case you need to fork to Dispense and Refund.
Correct
You should model Power off as Signal which can be triggered at any time. The power can be disconnected at any time during the machine is running, not just when it's idle.
Scenario: (sort of Call center) (1) Customer Requests technician. (2) Request goes into queue for technicians to see. (2b) Customer gets confirmation email about submitting data (3) Technicians Process request (3b) everyone gets email (4) Request is completed (5) Technician submits data for completed request (6) Closed Request.
So two actors on the left. Not everything has to connect right? So for customer getting emails and submitting data is drawn.
For Technician actor they have processing interaction and submitting data and getting email.
I am reading about UML here: http://www.soberit.hut.fi/T-76.115/01-02/palautukset/groups/Fireball/t2/docs/UseCaseMethod.html
Was wondering if there should be an actor on the right side of the diagram representing the database? Am I missing anything? How do you know you are completed with a use-case diagram?
Actors are not included in the system, they are extern to the system. Usually, the DB is in the system and it is not an actor.
For example, in your case, a secondary actor could be google map if the technician has to know how to go the customer and, for that he has to see a map whith the travel. In this case, during a use case, google map is reached to get the map.
The only way I know to be sure that UCs are completed is to review them and/or to get a list of customers needs and to trace customers needs with UCs.
Hope this help.
More :
The remark of #Kilian about function is a real good one. Usually when we start we thought use case as "workflow to achieve a feature" or as the set of all user interface menus and this is not that.
So #Waren, I could suggest:
First try to define the system with a title and a paragph deifning the main mission of the system. System is not only the code you are going to write but all what will deployed for it (machine, virtual machine, db, bays, swicht, procedures, DDL, configuration files and so on)
Then define the needs, high level needs that the system must fulfilled (iso term is shall see enter link description here )
Then define the actors/stackeholder and the inheritance hierarchy to figure the needed roles and rights. Do not forget all operational needs (monitoring, backup/restore, DRS procedure, reports, deployment and so on)
Then define your use cases thinking features or single added values and check the whole coherency. A good point about UC is to describe "error/exception" scenarios.
Then an interesting point could be to define the mode of system : installation, tests before production live, production, update/patch, maintenance, system stop and removing. Like that you will be sure to cover the whole system lifecycle.
I'm currently trying to learn the construction of class diagrams for an upcoming exam, although I'm having difficulties knowing how to identify classes based on a use case specification (or any similar description of a system).
I understand people here can be reluctant to help with education based questions, I just wanted to clarify that I'm not asking for the work to be done for me, I just need to be pointed in the right direction.
I'm going over a past revision paper which contains a use case specification for the process of 'purchasing an ice cream' at a vending machine. The first question is to identify 9 typical classes from this specification.
I understand a class is like an object and usually identified by a noun, although my confusion is how I am able to extract 9 classes as I can only seem to find 6, that is if they're even correct:
Customer, Student, Staff, Touch Screen, Change Dispenser, and Member Card.
Here is the use case specification, apologies for the length:
Ben & Jerry’s company has just installed a new vending machine at a
University; it has a variety of ice creams available, in the format of
tubs or mini-tubs of different flavours. Products are subsidised for
students and staff but not for the rest of users; such that a customer
can insert a member card in a card reader and the subsidised prize for
the selected ice cream is displayed. You have designed a use case
model of the system, and identified a single use case (“purchase an
ice cream”) where the main actors are the customers.
ID: VM1
Name: Purchase a tub
Main Actors:
Subsidised customer (staff and students) 2 Non-subsidised customer
Pre-conditions:
Machine is on and works perfectly fine
There is stock of drinks and coins
There is sufficient stock of coins in the machine for providing change
There is sufficient stock of products
Main Flow:
Machine displays a welcome message
Student/staff inserts member card
System validates member card
Customer selects the tub by pressing the touch screen
Machine displays the subsidised price for the selected ice cream
REPEAT until sufficient coins entered: 6.1 Customer enters coin 6.2 Touch screen displays the amount entered so far
System dispenses the tub
IF too many coins are entered change is delivered
Price is added to the weekly total amount
Machine resets
Post Condition: Ice cream purchased
Alternative flow 1:
IF customer does not have sufficient coins 6.1 Customer presses the return button 6.2 System returns the entered coins
Alternative flow 2:
IF validation is unsuccessful 3.1 Message informing user 3.2 Non-subsidised price is show 3.3 Use case continues main flow 4
If anybody can help I'd really appreciate it. Thanks
You have mostly identified a number of actors, few classes itself. To start your design, ask yourself what the system under consideration (SUC) is. Obviously a vending machine. Now look at the UC how this SUC acts. There are a couple of hints:
control resources (temperature, ice cream, tubs, etc.),
control collection of money,
control dispension of ice cream.
For these you can create controller classes which look to the outside and act accordingly (read temp -> turn on cooling; count money -> start vending; etc.)
The vending process with customer interaction is probably even more complex (show offers, make selection, pricing, etc.)
As you already guessed, this is no tutorial point. However, those are the basic steps to start the design. You can go on and create sequence diagrams to verify collaboration between the single classes (lots of exceptions like: temp controller starting to yell when temp does go up too much).
Say there is 5 bags of potatoes, when it hits two bags, an order is sent to the supplier automatically. Who/What is the actor?
Clearly you have an actor to watch the queue like this:
Even if the Potato Watcher is something implemented inside the SUC, it would be an actor on its own. You may drag it inside the SUC boundary. In a final implementation it might be a system task to poll a queue or a subscriber to the queue. But from the added value viewpoint it's just a simple actor to watch a queue and do something with it.
Since "an order is sent... automatically" the system is the actor. Assuming you are automating using software system.
However in real life it all goes wrong and businesses are far away from sending orders automatically.
Badgerbadger, you need to be carefull about statement "sent an order".
It is easy to overlook actual business process and previous subfunction-level answers are giving a nudge.
More realistic scenario is that the system is the actor who just initiates the check of stocks, maybe orchestrates. And then there is a complicated process of getting approval, finding budget, checking if goods are really required to be ordered and so on. In theory all of those can be automated, but usually in practice there is a work for human actor as well. Of course you may be lucky and avoid all of this.
Example of pessimistic scenario to consider:
It was eight bags, but now hits three. John just bought five bags from us, hooray!
System automatically places an order and pays for 10 more bags.
In ten minutes someone ordered one more.
System automatically places an order again and pays for 10 more bags.
We don't have enough money on account so we are facing overdraft.
At the same time regular inspection found that one bag is rotten.
System: 10 more bags please!
Our colleague just told us that we've missed 20% discount from supplier on simultaneous orders of 25+ bags which can be obtained only by calling a company manager.
John cancels his order in an hour after placing it.
Now we have 36 bags and a hole in our budget.
And our marketing manager just told us that the green bags system ordered are actually now selling with a discount, we are getting rid of them in favour of new line of blue bags.
You have to possibilities here:
Each time the stock is used the system checks if the condition to order is met and if yes then order it. As ordering will probably involve another actor (e.g. supplier's system), you might need to model it as a separate UC and use extend relationship. In this case you will not have any additional actor initiating the order, only the actor initiating stock usage.
The system checks on a regular basis what stocks reached the automated order level and make a single mass order. In this case you'll have to model Scheduler as an actor (in reality it's another system running on the server so it's fine to call it an actor). Some people prefer modelling such actor as "time" but it's discouraged.
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).