Manager and Worker classes will add the fields necessary to implement their

interrelationships

For this task you will create a number of classes that provide information about the personnel in an organisation. You will write a Manager class and a Worker class, each of which will subclass a Person class. A Person will have a name, just a String, and an identity number, which is an integer. As no-one is just a person, the constructor of the Person class will only be used by constructors of derived classes. The name will be provided when an instance of a derived class is created. The identity should be automatically generated during construction and must be unique. No person, either manager or worker, can have the same identity number as another person. You should also ensure that the identity numbers of managers and workers cover separate ranges of integers (e.g. 1 – 99 for managers and 100 – 999 for workers), so that an identity number can be used, in the human organisation but not in your program, to discern whether a person is a manager or a worker.

There is a relationship between managers and workers that needs to be incorporated in the

corresponding classes. Each manager is the leader of a team of workers. In particular, a manager leads

exactly one team and a worker belongs to exactly one team. The system must allow for workers to be

moved from one team to another, managers to be moved from leadership of one team to leadership of

another, as well as for the appointment and retirement of personnel. For the current assignment task a

simplifying assumption will be that we do not need a class to represent a team’s work area. Instead the

manager-worker relationships will be incorporated by each Manager object maintaining a list of

Worker references, representing the team, and each Worker object maintaining a Manager reference,

representing the team leader.

The following state and functionality should be provided for these classes:

The Person class will maintain name and identity fields, as described above, and the derived

Manager and Worker classes will add the fields necessary to implement their

interrelationships.

Appropriate constructors will allow the name and identity fields of Manager and Worker

objects to be initialised properly. Note that, although the identity field will be inherited,

its initialisation depends on the particular derived class. Full initialisation of the fields

implementing manager-worker interrelationships would not be done at this stage, but they

must be in an appropriate state for testing.

Getters for fields will be provided in appropriate classes.
Appropriate toString methods will be provided as required to simplify the display of object

state. Where an object’s state contains a reference to a person, include that person’s identity

number in the string.

For setting up, changing, or nullifying the field values implementing manager-worker

interrelationships you need to make changes in the state of both a Manager object and a

Worker object. There are different ways to do this. For example, for moving a worker

between teams, one way is to provide the Worker class with a movetoTeamOf instance

method that accepts a Manager reference. The code of this method could first make some

checks (e.g. are either of the current and new Manager references null or are they the same?)

before removing the current worker from the team of the current manager, changing the

worker’s manager and then moving the worker to the new manager’s team. Note that this

would access instance methods of Manager for removing a worker from a team and for

adding a worker to a team. A similar approach applies for setting up a new worker and for

removing a worker from the system; the changes must be done so as to ensure the

information system remains in a stable state, which cannot be left as a responsibility of client

code.

Changing team managers is another operation on manager-worker interrelationships that

needs to be done, and with care. It might be implemented via a switchTeams instance method

of the Manager class that accepts the reference of another manager, but you need to make

sure that this switches all the Manager references held by the respective teams. You also

need to implement functionality for removing a manager from the system, which will only

occur if a newly created manager is available as a replacement, and adding an additional

manager, whose team could then be populated by client code applying some combination of

creating new workers and moving workers using functionality described above.

Write a TestPersonnel class to test the functionality of the classes you have developed. It will be done

without user interaction and will provide the following sequence of actions, using good design techniques such as in the appropriate use of methods:

Create a single list for the people in the organisation, which is a list containing Person

references for managers and workers.

Provide code to create some managers (3 will do) and some workers (12 will do) and add

them to the list. Assign the workers in turn to the different managers.

Display the state of all the people in the organisation.
Add 3 new workers to the organisation, assigning them in turn to the different managers.
Display the state of all the people in the organisation.
Remove from the organisation the first 2 workers in the list of people.
Display the state of all the people in the organisation.
Add a new manager to the organisation, reassigning the first worker in the list of people to

this new manager.