Any low level diagrams automatically generated from source code are going to be useless. They'll be more obscure than your code, have a messy visual layout, and soon be out of date. Future developers will distrust them and look at the code instead, so you're better off investing the extra effort into refactoring your source code (ie, to use self-explanatory names, have a class structure that represents your problem domain cleanly, and so on).
It is worthwhile to create good javadoc or doxygen comments and keep them up to date: many people find these quite useful.
High-level diagrams also are valuable. Read Martin Fowler's UML Distilled and learn the UML notation. Then use Viso or another graphical editor to document just the parts of your software that would be helpful for future developers. Don't waste time making the diagrams "complete" and perfect, just focus on what will help other developers the most.
I would not say that your design, as you speculate, is totally wrong, in fact Administrator and End-User are valid domain objects that should be represented somehow in the Class Diagrams. Just because you identify those two entities as actors doesn't mean they should be excluded from the Domain, remember, your domain is your scope, or "relevant context", that is, the set of useful objects that play a relevant role in your solution.
You may start with basic objects that comprise your model, just write them down, without further analysis, like brain storming...
Then try to establish the relationships between those objects, if you can not find any relationship that means you are not choosing the right objects, if they are part of the same problem domain then they must be related somehow.
After some time, you will discover that there are objects missing, try to encapsulate as much as possible, and represent the correct abstractions, Design Patterns might help you out with that.
When every possible object is represented with all its properties and methods, then you should have a fully, although not yet finished, functional design.
I know you should have a lot of theory in your mind, so get going, without fear, I myself have used this approach successfully many times at work.
Finally get a copy of UML Distilled
See also Enterprise Architect Product Demonstrations and the UML Tutorials.
Keep in mind, this is a UML tool. It's possible that part of what you need is a step by step guide to understanding UML. If these tutorials don't help you, I suggest UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) by Martin Fowler. Before reading this book, I felt that UML was this huge, tangled ball of twine. This book showed me the starting point, from which I was able to unravel the ball of twine.