Admin class should not have addParkingFloor/addEntrancePanel/addExitPanel funcs?

My point is that ParkingLot class should have these functions, admin should be an account only with set of permissions to add/modify/remove instances from the ParkingLot, and the verification for these permissions can be done on the front end once an admin login. during the login the admin get back an api_dev_key use this key to make requests for addParkingFloor/addEntrancePanel/addExitPanel…ect and all this done on the AdminPortal.

This also lead us to the point to question why ParkingLot class should have CustomerInfoPortal and ParkingAttendantPortal as instances. Because I am thinking on the way around the CustomerInfoPortal and ParkingAttendantPortal should have an instance of the ParkingLot just like the AdminPortal as we say earlier should has an instance of the parkingLot. My understanding of the portal here is that the customerInterface/ParkingAttendantInterface/AdminInterface will communicate directly into the these portals. To make it more clear, customerInterface <=> CustomerInfoPortal, ParkingAttendantInterface <=> ParkingAttendantPortal , and AdminInterface <=> AdminPortal [ <=> means bidirectional communication requests goes back and forth]
Also ParkingLot should have a database instance since we are doing adding/editing/removing object from ParkingLot, so we need to reflect that on the database as well by using this instance.

**** From the explanation above, I am suggesting that the class diagram has some flipped arrows between ParkingLot and CustomerInfoPortal,ParkingAttendantPortal,and AdminPortal(which is missing from the diagram).

@Design_Gurus what do you think?
Please give me your opinion on this. I really need it.

Thank you very much