I'm trying to write a program that stores details of employees and maintains a rota for employees. I'm trying to use some sort of design process and improve my understanding of UML.

I've attempted to draw a use case diagram after writing detailed use cases...but it hasn't turned out well it's a mess and most of the examples I can find are too simple to use.

Can anyone give me any idea of where I'm going wrong with drawing the digram (attached)?

I'm not sure what other information to add.



This post has been edited by KeithJ108: 21 Jul, 2009 - 01:06 PM

KeithJ108,

I am not sure what you can add, but I think you could remove some of the use cases, as you are repeating yourself, "Set an employee's times available" & "Edit an employee's times available" are really the same thing, the same for employee's holidays, regular shifts and Add/Remove to/from rota. I would rename them all to "Edit <something>"

Where's the use case for the planning of the rota's for all employees? as the one you have there is for an individual employee, but a rota should be for a particular time period and therefore a number of employee's will be included.

Just my initial thoughts, but remember there is always more than one way to do something, so I could be right or I could be wrong it depends on the problem domain.

itlee.

itlee, thanks for the response

I was repeating myself, I had thought that was necessary to describe the functionality accurately, which most likely isn't the case. I have made the changes you suggested.

For the purposes of a use case diagram does it not matter that the word 'Edit' implies changing something that is already there? In my example, on first use, the information would be added not edited.

What I was trying to represent with rota was that when the employer added an employee to the rota they would select which employee to add. I was planning on the employer selecting a date from a calendar and then choosing which employee to add to that date. What is it about the diagram that implies it is for an individual employee?

Is there an excessive number of includes/extends relationships in the diagram? I'm just wondering if there is a clearer way to represent the relationships.

Thanks,
Keith



This post has been edited by KeithJ108: 22 Jul, 2009 - 03:46 AM

KeithJ108,

For me "Edit" means adding, changing and removing/deleting, but that would depend on the "glossary" used in the problem domain. I always try to add a glossary to my documentation to cover this kind of thing.

I see now how you were doing the rota, missed it on my first look. I was thinking about how I would implement a rota by selecting a time period, finding the employees available for that time period then assigning them a "slot" in the rota either manually or based on a set of rules.

As for the readability of the diagram, you could have a 1st level use case with the ones from the left of your diagram, and then another level that describes the includes/extends for each of the 1st level.

itlee.

Hi,

Your use case diagram has too much information. The top level of a use case diagram must not have more than 5-6 usecases, which illustrate the most important functionality of the system. When you go to the next level of use case diagram, you have to be doing one each for these top level use cases. There is also plenty of information in your use case diagram that can be generalized.

Refer to the book 'Applying UML and patterns' by Craig Larman if possible.

Sandhya