thinking of using an interface for company and an abstract class for employee and connecting mangers,accountant and blacksmith not sure where to put owner and would like assistance with properly placing the task object class.

XYZ company consists of a number of people, including nine employees and one owner (Craig). All ten people share these attributes: name, age, title and salary. 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. When out of town, the owner can assign this duty to one of the managers only. A manager can evaluate the performance of accountants or blacksmiths one at a time and ranks a Likert scale between 1 and 5. When a manager is out of town, the evaluation duty is handled by another manager. An accountant can update the salary of an employee at a time. When out of town, an accountant asks the other accountant for help no others. Very importantly, only accountants can update salary. A blacksmith can perform an assigned task object. A task object has an ID, due date, and description as the attributes. When out of town, a blacksmith can ask a blacksmith, a manager, or even an accountant for help to work on the assigned duty. 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 must be private, and the classes must include Company, Employee, Owner, Manager, Accountant, Blacksmith, and Task. Each type of person class should not have all four but only one of these methods: send, evaluate, update, and perform. The design should provide suitable arguments to these methods. 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, please reduce the number of association links and stay away the 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 Managers superclass or supertype is an indirect link.