The question of inheritance vs instance depends on functionality. If there are any differences in your data model between ducks and other types of birds then you would want a Duck class that inherits from Bird. Otherwise you're looking at your duck simply as an instance of Bird.
Polymorphism only comes into play when you are calling the same method across different Bird implementations.
For UML modeling here are a couple points to help you out.
This book is required reading for many Software Engineeing courses and has served me well for many years.
This blog does a pretty good job of showing the different use cases and the corresponding OOP models. http://usna86-techbits.blogspot.com/2012/11/uml-class-diagram-relationships.html
This diagram you include is not strict uml. From what i can understand it means the following:
You have a class called ElectricFan
Your class has the following member variables (power, speed, maxSpeed, type, etc). In parenthesis i guess that the author has included the values applicable to each member variable.
Also, the author includes the methods that are applicable in this class (i.e. switchOnOff(), changeSpeed(), etc).
An important piece of information that the author doesn't include is the visibility and type of the member variables as well method arguments and return types.
If you are interested in learning more about UML you could start by reading Marting Fowler's UML distilled (http://www.amazon.com/UML-Distilled-Standard-Modeling-Language/dp/0321193687).
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...
Vacation
Location
Travel Agent
Schedule
User
Reservation
Reservation Service (This can be an interface for accessing the vacation reservation stuff)
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.
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.
The question of inheritance vs instance depends on functionality. If there are any differences in your data model between ducks and other types of birds then you would want a
Duckclass that inherits fromBird. Otherwise you're looking at your duck simply as an instance ofBird.Polymorphism only comes into play when you are calling the same method across different
Birdimplementations.For UML modeling here are a couple points to help you out.
This book is required reading for many Software Engineeing courses and has served me well for many years.
http://www.amazon.com/UML-Distilled-Standard-Modeling-Language/dp/0321193687
This blog does a pretty good job of showing the different use cases and the corresponding OOP models. http://usna86-techbits.blogspot.com/2012/11/uml-class-diagram-relationships.html
This diagram you include is not strict uml. From what i can understand it means the following:
An important piece of information that the author doesn't include is the visibility and type of the member variables as well method arguments and return types.
If you are interested in learning more about UML you could start by reading Marting Fowler's UML distilled (http://www.amazon.com/UML-Distilled-Standard-Modeling-Language/dp/0321193687).
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.
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
Regards,
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.