OO diagrams - the use case diagram
The use case diagram gives a pictorial representation of all the external systems or people (usually called 'actors') who interact with a particular system, the range of functions that they will need when they interact with it and how the functions themselves interact with each other. Generally, this type of diagram describes what a system must actually be able to do (the 'use cases') and the people (or systems) involved who must use it (the 'actors').
Use case diagrams are a really good starting point for any project, and as such, are usually produced in the early, planning stages. It gives a clear summary of the actors in a system and the main processes that need to be designed. If a use case diagram is done properly and completely, what you actually end up with is essentially a Requirements Specification for the system you are going to build.
Use case diagrams provide an overview, which can be used by a team of designers as the basis for checking that all the major areas in a system have been covered and that all the relevant actors have been included. They can then also use this diagram to help them to go on to design and plan further, more detailed work.
Suppose we wanted to model the process of preparing to go to university. You can see in our first draft use case diagram that there are a number of different 'actors' who interact with the system. Apart from the student, there is the bank, the Student Loan Company, the Finance Office at the university and the University Admissions Office. The student will have to set up a bank account, apply for grants, loans and courses. The Student Loan Company will have to receive and process applications and then pass grants and loans to students via their bank, and will also have to pay students' university fees direct to the universities.
The Admissions Office in each university will have to receive applications, process them, arrange interviews and report back to students with offers or rejections.
Whenever a student starts an application for a course, they will have to set up a new account. They will only do this once, the first time they visit the system. If they are a new applicant, then they must do an additional use case of creating a new account. This will involve entering in personal details, contact details, predicted grades, selecting a username and password and so on. You can see that because this use case is conditional (on them being a first-time visitor), we extend 'Apply for Uni course' to 'Create new account' by using <<extends>>.
Whenever a student wants to track their application, they will have to login and their login and password will have to be verified. This is not optional. It must happen each time they view their application. We therefore use <<includes>> to include a non-optional use case.