Skip to main content

Use Case 1 - Adding a new employee.

Use Case 1 - Adding a new employee

A new employee is added by the receipt of an AddEmp transaction. This transaction contains the employee's name, addess, and assigned employee number. The transaction has the following three forms:

$ AddEmp <EmpId> "<name>" "<address>" "<address>" H <hourly-rate>

$ AddEmp <EmpId> "<name>" "<address>" "<address>" S <monthly-salary>

$ AddEmp <EmpId> "<name>" "<address>" "<address>" C <hourly-rate> <commission-rate>

The employee's record is created with its field assigned appropriately.

Alternative:
An error in the transaction structure
If the transaction structure is inappropriate, it is printed out in an error message, and no action is taken.

Requirement Analysis​

The Use Case describes various ways how Employee-data can be added to the system. AddEmp could be implemented as a polyadic function that receives 6 to 7 arguments, describing an Employee's personal information and the salary the Employee_receives, and the type of _salary (H, S or C). If the salary type is C, an Employee requires an additional commission-rate. Obviously, errors happening during transactions must be treated with care, appropriate error messages should be displayed. This is particularly important for the input provided by the client, e.g. salary types must be validated as well as the rates; also, check if empIds already exist and prevent multiple occurences of the same empId.

Takeaways​

  • validate user input:
    • empId: existing? valid format?
    • salaryType: is it one of H, C, S?
    • salary should probably be greater than 0
  • display error messages if a transaction failed

Actors​

Accountant - adds a new Employee to the system.

Figure 1 Actor "Accountant" carries out the "Add Employee"-Use Case.

The Actor carrying out the Use Case is an Accountant. Of course, any other "role" would be eligible, but since the system exists in a Domain dealing with Accounting, I assume Accountant describes (a part of the) target audience of the system quite well.

Design​

The initial design should consist of 3 parts: An Application Layer, a Repository for managing transaction-calls and an Employee-Entity.

  • Payroll exists in the Application Layer and is the main entry point for interacting with the system, in the form of a traditional Facade.
  • The Repository would be the EmployeeRepository and encapsulates the required infrastructure for persisting Employee-Entitys.
  • The Entity would be the Employee itself.