If I read your question correctly, you're concerned about synchronizing the class select boxes that show up in the class and pupil create modules and the view filter. IMHO, you're question stems from a larger problem.
You have chosen to expose the properties of multiple actions on the page at one time. Before trying any solutions to the specific issue, ask yourself:
Do the users really need to see all of those choices all the time?
If this answer to that question is yes
On the surface, it seems the class value in the create actions should be kept in sync with the view. That keeps the teacher in the context they are working on: "I'm looking at 7a and I need to create things for 7a." If they choose to step out of that context for a moment, they can change an individual value.
Once a class value has been changed for creation, you have to rely on user feedback and testing to find out if the changed value should remain unsync'd for multiple adds or revert to the current view's value. It's hard to imagine that creating for another class should also change the view, but your users may tell you otherwise.
If the answer to that question is no
Without knowing your users, there appears to be a lot of opportunity for reduction. You don't want to slow users down, but your they might find a more focused view easier to learn and master.
download bmml source – Wireframes created with Balsamiq Mockups
In this revision, when an action is taken (eg, add student) the relevant properties pop in a modal. When a row is selected, actions are populated in an overlay at the bottom of the table (or fixed to the bottom of the currently visible rows, if your table can extend below the viewport).
The simplified UI I've outlined could work well for all users, but power users are often core to "back office" applications. For those highly engaged users, it's important to back actions with key sequences so they can move effortlessly through a given workflow.