Newbie trying to create first use case diagrams etc...?

[Gramma]

I am trying to do my first use case and class diagrams...My first questions is...from all the information I am given how do I determine who the actors are? My project is to create a new automated system for a store. There are customers and employees (owner, manager, shippers). Would these be considered my actors. Each employee can perform certain tasks(add, delete,edit,void) with the owner being able to perform all tasks relating to customers, sales, inventory and payments. Also, transactions can either be a purchase by a customer or a purchase by the store to acquire inventory. After creating the use case diagram I am then to find the initial Problem domain classes and then to create class/sequence diagrams relating to Sell Product. Any guidance qould be appreciated..
P.S. I am not looking for someone to do it for me I am just wanting to know if I am on the right track. I have actually created a diagram but am unsure if I did it correctly. I have customers, owner, manager and shipper as my actors and then I have use cases for each of these..For cutomer I have create order and make payment for the rest I have broken it down into subsystems for transactions, inventory and customers each with add, edit, delete and void. I don't think I have done it correctly. I am also unsure of how to determine my classes. I can do the diagram once I know what my classes should be because I know how to determine my attributes etc..This stuff is just plain frustrating..lol

 

[Geaerefeieeeled]

The actors are anyone or anything that interacts with the system or request an operation from the system. They could be people, and they could be devices.

Regarding your actors, I think you are in the right track. However, I highly recommend you to use "inheritance" relations with your actors. The inheritance concept is very simple, if actor A inherit from actor B, then actor A can do all the operation actor B can do. (See the link below for more info)

For example, you said the owner could do the operations the manager can do. In that case instead of drawing the same operations for the manager and then drawing them again for the owner. You draw your manager, then draw the tasks he can perform. After that, you draw your owner and make him inherit from your manager.

As I said, the actors are anything requests an operation from your system, and that's the key to identify them. First, start by modeling the most general actors, such as Employee and Customer. Then, draw their operations. If you saw that there is a need to break these actors down, then do it by breaking Employee into Manager and Cashier for example. Repeat that process until your diagram makes sense.

Regarding the tasks, it differ from one person to another. You may model a very abstract use case diagram, while someone else might model a very detailed one. For example, you said you just drew a "make payment" use case which is very general. Some one else might break it down into a detailed cases, while a third one may draw it into even more detailed cases! It really depends on your project. However, it is a good practice to draw a very general model and when you are 100% satisfied with it, you break it down into a detailed one, and then into a detailed one and so forth.

Note that in the Software Engineering world, and especially when it comes to diagrams, there is no right and wrong. I might model a totally different diagram than yours, and yet, we are both right! The most important thing is to keep it logical.