1. Designing A Payroll System A Solution Daniel POP, Ph.D

2. 2 Analysis by Use Case It is the systems behavior that we are creating, not the systems data; systems data is a consequence Use Cases (UC) are ways to capture systems behaviour –Similar to user stories (in SCRUM/XP) For our system, the UCs, what customer wants, are: 1.Add a new employee 2.Delete an employee 3.Post a time card 4.Post a sales receipt 5.Post a union service charge 6.Change employee details (e.g., hourly rate, dues rate, etc.) 7.Run the payroll for today

3. 3 UC #1: Add a New Employee Description A new employee is added by the receipt of an AddEmp transaction. This transaction contains the employees name, address, and assigned employee number. The transaction has three forms: AddEmp " " " " H AddEmp " " " " S AddEmp " " " " C The employee record is created with its fields assigned appropriately If the transaction structure is inappropriate, it is printed out an error message, and no action is taken.

4. 4 UC #1: Add a New Employee Inferred model Use Command pattern to model each possible type of transaction Command Enforces SRP

5. 5 UC #1: Add a New Employee Inferred model Q: What do the three transactions create? A: They create three kinds of employee objects

6. 6 UC #2: Delete an Existing Employee Description Employees are deleted when a DelEmp transaction is received. The form of this transaction is as follows : DelEmp When this transaction is received, the appropriate employee record is deleted. If the field is not structured correctly or does not refer to a valid employee record, the transaction is printed with an error message, and no other action is taken.

7. 7 UC #2: Delete an Existing Employee Inferred model

8. 8 UC #3: Post a Time Card Description On receipt of a TimeCard transaction, the system will create a time card record and associate it with the appropriate employee record: TimeCard The system will print an appropriate error message and take no further action.

9. 9 UC #3: Post a Time Card Inferred model

10. 10 UC #4: Post a Sales Receipt Description On receipt of the SalesReceipt transaction, the system will create a new salesreceipt record and associate it with the appropriate commissioned employee: SalesReceipt The system will print an appropriate error message and take no further action.

11. 11 UC #4: Post a Sales Receipt Inferred model

12. 12 UC #5: Post a Service Charge Description Service Charge may be pension contribution, health system contribution, union contribution etc. On receipt of this transaction, the system will create a service-charge record and associate it with the appropriate union member: ServiceCharge If the transaction is not well formed or if the does not refer to an existing service member, the transaction is printed with an appropriate error message.

13. 13 UC #5: Post a Service Charge Inferred model Because memberID and empID are not the same, the system must be able to associate union members and employees. There are many ways to provide this kind of association, so to avoid being arbitrary, lets defer this decision until later.

14. 14 UC #6: Change Employee Details Description Upon receipt of this transaction, the system will alter one of the details of the appropriate employee record. There are several possible variations to this transaction: ChgEmp Name Change employee name ChgEmp Address Change employee address ChgEmp Hourly Change to hourly ChgEmp Salaried Change to salaried ChgEmp Commissioned Change to commissioned ChgEmp Hold Hold paycheck ChgEmp Direct Direct deposit ChgEmp Mail Mail paycheck ChgEmp Member Dues Put employee in a specific service ChgEmp NoMember Cut employee from service If the structure of the transaction is improper, does not refer to a real employee, or already refers to a member, the system will print a suitable error and take no further action.

15. 15 UC #6: Change Employee Details Inferred model Lot of information in this UC: 1. The fact that the type of employee is changeable implies that the diagram inferred from UC #1 is invalid; the inheritance is not appropriate => need to use object composition instead; Strategy pattern is a good candidate for pay computation Strategy 2. The same approach can be used for method of payment (it is also changeable) 3. The same approach can be used for Service affiliation; but, because all these afiliations are optional, well use a NoAffiliation class for this (see NullObject pattern) NullObject All these patterns enforces OCP principle in our design

16. 16 UC #6: Change Employee Details Inferred model

17. 17 UC #7: Run The Payroll For Today Description On receipt of the payday transaction, the system finds all those employees that should be paid on the specified date. The system then determines how much they are owed and pays them according to their selected payment method. An audit-trail report is printed showing the action taken for each employee: Payday

18. 18 UC #7: Run The Payroll For Today Inferred model First, how does the Employee object know how to calculate its pay?

19. 19 UC #7: Run The Payroll For Today Calculate the pay day The system will sum up an hourly employees time cards and multiply by the hourly rate. Similarly, the system will sum up a commissioned employees sales receipts, multiply by the commission rate, and add the base salary. For Salaried employee, the system will pay the fixed monthly amount

20. 20 UC #7: Run The Payroll For Today Digging hidden abstractions Some abstractions are easy to find; for example, from Some employees work by the hour and Some employees are paid a flat salary we derived the PaymentClassification abstraction. Some others are hidden; for example, from They are paid every Friday, They are paid on the last working day of the month,, or They are paid every other Friday. we may derive the notion of Schedule of Payment, that is not specifically mentioned in requirement! One way of doing this is to compute whether a day is a pay day or not in the PaymentClassification classes …but this is violating 2 OOP principles: OCP and SRP

21. 21 UC #7: Run The Payroll For Today Digging hidden abstractions Instead, well do like this What pattern did we use?

22. 22 UC #7: Run The Payroll For Today Affiliations model revisited Old model New model (from UC #6) What patterns did we removed in the new model?

23. 23 Summary Final Design –Command –Strategy (*) Commands hierarchy is not depicted here

24. 24 Summary Java Sources This example has been (partially) implemented in Java Download the Java sources and binaries from the following address: http://web.info.uvt.ro/~danielpop/dp/payroll.zip To run the example, extract the zip file and execute run.bat file

25. 25 The Big Conclusion Of This Course Overreliance on tools and procedures and underreliance on intelligence and experience are recipes for disaster.