I'm a bit confused regarding Generalization, Aggregation and abstract classes in UML.
By Generalization, I can understand that it's a "is a"-relationship. A student is a Person - and a teacher is a Person. So Person would be the superclass, whereas student and teacher are both subclasses.
By Aggregation, this is what I understand: It's a "softer" relation compared to composition. An example could be: You can have a hand with no fingers (aggregation) but you can't have fingers without a hand (composition).
And then I am completely lost on abstract classes. What are the characteristics of abstract classes? I'd like an example on this if possible.
But am I on the right track here? This is how I understand these terms.
You understand Generalization.
Associations may be Aggregations or Compositions (or neither). This is a good example that Tom Pender used to use. Suppose you have a Car class. That Car class "has" a steering wheel, seats, two axles, four wheels, and so on. If you're creating that Car in a manufacturer context, the relationship between all of those would be Composition: the lifetime of all the car's parts (at your manufacturer) is tied to the lifetime of the car. From the standpoint of the manufacturer, the lifetime of the car and all its parts ends when you deliver it to a dealer.
Now, let's suppose you're the owner of a junkyard. In this case, a car still "has" all those parts, but they have a lifetime of their own: you can sell parts off of the car, and even make them part of some other car if you need to. The relationship between the car and those parts is Aggregation, because the lifetime of the parts isn't tied to the lifetime of the car itself.
So, you can see that the same car could actually be modeled in two different ways depending on context.
As for abstract classes: an abstract class is simply a class that defines methods and/or properties while requiring that they can only be implemented in subclasses. It's easiest to explain why with interfaces. Interfaces are abstract classes, with the added proviso that NONE of the methods or properties can be implemented directly in the class (you might say it's a definition of how to define a subclass). Here's where they come in useful.
Suppose I want to define an Animal class. What do animals do? Well, they move. They bite. (They do other things too, of course, but let's stick to Move and Bite.) If I create an Animal interface, I'm saying "here's what an animal does. If you want to be an animal, you have to also do these things. However, I'm not going to tell you how to do them." So, I create an iAnimal interface, with two methods, Move and Bite. As an interface, I don't provide any sort of implementation, just empty procedures.
Now, suppose I have two animals, a Flea and a TRex. Clearly, Fleas and TRexes don't have anything in common in the way that they move or the way that they bite, but they both do both. I'll have Flea and TRex inherit or "implement" the interface, providing implementations of Move and Bite appropriate for the type of animal.
The advantage of this is that clients of my flea and trex don't have to know which one they are dealing with. They can create an iAnimal, inject an instance of Flea or TRex as appropriate, and safely call iAnimal's Move and/or Bite methods without having to worry about whether they're supported or not. (This is what we mean by "polymorphism").
So, interface implementation is a form of Generalization (more correctly Specialization, going the other way), as you have probably already surmised.
From here, an "abstract class" is simply any class with any method or attribute defined that has to be inherited to be implemented. Therefore, as I have said, interfaces are abstract classes. However, in general usage, an abstract class is taken to mean one that is not also an interface, i. e. one that has some concrete methods or attributes. Most programming languages adhere to this definition.