I'm trying to imagine how a use-case actor with multiple behaviors actually shows up in the application.
Take the following real world but oversimplified case:
An environmental consulting organization has a project manager responsible for: creating and managing clients; projects; facilities and buildings, and equipment and supplies. A lot of this is just CRUD, but there's quite a bit more.
Does it make sense to have a ProjectManager class with all the behaviors implied? Just looking at the use-case diagram, I can see 20+ methods that would be required.
Instead of putting all the eggs into a one basket, why don't you group responsibilities in different "roles" and then assign these roles to PM?
What I mean by that is, please bear with me and imagine:
Interface: CustomerRelations Responsibilities: customer related ops (e.g. create customer, keep good relations with them etc)
Interface: OfficeManagement Responsibilities: acquire necessary equipment to do business, and provide necessary supply to use them etc.
Interface: ProjectManagement Responsibilities: monitor and supervise projects etc
And them
Class: ProjectManager implements CustomerRelations, OfficeManagement and ProjectManagement.
This way, you can easily re-shuffle responsibilities around if need be.
