Use case diagram : distingishing the actor of a use case

first impressions:

I'd say your include arrows are the wrong way round, it's a little odd that Validate membership isn't included in extend return date? and I'd also be tempted to split these into two or three separate diagrams (so we don't have crossing lines).

However, I'd also say that take 'correct uml' with a pinch of salt, if the diagram is useful to you, and to what you want to communicate, then it is doing its job already.

There are two relationships in a use case diagram - include and extend.

The extend relationship is used when one use case adds behavior to another use case. In this situation, the base case would be executed. Then, depending on what happens during execution of that one use case, one or more other use cases could possibly be executed. Note that it's not required that an extension actually be executed - it's just a possibility. This also indicates some level of reuse between the features.

The include relationship is used when one use case includes the functionality of another use case. The specific behavior is not important, but the end result is, which means that the included use case could have a different implementation, but the same steps and end result. In this type of relationship, the included use case is usually not available as a stand-alone use case.

Looking at your particular example, I developed two use case models that I feel are more appropriate. In both, I changed the actor from "Member" to "Librarian". It appears that the person actually interacting with the software is not the library member, but the librarian.

In this example, the Librarian can perform two functions - check out a book or reserve a book. Both examples require the librarian to look up the book using the information provided by the member. However, the search functionality is not available as a stand-alone entity. I'm not sure that this is what you are going for.

In this example, the Librarian can perform three functions - looking up books, checking out books, and recording reservations. Both checking out books and recording reservations use the look up book use case, but add additional behaviors. The implementation details are left as an exercise for additional specification, but this indicates that the in order to either check out a book or place a reservation, the librarian must first look up the book. I believe this is more in line with the functionality you are describing in your question.