Will the actors in both these cases be student and system? (These two cases as a whole point to one system)
Enrol a student at the university: A student provides his or her
personal details (name, address, date of birth), along with the code
of the course (e.g. Bachelor of Computer Science) in which he or she
wishes to enrol. A student record is created, and a unique student
ID number is assigned to the student. The system automatically
enrols the student in any core first-year subjects for the course.
Enrol a student in a subject: A student provides his or her student
ID number and the subject code of the subject in which he or she
wish to enrol. The system checks that the subject requested by the
student is allowed for the course in which the student is enrolled.
If not, the enrolment request is rejected. The system checks what
subjects (if any) are specified as prerequisites for the subject in
which the student wishes to enrol. If the student has passed all the
prerequisite subjects, he or she is enrolled in the desired subject.
Otherwise, the enrolment request is rejected.
The actor of the use case will be the user. The student (or possibly a university employee). You may have a generic user and from that extend different user types.
In this case the system could be the actual program the user is interfacing with. So the use case represents how the system user interacts with the system. A bit like the following diagram, although my diagram has no detail within the system boundary.
In some use cases, you may be examining a part of a system and then there may be a system actor from outside of the relevant case that interacts with it.
In this case your system could be an actor, depending on how the system (or program) is modularised. The same goes for accessing databases.
This second image is a closer look at the use case above, "run". It's looking at a module within the system.
You can see by my images, that it depends on how the system boundary is defined. UML diagrams vary greatly, and much of it depends upon the level of expected detail. If it is a school assignment, a work spec, for a quote, an idea or a simple expression of thought.
I hope this is helpful.
Related
what is the difference between MedicationDispense vs MedicationAdministration fhir? Functionally speaking
I am BA and I'm trying to figure out what is actually retrieved when using one or the other. Devs are all new to this FHIR too.
If you read the descriptions there are subtleties but not clear definitions.
For example, are MedicationDispense medications that my doctor GP prescribed and I bought at the pharmacy? Are MedicationAdministration only those given to me when I am under care at home or hospital? Seems like a thin line.
MedicationDispense is used to track the supply of a medication (typically a prescribed medication) for patient use. In out-patient settings, it tracks the provision of a supply of medication to a patient or their representative - typically for periods of 30 days or longer. In in-patient settings, it is generally used to track the supply of a medication from the pharmacy to the ward (possibly per day or longer, but sometimes on a per-dose basis). In both cases, it tracks only the supply of the medication, not that it has actually been consumed by the patient. It is not uncommon for a medication to be dispensed but not administered (or not administered as planned).
MedicationAdministration tracks a single consumption of a dose of a medication. A completed MedicationAdministration means the patient is believed to have actually ingested/been injected with/otherwise appropriately therapeutically received the substance. It is typically only used in in-patient settings where a nurse or other practitioner records the occurrence of an injection, an IV adjustment, the witnessing of a patient swallowing an oral medication, etc. However, it can also be created by home health monitoring solutions. E.g. if a patient tracks their medication consumption with a mobile phone app, the app would create a MedicationAdministration instance for each dose of medication the patient (or spouse or other caregiver) records. Aside from that exception, administrations aren't generally tracked for outpatients.
The main differences are:
a MedicationDispense is accompanied by medication instructions indicating the timing and dosage instructions for how the supplied medication should be used. The quantity dispensed is typically sufficient for multiple doses and is NOT necessarily intended to be taken all at once.
a MedicationAdministration is not accompanied by instructions. Instead it simply captures what was administered at a particular point in time, or for IV or other continuous medications, over a specific period of time at a given rate.
The business processes they're associated with are quite different. If you feel the descriptions could be improved to make the differences clearer, feel free to propose language using the 'propose a change' link at the bottom of any page in the FHIR specification.
I have a quiz system scenario and I have drown my Use case, now I want to draw a sequence diagram which describe the the choosing quiz by student as following:
student will see a list of available teachers in the system.
student will choose a specific teacher and the system will show the
available quizzes.
the student will choose a specific quiz.
the system will return the question and the available answers to the
student to answer them later.
How I can represent the previous scenario in sequence diagram,I know the essential of sequence diagram but I don't know I can apply that on my scenario.
Edit: The following diagram is my attempt.
Refine the problem by identifying other actors that constitute the "system". Quiz, Question and Answer look like data objects that will be transferred throughout the system, with no activity or behavior of their own, it is not likely there will be any special messages they receive or send.
Similarly to how http://www.uml-diagrams.org/sequence-diagrams-examples.html#facebook-authentication refines original use case "system authenticates user using his facebook account"
where the original abstract term "system" expands into "WebBrowser", "Application", "Facebook Authorization Server", "Facebook Content Server" which can be further refined down into more concrete classes which will turn into actual code
Sequence diagram is drawn between the objects who interact with each other. Here in your scenario The student will interact with system and not with the teachers or quizes. So the sequence diagram of your scenario will be like this:
**
Currently (02-12-2013), in the practitioner resource 0..1 names can be associated to a practitioner. In contrast, 0..* names can be associated to a patient. This allows specifying a person's maiden name for example. Why is there this difference?
In the project I'm working on, we're exporting existing data about practitioners from our database using FHIR messages. In the database, all persons are stored in the same way. Since it is possible to store a person's maiden name (which is also done for practitioners in our data), we have to build the name part in a practitioner message differently from the name part in a patient's message. Also, when parsing a practitioner message, we'll need different code to extract the name of a patient and of a practitioner.
Therefore, I believe that there are two disadvantages of having different generic attributes of persons of different kinds:
It prevents us from sending the complete name information of a practitioner without resorting to extensions.
It complicates the code for building and parsing FHIR messages, which also makes the code less maintainable.
I understand that in most cases it's not very important to be able to send the maiden name of a practitioner, but it does add extra complexity for the implementation. Furthermore, I don't see what problems setting the cardinality to 0..* could cause. If someone only wants to send a single name, then that's still possible.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also discussed here) also seems like an unnecessary restriction.
Managing cardinality is a tricky issue. If the resource can have multiple names, then everyone dealing with this has to deal with the possibility of multiple names. The relevant committee believes that having multiple names is an unusual practice for practitioner records (that's certainly my experience) but a common one for patient.
Perhaps you'd like to explain your full use case so it can be considered by the committee? On the other hand, you can use an extension:
<Practitioner>
<extension url="http://myurl.com/fhir/profiles/extensions#maiden">
<valueHumanName>
<!-- details for human name -->
</valueHumanName>
</extension>
</Practitioner>
Therefore, I believe that there are two disadvantages of having
different generic attributes of persons of different kinds:
When designing Patient, Pracitioner and RelatedPerson, we have tried several different solutions:
having Person resource, separate from Patient/Pracitioner. This proved to be burdensome since many systems (unlike yours!) don't capture patient and person separately, and when looking at REST useage patterns it turned out they were always needed togehter, resulting in unneccessary burden on client and server
Having a special Demographics datatype which contained all shared attributes. This met resistance since it meant having attributes on Practitioner that did not make sense, e.g. marital status and deceasedDate. This run against our intent to keep the Resources focused to their scope and the number of attributes per resource manageable.
This is how we ended up where we are now: more or less "duplicating" the attributes (when applicable) across those three resources.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also >discussed here) also seems like an unnecessary restriction.
The Practitioner resource represents a person employed by an organization to provide care. We assumed that for one such engagement, there is one "official" (post) address for that person. The practitioner may however perform services at multiple locations (each of which can have an address).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
The question is quite generic. What are the points that should be kept in mind to identify a valid use case? How to approach a use case?
A use case identifies, with specificity, a task or goal that users will be able to accomplish using a program. It should be written in terms that users can understand.
Wikipedia's description is overly formal. I'll dig through my other texts shortly.
In contrast, the original wiki's article is much more accessible.
An early article by Alastair Cockburn, cited positively by The Pragmatic Programmer, contains a good template.
This question, from just a few days ago, is very closely related, but slightly more specific.
The definition of use case is simple:
An actor's interactions with a system to create something of business value.
More formally:
a sequence of transactions performed
by a system that yield a measurable
set of values for a particular actor.
They're intended to be very simple: Actor, Interaction, Value. You can add some details, but not too many.
Using use cases is easy. Read this: http://www.gatherspace.com/static/use_case_example.html
The biggest mistake is overlooking the interaction between actor and system. A use case is not a place to write down long, detailed, technical algorithm designs. A use case is where an actor does something.
People interact with systems so they can take actions (place orders, approve billing, reject an insurance claim, etc.) To take an action, they first make a decision. To make a decision, they need information
Information
Decision
Action
These are the ingredients in the "Interaction" portion of a use case.
A valid use case could describe:
intended audience / user
pre-requisites (ie must have logged in, etc)
expected outcome(s)
possible points of failure
workflow of user
From Guideline: Identify and Outline Actors and Use Cases by the Eclipse people:
Identifying actors
Find the external entities with which
the system under development must
interact. Candidates include groups of
users who will require help from the
system to perform their tasks and run
the system's primary or secondary
functions, as well as external
hardware, software, and other systems.
Define each candidate actor by naming
it and writing a brief description.
Includes the actor's area of
responsibility and the goals that the
actor will attempt to accomplish when
using the system. Eliminate actor
candidates who do not have any goals.
These questions are useful in
identifying actors:
Who will supply, use, or remove
information from the system?
Who will
use the system?
Who is interested in a
certain feature or service provided by
the system?
Who will support and
maintain the system?
What are the
system's external resources?
What
other systems will need to interact
with the system under development?
Review the list of stakeholders that
you captured in the Vision statement.
Not all stakeholders will be actors
(meaning, they will not all interact
directly with the system under
development), but this list of
stakeholders is useful for identifying
candidates for actors.
Identifying use cases
The best way to find use cases is to
consider what each actor requires of
the system. For each actor, human or
not, ask:
What are the goals that the actor will
attempt to accomplish with the system?
What are the primary tasks that the
actor wants the system to perform?
Will the actor create, store, change,
remove, or read data in the system?
Will the actor need to inform the
system about sudden external changes?
Does the actor need to be informed
about certain occurrences, such as
unavailability of a network resource,
in the system?
Will the actor perform
a system startup or shutdown?
Understanding how the target
organization works and how this
information system might be
incorporated into existing operations
gives an idea of system's
surroundings. That information can
reveal other use case candidates.
Give a unique name and brief
description that clearly describes the
goals for each use case. If the
candidate use case does not have
goals, ask yourself why it exists, and
then either identify a goal or
eliminate the use case.
Outlining Use Cases
Without going into details, write a
first draft of the flow of events of
the use cases identified as being of
high priority. Initially, write a
simple step-by-step description of the
basic flow of the use case. The
step-by-step description is a simple
ordered list of interactions between
the actor and the system. For example,
the description of the basic flow of
the Withdraw Cash use case of an
automated teller machine (ATM) would
be something like this:
The customer inserts a bank card.
The system validates the card and prompts
the person to enter a personal
identification number (PIN).
The customer enters a PIN.
The system
validates the PIN and prompts the
customer to select an action.
The customer selects Withdraw Cash.
The system prompts the customer to choose
which account.
The customer selects
the checking account.
The system
prompts for an amount.
The customer
enters the amount to withdraw.
The
system validates the amount (assuming
sufficient funds), and then issues
cash and receipt.
The customer takes the cash and receipt, and then
retrieves the bank card.
The use case ends.
As you create this step-by-step
description of the basic flow of
events, you can discover alternative
and exceptional flows. For example,
what happens if the customer enters an
invalid PIN? Record the name and a
brief description of each alternate
flow that you identified.
Representing relationships between
actors and use cases
The relationship between actors and
use cases can be captured, or
documented. There are several ways to
do this. If you are using a use-case
model on the project, you can create
use-case diagrams to show how actors
and use cases relate to each other.
Refer to Guideline: Use-Case
Model for more information.
If you are not using a use-case model
for the project, make sure that each
use case identifies the associated
primary and secondary actors.
We have a layered application, or at least is in the process of transitioning to one, broken down as follows:
Interface (user-interface or application-interface, ie. webservice, etc.)
Business logic
Data access
To make the rest of this question more concrete, I'll describe a specific instance.
We have a user interface, which has a controller object behind it (the business logic layer). This controller talks to the database through another object (the data access layer).
In a given context, the user interface allows the user to pick an employee to tie the operation being done to. Since there are rules regarding which employees the user (well, any world outside of the controller really) can pick, the controller provides two things for this:
a readable property containing a list of available employees to choose from
a read/writable property containing the currently chosen employee
The user interface might read the list and use it to populate a combobox.
In version 1 of this application, the combobox contains the identifying number of the employee + the name of the employee.
All is well...
... until version 1.1, a bugfix. A user complains that he can't choose between Jimmy Olson and Jimmy Olson because the application doesn't make it easy enough for him to know which is which. He knows there is one Jimmy in the sales department, and another in the development department, so the fix for this 1.1 version is to simply tack on a slash + the department name in the combobox. In version 2 we would opt for replacing the combobox with a combobox that has column support, removing the slash, but in 1.1, this is what is chosen in order to minimize the risk of further bugs.
In other words, the combobox would contain:
1 - Jimmy Olson/Sales
2 - Jimmy Olson/Development
other people
However, the user interface code has no SQL code, or any way to get hold of that department, and thus we have to go to the controller and look at the code there. The controller doesn't need the department, and to be honest, it doesn't even need the name of the employee, the identifying number is enough, so there is nothing in the controller that asks for or does anything to the department. So we have to go down to the data access layer and change the SQL there.
This solution quite frankly smells.
If there are multiple interfaces to this controller, with different requirements, we have three possible solutions:
Change the data access layer to cater for the (increasing/diverse) needs of multiple interfaces (2 layers away), which means that all the interfaces will possibly get all the data they need, but they would also get all the data required for any of the other interfaces
Add something that lets the user interface tell the data access layer (still 2 layers away) what it needs
Somehow make the user interface layer get hold of the required data without changing either the controller or access layer involved, this sounds like we need more data access code, somewhere.
None of the above solutions feel good.
What I'm wondering is, are we completely off course? How would you do this? Are there a fourth and fifth solution below the 3 above?
Per this question: Separation of Concerns, the accepted answer contains this quote:
The separation of concerns is keeping the code for each of these concerns separate. Changing the interface should not require changing the business logic code, and vice versa.
Does this simply mean that all the controller/data access layer should provide us with is whatever it needs to do its job (ie. the identifying numbers of employees), and then the user interface should go talk to the database and ask for more information about these specific employees?
The way I see it, you have two possibilities:
Have the lower layers send up all
the information they have about a
person, possibly as an XML document,
even though many of the consumers of
that information don't need it all.
Provide APIs for the higher level
layers to drill down and get the
information they need. So in the
case you give, have a method that
the interface can ask the business
layer to ask the database layer for
the department given the user id.
Both have trade-offs. The first one exposes a lot more information, possibly to consumers who don't have any right to that information. The second one passes a lot less information per transaction, but requires more transactions. The first one doesn't require a change to the API every time you have more information, but changes the XML. The second keeps the interface of existing APIs the same, but provides new APIs as needs change. And so on.