In short, there's no real right or wrong answer here: it's one of those things where its up to your work style and work flow. Personally, I like to take all the users that could possibly ever use my system, and then list them out.
- Parent
- Student
- Teacher
- Administrator
Then, I write ALL the different things those users would want to accomplish for my system
- Parent
- Register Child/Children (Could be more than one child)
- Student
- Teacher
- View student's who've registered for their class
- Administrator
- Register Students
- Move student's to different sections
Finally, each one of those behaviors becomes a use case, with main flows, and alternate flows, such as a parent entering an invalid class, or an administrator trying to move a student into a full section. You may find that some of these use cases are very similair and that's fine, feel free to combine them. At least this way you know you aren't missing any!
Although I generally agree with Bart van Ingen Schenau's answer, I think a few points need additional elaboration.
Th advantage of the 4+1 View Model is that it maps stakeholders to the type of information that they need, without requiring specific modeling notations to be used. The emphasis is on ensuring that all groups have the information to understand the system and continue to do their job.
The 4+1 View Model of Software Architecture was described in Philippe Kruchten's paper Architectural Blueprints - The "4+1" View Model of Software Architeture that was originally published in IEEE Software (November 1995). This publication doesn't make specific references to UML. In fact, the paper uses the Booch notation for the logical view, extensions to the Booch notation for process view and development view, calls out the use of "several forms" of developing a physical view, and a new notation for scenarios.
Instead of trying to map each of the views to particular types of diagrams, consider who the target audience of each view is and what information they need. Knowing that, look at various types of models and which one(s) provide the required information.
The logical view is designed to address the end user's concerns about ensuring that all of their desired functionality is captured by the system. In an object-oriented system, this is often at the class level. In complex systems, you may need a package view and decompose the packages into multiple class diagrams. In other paradigms, you may be interested in representing modules and the functions they provide. The end result should be a mapping of the required functionality to components that provide that functionality.
The process view is designed for people designing the whole system and then integrating the subsystems or the system into a system of systems. This view shows tasks and processes that the system has, interfaces to the outside world and/or between components within the system, the messages sent and received, and how performance, availability, fault-tolerance, and integrity are being addressed.
The development view is primarily for developers who will be building the modules and the subsystems. It should show dependencies and relationships between modules, how modules are organized, reuse, and portability.
The physical view is primarily for system designers and administrators who need to understand the physical locations of the software, physical connections between nodes, deployment and installation, and scalability.
Finally, the scenarios help to capture the requirements so that all the stakeholders understand how the system is intended to be used.
Once you understand what each view is supposed to provide, you can choose what modeling notations to use and at what level of detail is required. Bart's last paragraph is especially true - you can show various levels of details in your UML models by focusing on particular design elements or combining various types of diagrams into a set. In addition, you may want to consider going beyond UML to other modeling notations to better describe your system architecture - SysML, Entity-Relation modeling, or IDEF.
Best Answer
TL;DR
Yes. You can have separate UC diagrams focusing on different parts (functionalities) of your system and one of options is to split them by involved actors.
Explanation
When you describe a system what you do is creating a model. A model is an abstraction of the actual thing (in this case of the system) intended to represent properties of the actual object. We're used to physical models, like scale model of a plane or car. There are also various reasons to build a model. You can build a model to show how something is going to look like or to test some physical properties (like aerodynamic drag).
Using an abstraction definition, a plan of a house, while might not be perceived as such, technically is also kind of house's model.
UML is intended to build models of systems (not only computer systems, however this is the main usage). To represent the system you need to model its various aspects and while the system is not a physical object the model has a form of diagrams depicting those aspects. A single diagram focus on a specific aspect of a system and to get the whole idea you need to study all of them. Thus all diagrams of the system combined constitute a model.
It's difficult if not impossible to show all aspects of even a simple system on a single diagram. Actually the number of diagram types comes from the fact that they focus on different aspects of the system, e.g. class diagram focuses on static data structures while activity diagram or state machine diagram focuses on changes of the system over time. It creates natural layer of abstractions and aspect borders.
But it is not the only limitation of modelling. To make it efficient model has to be understandable. with increasing complexity of the system it becomes impossible to depict all the information of one kind (e.g. data model or system functionalities) on just one diagram so to keep things clear those can be further split into smaller diagrams, adding new aspects. For classes it can focus on main business areas. For functionalities one of good options is separating the diagram by actors involved.
If you read into details of UML specification it clearly states, that the information on a single diagram is hardly ever complete information for the whole system. Even a full model might not cover all details.
So feel free to organise your diagram in a way that is most efficient to use for you and other stakeholders involved. And yes, of course you may produce multiple UC diagrams for a single system as long as they are consistent.
Notes
If you look at the UML specification, the class diagrams there represent the whole UML language model. Of course they are split into multiple class diagrams as otherwise they would be totally unreadable.
If you take any CASE system (like Enterprise Architect, Visual Paradigm, Rational Rose or even StarUML) you will find a difference between model and diagrams. Elements that you put on your diagram become parts of your model (usually visible in a form of a model tree) but it's not enough to remove element from a diagram to remove it from the model. Moreover if you drag two related elements from a model on a new diagram, they will automatically show with the relationship already presented.