I'm currently learning the second part of object-oriented programming and we have moved on to UML. We are learning about use cases and actors currently and we need to create: List of actors and use cases initiated by each actor for a given problem.
I understand what each of the individual components are but we haven't been given any examples. I've looked up examples but it only seems to give the final result of the use case diagram. What I am struggling with is using a problem statement ( the requirements of the system) to then create and find the actors and use cases:
https://www.scribd.com/document/401208954/Pms
This is my example of what I think to do but not sure if im on the right track...
2.2 MONITOR Each bed has a separate monitor that collects patient data, sends information to the display, and responds to user commands
and queries.
The requirement is going to be: collects patient data, the goal: sends info to the display and the owner: the patient????
First, you need to find in your document the actors who use the system and initiate interaction with it. These are the primary actors. For example:
1.PURPOSE
Blablabla... The users of the system are nurses and doctors
Then you need to find in your document any secundary actors. It's the actors that might be involved in an interaction in the system, but as a participant, not as initiator. For example:
3.1.4 ECG AND HEART RATE (HRT)
The ECG signal is carried by cables connected to electrodes attached
to the patient's skin.
Here, clearly, the patient is involved, at least passively.
Attention, primary and secondary actors could also be systems, that would be independent of the system under consideration (e.g. a central admission system that would feed the system with patient data). I'm not sure that we have this case here.
Then you need to go again through your text, keeping the primary actors in mind, and looking for what they could want to use the system for. That's the use case, and it should in principle correspond to an actor's goal. For example:
3.1.8 PATIENT ADMISSION AND DISCHARGE
In order to blablabla..., the patient must be admitted. Patient
admission consists of blablabla....
3.3 EVENT RECORDING
The user must be able to input textual remarks on the patient
condition. Blablabla...
In these examples, the users will definitively want to admit a patient, monitor the vital signs of the patient, and record events. The difficulty is to filter out what the users want to do (the goal), and the details of how they do it or how the system looks like. For example, entering the name and age, plugging the ECG cable, or the NBP are operational details of the admission.
Some of those details are purely descriptive (where the info will be shown on the screen), but some details could be a secondary goal (a subgoad for the user, in order to achieve a higher level goal). For example silencing the monitoring. You may list those as a use case, but you should then note that it's not a top level. These details are only needed when refining the main use cases.
Then you may associate secondary actors to identified use cases where appropriate.
Related
When I query seat maps for certain flights, I find that much of the seatmap comes back with "blocked" status. I can confirm with various other sources (airline webpage, ExpertFlyer, etc.) that many of the seats showing up as blocked in the Amadeus API are actually open.
One example is the following query for EWR-LHR flights on UA. I run this as a GET query on the flight-offers API and then pass the results to the seat map API.
https://test.api.amadeus.com/v2/shopping/flight-offers?originLocationCode=JFK&destinationLocationCode=LHR&departureDate=2020-12-18&adults=1&nonStop=true&max=250
This comes back with rows 30-35 or so all "BLOCKED" status. Many of these seats are in reality open, but United may charge an extra fee to book them.
Is there a way to show actual seat availability or include the information on seats for purchase? Alternatively, can I specify the booking class in the query somehow? E.g. I wonder if I asked for a higher class of fare (e.g. full-fare Y) maybe no seat charge would be required (not completely familiar with UA's rules on this). Overall my goal is to see all actual available seats.
The SeatMap Display API builds the aircraft seatmap based on specific flight offer. That’s why the information you get for the seat availability depends on the traveler class information. In the Flight Offers Search API you can define with the parameter travelClass the travel class; economy, premium economy, business or first class. Also, in the test environment it's normal to have discrepancies with other sources as the test environment doesn't contain the full and live data.
I am designing a system for airport as a part of office project and I am supposed to design a class for handling passengers. I am using WPF MVVM so I have my PassengerInfoViewModel which basically represents a Passenger traveling to Airport. I am confused among using State, Visitor and Decorator patterns.
The requirements:
There are several types of Passengers. Passenger can be a *** with SSN + verified biometrics, SSN + enrolled without verified biometrics, Without SSN + enrolled without verified biometrics, With SSN + enrolled without verified biometrics and other combinations with some other entities.
Any of the above passenger can have one of the following status. NewEnrollment, WaitingForVerification, Verified, Rejected, Deboarded, Cancelled etc. The status of the passenger is updated based on some actions performed by airport staff. But this will be updated not during a single transaction. The updated status will be pulled next time a passenger inputs the Booking Reference number.
A passenger can opt for special assistance that triggers a special workflow. The passenger can check/uncheck special assistance during a single transaction. So, the values keep updating in a single transaction. Once the transaction is over, and if the passenger has opted for Special assistance, this can't be changed again.
What I am planning to do is:
Create a base abstract Passenger class which has basic demographic and other details common across all the passengers. PassengerWithSSN and PassengerWithoutSSN can be a separate class with a VerificatonStatus field Verified, EnrolledPendingVerification etc. This will be fetched when initial transaction begins.
Is this right or should I make separate classes for each type (I am thinking so). Reason being each type triggers a different workflow. As the state does not change during a transaction, I am not going with State pattern.
Also, I should be able to plug different workflows per type in future. Workflows involve calling separate APIs and navigation to different pages.
For NewEnrollment, WaitingForVerification etc, this will be put into a PaxStatus and I am planning to use Visitor pattern to handle the logic for this, keeping it out of the main class. Not sure if this is the right approach.
The SpecialAssistance is something which will change during transaction so I am planning to use State design pattern here. SpecialAssistance state and NormalPassengerState Also there might be an Infant state in case parents want to register Infants for workflows.
There are N*N combinations (e.g. a Non-Verified passenger with Biometrics Enrolled and has SSN travelling with an Infant and needing special assistance) which might mess up needing a lot of rework in future if not designed properly.
Can anyone guide me in the right direction?
One of the latest projects is to organise an outdoor summer music festival known as the ‘Long-Weekend’ over a three-day period, and they really need a system to help them record and access the data. It is hoped that the festival will attract between 4000 and 5000 fans each day during the three-day period. Recently they had an event of folk music festival in Roundhay Park, Leeds. They haven’t got much social media presence, therefore, they would like to include links to relevant social media as part of your final product. The system needs to be accessible to multiple users.
In addition to above, here is a list of some other important information we need to include in the system:
Details for each Festival and the key organizer of the Festival.
Details of Venues and Locations where the festival is taking place, and Contact person for the Venue
Details of Venue as they may be of a different types/sizes and hire price.
List of all staff working at the Festival
List of Bands playing at Festival.
Additional Entertainment to keep fans occupied over a period
The music bands represented by an agent need to play a prominent Venue
Space for band/singers should be allocated for storage
A list of bands on each location, times and dates are kept
Allocation of staff to a stage and supervisor and the ability to record feedback
Reporting on the equipment list for each stage
Security staff allocated to a venue and each stage (if applicable)
Information of qualified first aiders.
Well this forum is purely related to code stuff while you have asked some conceptual to logical conversion.
Anyway, I will try to answer:
Identify the entities like bands, venues, staff etc
Identify their attributes like bandId, bandTitle or venueTitle, venueAddress, venueContactPerson
Identify the strong/week/multiple/composite attributes of these entities for example title of band will be single, address can be composite by combination of streetAddress, streetNo, sector, city etc, contactPerson can be multiple
Identify the relations between entities for example band has many staff member, a member can not be part of multiple bands etc
Try to Draw diagram by following https://www.smartdraw.com/entity-relationship-diagram/
Further, you can email me at ping#naveedramzan.com
Say I have an app for patients and doctors.
Patients should be able to access their information at `site.com/api/patients/.
Doctors should be able to access information about the patients as well, but would receive different information than the patients.
I can imagine two ways of handling this:
api/patients with logic to split between different permissions
OR
api/patients for patients AND
api/doctors/patients for doctors getting information about patients
This seems relatively fine, but then I started thinking about what happens when both a doctor AND a patient can add tasks for a patient.
api/patients/tasks/ for a patient to add a task BUT
api/doctors/patients/tasks Which gets pretty bad as far as nesting goes (Where I believe it might be better to limit the depth of my routes)
Is it simply better to have api/patients and check for whether the user is a doctor or a patient or to nest resources? What is the consensus on best practice (if there is one)?
It would be nice to have API endpoints like:
api/tasks/
api/patients
api/doctors/
which keeps things simple, and then control permissions/authentication with a token or query string.
Definitely don't do api/doctors/patients, etc.
Should this be two different APIs, one for Doctors and one for Patients? It depends on how much overlap of functionality there is.
In any event, you should already be tracking authentication/authorization information for your users. Otherwise you'll have doctors modifying patients who don't go to them. Use the auth info to determine what values/options are supported for the caller.
I assume you're handling the case where I copy Dr. Bob's token/query string and send my own requests?
I'm trying to make the domain model of a management system. I have the following kind of people in this system:
employee
manager
top mananger
I decided to define an User, from where Employee, Manager and Top Manager will specialize from.
Now, I don't know what kind of specialization hierarchy I should choose from.
I can't decide between the following ways:
or
Which might be preferable and why?
As a long time coder, every time I try to do a domain-model, I have to fight against the idea of trying to think in how I'm going to code this. From what I've understood, I should not think about those matters in the domain-model, only in object relationships. I don't have to think of code duplication or any of these kind of details here, so I can't really pick any of the options over the other.
Thanks
EDIT:
I'll be a bit more explicit: This is a program to manage worker's vacations plans. With this program, a employee can choose the set of vacations days for the year. Then the manager might approve or not those days for each one of the employees and at the end of the day the top manager should approve or disapprove the manager's decisions. This is all the users of my program are supposed to be able to do. There are no other tasks.
This mostly comes down to a question of how you define your terms. The basic question is whether a manager can be substituted for an employee under any possible circumstances -- and without knowing the precise rules of the workplace being modeled, it's impossible to say one way or the other about that.
One general notion is that yes, at least up to a certain point, in a pinch a manager should be able to do the job of any of his subordinates (at least one level below, and quite possibly two or three).
On the other hand, in some places with lots of union-driven rules in place, that may not be the case at all. Even if a person is entirely capable of doing a job, rules may prevent him from substituting in that position at all. In some cases this arises from certification requirements and such (e.g., the manager may have one been qualified to do the work, but the required certification has lapsed) or from things like union rules (e.g., a friend of mine who was once reprimanded because he carried a flashlight bulb and battery from the company store back to his lab instead of getting a union materials handler to do that for him).
In real life, Managers are Employees too. So this is surely just a chain of increasing specialisation:
User -> Employee -> Manager -> Top Manager
edit
"This is a program to manage the
vacations plans of workers."
In you company do Managers take planned vacation? Surely they do. And equally surely you are not going to build a separate application to manage that. So what you really need is this:
User -> Requester
-> Approver
Each User will be a Requester in one approval chain. (You may need special arrangements for the CEO). In addition some Users will be Approvers in one or more chains. The final approver will probably vary depending on the grade of the Requester: the CEO won't want to bother themselves with approving the vacation arrangements of the janitorial staff.
You will need some rules to enforce who can be an Approver of any given Requester's holidays. Unless you have an exceedingly flat organisation you will find you have a hierarchy of workers and managers. For instance, a Team Leader or a foreman - individuals who are in other respects "workers" rather than "managers" - may be in the chain. Also you may need to consider other aspects of the organisation. Fr instance, if the employee wishes to carry leave over to the next year that may require approval from the HR dept, somebody who normally has no managerial responsibility for the employee whatsoever.
Edit 2
Okay, so we are modelling an arbitrary set of rules rather than a realistic scenario.
Let's see. Each User fits into a single category, defined by these tasks:
an Employee can Request leave
a Manager can Approval or Reject a Leave Request
a Top Manager can Accept or Overturn an Approval or Rejection
Managers and Top Managers have no behaviours in common. Consequently, the first model is the correct one.
I would model these as actors. They are not the domain of the system, but the users of the system. Would you model a shop's inventory system with 'school-kid who wants sweets', 'school-kid's parent who wants tobacco', 'clerk' etc? Although only a store manager (actor) can give refunds without a receipt, what matters at the system level is that system recognises the store manager's key, and it's that permission token which is in the software rather than role the actor takes.
The domain of the system you describe is vacation requests and the user account, and some of the use cases mean that some of the accounts have permission to perform certain state transformations to a vacation request.
The difference in modelling User/Manager/Employee as actors and roles is that you can focus on modelling what you need to put into the system, as don't have to have hierarchies of actors - you start using abstraction at the use case and system entity levels, rather than in the actors. It's not always a bad idea to think 'how would this work in code', at least as far as asking 'why bother coding this distinction'.