1. A company wants a new software system to manage its financial affairs. Suppose the company makes regular payments to employees and service providers (other companies). There are many types of payment recipients. Therefore, it is necessary for the software to allow adding more kinds of companies in the future.

This software system will have a class called PaymentUnit. The details of the payments that need to be made will be delegated to classes other than the PaymentUnit class. For example, an Employee class can keep track of how many hours an hourly employee has worked. A UtilService class needs payment information provided by the service providers.

It is impractical to know all the possible types of payment recipients prior or during software analysis and design stages. That is, the PaymentUnit class must know what it needs from a recipient class for making a payment. Therefore, the interactions between the PaymentUnit class and possible recipient classes must be specified (supported) in the design.

Need to slove:

The IRecipient defines what a recipient must do to be accessible by PaymentUnit. The Employee class represents one employee. Since an employee should receive payments from the software system, the Employee class must implement IRecipient. There are at least two types of employees, salary and hourly wage employees. For salary employees, wages are calculated from a yearly salary. For hourly employees, wages are determined by an hourly rate and the number of hours worked. Call the salary employee class SalaryEmployee and call the hourly employee HourlyEmployee. All employees are paid on a bi-weekly schedule.

Develop a class diagram that specifies the classes for the employees. Show the implementation of the IRecipient, both in the class relationships and explicitly with the methods of each class.

Answer rating: 100% (QA)

Here is the class digram showing relationship between paymentUnit ... View the full answer