XYZ company consists of ten people, including nine employees and one owner $($Craig$).$ The owner is not

considered as an employee. All ten people share these three attributes: name, age, and title, but the

employees also have a salary attribute. Non$-$sharable attributes can be added freely. For the nine

employees, John and Mary are managers, Jane and Joe are accountants, and the others are blacksmiths

including Jack, Katie, Amy, Lin, and Greg. Employees of the same job title have an identical start$-$up

stipend. The salary can grow over time above the start$-$up stipend according to the individual

performance. The start$-$up stipend is $$50,000$ for manager, $$45,000$ for accountant, and $$35,000$ for

blacksmith.

The owner can send a text message to multiple employees at a time through a method. When out of town,

the owner can assign the duty to either a manager or an accountant. A manager can evaluate the

performance of an accountant or a blacksmith and ranks a Likert scale between $1$ and $5.$ When a manager

is out of town, the evaluation duty can only be handled by the owner or another manager only. An

accountant can update the salary of an employee at a time. When out of town, an accountant can only ask

another accountant for help no others. Very importantly, only accountants can update salary for

employees, while the other employees can view not update their own salary. Only a blacksmith has a

method to perform on an assigned task object as input. A task object has an ID$,$ due date, and description

as the attributes. When out of town, a blacksmith can ask any one of the employees to help perform on the

assigned task. For simplicity, assume one person can do only one extra work besides his own work.

Provide a UML class diagram for the system design. $(5$ pts$).$ All shared attributes are default to be private,

and the classes must include Company, Employee, Owner, Manager, Accountant, Blacksmith, and Task.

Each type of person class can have only one of these private methods: send, evaluate, update, and

perform. All the methods just need to get to the point by printing out a simple message. The design

should provide suitable arguments to the methods if needed. Feel free to add interfaces, abstract classes,

and supporting methods into the design, but no extra classes. Please model the relationships, multiplicity,

and visibility. To achieve good software reusability, it is important to minimize the number of association

links and stay away from direct associations among Owner, Manager, Accountant and Blacksmith classes.

For example, an association from Owner to Manager is a direct link but from Owner to the Manager$$s

superclass or supertype is an indirect link.