UCDs have only 4 major elements: The actors that the system you are describing interacts with,

the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements. Example: A UCD is well suited to the task of describing all of the things that can be done with a database system, by all of the people who might use it (administrators, developers, data entry personnel.)

Example: In the diagram below we would like to represent the use cases for a camera. Suppose we choose "Open Shutter", "Flash", and "Close Shutter" as the top-level use cases. Certainly these are all behaviors that a camera has, but no photographer would ever pick up their camera, open the shutter, and then put it down, satisfied with their photographic session for the day. The crucial thing to realize is that these behaviors are not done in isolation, but are rather a part of a more high-level use case, "Take Picture". (Note that it does make sense for a photographer to "Take Picture" just once during a session with their camera.)

System : The system box only appears on the top-level diagram.

The actors do have interactions. How do I represent them?

If there are interactions between the actors in your system, you cannot represent those interactions on the same diagram as your system. What you can do instead is draw a separate UCD, treating one of the actors itself as a system, and your original system (along with the other actors) as actors on this new diagram.
The uses arrow (or uses edge as it would be called in traditional graph theory) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case

Difference in uses and extends :

What is the difference between uses and extends?

Probably the best way to think about these diagram elements is as follows: - "X uses Y" indicates that the task "X" has a subtask "Y"; that is, in the process of completing task "X", task "Y" will be completed at least once. - "X extends Y" indecates that "X" is a task fo the same type as "Y", but "X" is a special, more specific case of doing "Y". That is, doing X is a lot like doing Y, but X has a few extra processes to it that go above and beyond the things that must be done in order to complete Y.
State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system.

When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case.

How to Draw: State Diagrams

State diagrams have very few elements. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state. The activity section of the state symbol depicts what activities the object will be doing while it is in that state.

All state diagrams being with an initial state of the object. This is the state of the object when it is created. After the initial state the object begins changing states. Conditions based on the activities can determine what the next state the object transitions to.

Associations Classes can also contain references to each other. The Company class has two attributes that reference the Client class.

Although this is perfectly correct, it is sometimes more expressive to show the attributes as associations.

The above two associations have the same meaning as the attributes in the old version of the Contact class. The first association (the top one) represents the old contactPerson attribute. There is one contact person in a single Company. The multiplicity of the association is one to one meaning that for every Company there is one and only one contactPerson and for each contactPerson there is one Company. In the bottom association there are zero or many employees for each company. Multiplicities can be anything you specify. Some examples are shown:

0 1 1..* 1..2, 10..*

zero one one or many one, two or ten and above but not three through nine

UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links. Our class diagram has three kinds of relationships.

association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes. aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of OrderDetails. generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit.

An association has two ends. An end may have a role name to clarify the nature of the association. For example, an OrderDetail is a line item of each Order.