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?
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.
I have two questions related to Udi Dahan's article : Don’t Delete – Just Don’t
Sometimes we do need delete, the user (domain expert) request the delete functionality(the real meaning) for wrong data, Say the HR user has a form to add employees and he inserted wrong employee data, He wants to delete this data, It's not used in business yet and it's totally different from Retire or Fire an employee. How to handle the two cases in implementation?
How to make the UI more representative for this case ? using two buttons One shown only if we can DELETE employee and the other if we want to RETIRE employee ?
If the business wants this functionality and if they speak this words then it means they are part of the Ubiquitous language. In this case you may add the delete command. It is however recommended to make the intention clearer; you can name the command as deleteUserBecauseOfInvalidRegistration or so. In this case the delete command is part of the domain model; this means that you can easily restrict the deletion of the user depending on the other properties; for example, a user cannot be deleted anymore if it has approved by the HR manager or so. Then the UI can easily reflect this behavior by hiding the delete button if the operation is not permitted.
An alternative, when the business specialists have heard the word "delete" used by the IT guys so its not from the real domain, you may expose this functionality only in the Admin UI, as a low level command that deletes the rows from the database. The Admin UI could then be accessed only by some higher level persons, like the HR manager.
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?
In my community, every user should only have one account.
So I need a solution to verify that the specific account is the only one the user owns. For the time being, I use email verification. But I don't really need the users' email adresses. I just try to prevent multiple accounts per person.
But this doesn't work, of course. People create temporary email addresses or they own several addresses, anyway. So they register using different email addresses and so they get more than one account - which is not allowed.
So I need a better solution than the (easy to circumvent) email verification. By the way, I do not want to use OpenID, Facebook Connect etc.
The requirements:
verification method must be accessible for all users
there should be no costs for the user (at least 1$)
the verification has to be safe (safer than the email approach)
the user should not be demanded to expose too much private details
...
Do you have ideas for good approaches? Thank you very much in advance!
Additional information:
My community is a browser game, namely a soccer manager game. The thing which makes multiple accounts attractive is that users can trade their players. So if you have two accounts, you can buy weak players for excessive prices which no "real" buyer would pay. So your "first account" gets huge amounts of money while the "second account" becomes poor. But you don't have to care: Just create another account to make the first one richer.
You should ask for something more unique than an email. But there is no way to be absolutly sure a player don't own two account.
The IP solution is not a solution, as people playing from a compagny/school/3G will have the same IP. Also, Changing IP is easy (reset the router, proxy, use your 3G vs wifi)
Some web site (job-offer, ...) ask you for an official ID number (ID, passport, social security, driver licence, visa (without the security number, so peolple will feel safe that you won't charge them), ...)
This solution got a few draw back:
minor don't always have an ID / visa
pepole don't like to give away this kind of info. (in fact, depending where you live: in spain for example, it is very common to ask for ID number)
people own more than one visa.
it is possible to generate valide ID/visa number.
Alternative way:
ask for a fee of 1$
to be allow to trade more than X players / spend more than X money.
people that pay the fee got some advantage : less ads, extra players, ...
paying a fee, will limitate creation of multiple account.
fee can be payed using taxed phone number (some compagny provide international system)
the payment medium could be use as an ID (visa number)
put some restriction in new account (like SO).
eg: "you have to play at least 1 hour before trading a player"
eg: "you have to play at least 3 hour before trading more than 3 players"
Use logic to detect multiple account
use cookie to detect multiple account
check last connection time of both player before a transaction. (if player A logout 1 minute before player B login : somethings is going on)
My recommandation :
Use a mix of all thoses methode, but keep the user experience fluide without "form to fill now to continue"
Very interesting question! The basic problem here is multi-part -
Opening an account is trivial (because creating new email IDs is trivial).
But the effect of opening an account in the game is NOT trivial. Opening a new account basically gives you a certain sum of money with which to buy players.
Transferring money to another account is trivial (by trading players).
Combining 1 & 2, you have the problem that new players have an unfair advantage (which they would not have in the real world). This is probably okay, as it drives new users to your site.
However adding 3 to the mix, you have the problem that new players are easily able to transfer their advantage to the old players. This allows old users to game the system, ruining fun for others.
The solution can be removing either 1,2,3.
Remove 1 - This is the part you are focusing on. As others have suggested, this is impossible to do with 100% accuracy. But there are ways that will be good enough, depending on how stringent your criterion for "good enough" is. I think the best compromise is to ask the user for their mobile phone numbers. It's effective and allows you to contact your users in one more way. Another way would be to make your service "invite only" - assuring that there is a well defined "trail" of invites that can uniquely identify users.
Remove 2 - No one has suggested this which is a bit surprising. Don't give new users a bunch of money just for signing up! Make them work for it, similar to raising seed capital in the real world. Does your soccer simulation have social aspects? How about only giving the users money once their "friend" count goes above a certain number (increasing the number of potential investors who will give them money)?
Remove 3 - Someone else has already posted the best solution for this. Adopt an SO like strategy where a new user has to play for 3 hours before they are allowed to transfer players. Or maybe add a "training" stage to your game which forces a new player to prove their worth by making enough money in a simulated environment before they are allowed to play with the real users.
Or any combination of the above! Combined with heuristics like matching IP addresses and looking for suspicious transactions, it is possible to make cheating on the game completely unviable.
Of course a final thing you need to keep in mind is that it is just a game. If someone goes to a lot of trouble just to gain a little bit of advantage in your simulation, they probably deserve to keep it. As long as everyone is having fun!
I know this is probably nothing you have expected, but...
My suggestion would be to discourage people from creating another account by offering some bonus values if they use the same account for a longer period, a kind of loyalty program. For some reason using a new account gives some advantages. Let's eliminate them. There are a lot of smart people here, so if you share more details on the advantages someone could come up with some idea. I am fully convinced this is on-topic on SO though.
We have implemented this by hiding the registration form. Our customers only see the login form where we use their mobile number as username and send the password by text message.
The backend systems match the mobile number to our master customer database which enforces that the mobile number is unique.
Here is an idea:
Store UUID in a cookie at clients. Each user login store the UUID from Cookie in relation to the account entity in the databse.
Do the same with the IP adresses instead of UUID.
After that write a program interface for your game masters that:
Show up different account names but same IP (within last x hours)
Show up different account names but same UUID (nevertheless how long ago)
Highlight datasets from the two point above where actions (like player transfers) happened which can be abused by using multiple accounts
I do not think you should solve that problem by preventing people having two or more accounts. This is not possible and ineffective. Make it easier to find that evil activities and (automatically temporarly) ban these people.
It's impossible to accomplish this with a program.
The closest you can do is to check the ip address. But it can change, and proxies exist.
Then you could get the computer MAC address, but a network card can be changed. And a computer too.
Then, there is one way to do this, but you need to see the people face to face. Hand them a piece of paper with a unique code. They can only subscribe if they have the code.
The most effective solution might be the use of keystroke biometrics. A person can be identified by the way the person writes a sentence.
This company provides a product which can be used to implement your requirements: http://www.psylock.com/en
I think 1 account per email address should be good enough for your needs. After all, account verification doesn't have to end right after signup.
You can publish the IP address of the computer each message was posted from to help your users detect when someone is using multiple accounts from the same computer, and you can use a ranking system to discourage people from using temporary accounts.
Do your game dynamics allow for you to require that both users be online for a trade to occur? If so, you can verify the IP addresses of both users involved in a trade, which would be the same unless the user was paying for multiple internet connections and accessing two accounts from separate machines.
Address the exact scenario that you're saying is a problem.
Keep track of the expected/fair trade value of players and prevent blatantly lope-sided trades, esp. for new accounts. Assume the vast majority of users in your system are non-cheaters.
You can also do things like trickle in funds/points for non-trading actions/automatically overtime, etc.
Have them enter their phone number and send a text message to it. Then, keep a unique of all the cell phone numbers. Most people have one cell phone, and aren't going to ask their friend to borrow it just to create a second account.
http://en.wikipedia.org/wiki/List_of_SMS_gateways
I would suggest an approach using two initiatives:
1) Don't allow brand new accounts to perform trades. Accounts must go through a waiting period and prove that the account is legitimate by performing some non-trade actions.
2) Publicize the fact that cheaters will be disqualified and punished. Periodically perform searches for accounts being used to dump bad players and investigate. Ban/disqualify cheaters and publicize the bans so that people know the rules are being enforced.
No method would be foolproof but the threat of punishment should minimize cheating.
actually you can use fingerprintjs to track every user, use js encrypt the fingerprint in browser and decrypt in server