1
votes

I have a scenario for which I have to design a use case diagram, activity diagram and a class diagram:

“I run a small computer consultancy firm with a number of employees. Along with the basic information about the employees (name, DoB, contact details, etc.) I need to be able to keep track of what type of role they perform, such as Hardware Technician, Programmer, and Software Installer. A single employee can perform multiple roles, and each role has an associated hourly pay. I need to keep name and contact details of all customers that have a contract with us. A customer can have multiple contracts at the same time, but each contract is only associated with one customer. Each contract has a name, a description, a creation date, and a job type – e.g. System Development, Software Upgrade. No details of job types need to be captured other than their name. Each contract also has a single employee designated as the project leader. One employee may be the project leader of multiple contracts.”

I have tried to draw a use case diagram and I want to know if I have drawn it correct and if there are any mistakes or any improvements that should be made:

My Use-Case Diagram

1
In general this type of questions does not really fit the SO scope and it should be closed (I'm not voting yet). Let me just give you a hint though. Don't try to squeeze all the information into the UC diagram. Think what are functions of the underlying system. Who interacts with the system? What actions can a user do? From your list of UCs I would probably keep something like 3 in total, 2 of them with names changed.Ister

1 Answers

0
votes

Let's analyse your requirements, to identify use cases:

  • Manage employee

    I run a small computer consultancy firm with a number of employees. Along with the basic information about the employees (name, DoB, contact details, etc.) I need to be able to keep track of what type of role they perform, such as Hardware Technician, Programmer, and Software Installer. A single employee can perform multiple roles, and each role has an associated hourly pay.

  • Manage customer data (may be included in contract management)

    I need to keep name and contact details of all customers that have a contract with us.

  • Manage contracts

    A customer can have multiple contracts at the same time, but each contract is only associated with one customer. Each contract has a name, a description, a creation date, and a job type – e.g. System Development, Software Upgrade. No details of job types need to be captured other than their name.

  • Assign project leaders (may be included in contract management)

    Each contract also has a single employee designated as the project leader. One employee may be the project leader of multiple contracts.”

Now, more use case may be hidden behind these sentence and could be deduced. However, let's see critically if the additional ones you've identified fit.

The following seem ok at first sight:

  • Make contract (more precise than manage contract. On the other hand, what with contract modification and termination?)
  • Give contact details (par of manage contract)
  • Keep customer details (similar to manage customer data) but who 'd be the owner ?
  • Assign a project leader (see above)
  • Assign other members (excellent: not explicitly mentioned , but if employees are assigned to roles and hourly pay, it's certainly because it's relevant to assign them to projects)
  • Assign employees to project (see previous bullets)

The following use case are questionable:

  • Accept contract: will the owner of the contract (who is it: the customer ? the leader ? s.O. else ?) really accept it IN THE SYSTEM ?
  • Perform role: is it implied here, that the employees will use the system to perform their role ? Or will they just register some time for the projects ? Or will they not interact with the system at all ?
  • get paid hourly (same question)
  • Leading the project: will the project leader interact with the system to lead the project ? or is he/she just registered as leader for administrative responsibility purpose ?

Finally, some of these requirements go beyond the (goal oriented) use case, and describe the class model. Don't get trapped by this: the use case should focus on the actor interaction with the system.