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?
Related
This is an issue we have ran into multiple times now... very much looking forward to others' opinions!
Scenario Description (for illustration purposes):
Somebody visits our website, perhaps they fill out some forms, whatever. To us, this person is a prospect/lead. They have not been fully onboarded as a customer; they are simply a potential future customer.
Certain actions can be performed on these Prospects, such as adding certain data to their profile. Let's call this add_foobar_data. Of course, if they become a real customer (somebody consuming our service), we still need to be able to add/remove said data from their account.
Scenario (tl;dr):
Prospects can become Customers
Mutation add_foobar_data conceptually applies to both Prospects and Customers
Prospects only have a subset of data of Customers (they are a true subset; currently Customers have a lot of non-nullable fields Prospects do not have)
Options:
Create a union type, e.g. Customerable. add_foobar_data would return a Customerable (or backref to a Customerable) rather than a specific type.
Create separate mutations for modifying Prospects and Customers (add_foobar_data_to_prospect, add_foobar_data_to_customer)
Everybody is a Customer! Make all those non-nullable fields on Customer that are not in Prospect nullable and add a new flag called isProspect (or isDraft if we want to change how we think about the flow).
Perhaps some other approach I did not think of...
Anybody have thoughts on what is the best approach to this situation and why?
Ended up using an Interface since Prospect is a direct subset of Customer, and not by coincidence.
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.
I read the following question and the proposed solution:
Immovable planning entities for chained entities
In our problem we would like to send a set of technicians and customer with their appointment windows to optaplanner with the following condition:
Some customers were already served or are being served, so all of them are already belonging to a certain technician who did (is doing) the work there.
It is similar to the following example:
I start the time dependent vehicle routing example and stop it far before the "best" solution is obtained.
Then I want to use this solution as input, whereby from each technician in the simplest case only the very first customer of the chain has to be set immovable (because he was already served), but all the others are still available for the rest optimization.
In the 6.2 reference manual, take a look at:
immovable planning entities: don't change the entities which are already assigned (= by locking them)
non-volatile replanning: prefer not to change the entities which are already assigned, unless the gain is worth it
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'.