In order to better discuss the image, I annotated your image with some numbers. Hopefully this will help me be more clear in my writing.
There are really three types of lines used here - association (1), composition (4->2), and inheritance (3).
A solid line connecting two classes, such as between
BookComponent is simply an association relationship. It is often used to indicate that a class knows about (perhaps as in receives as an argument to a method) or has another class (perhaps as an instance variable). Without any decorations or with an arrow on both ends, the relationship is bidirectional - the two classes share the relationship and know about each other. In some cases, such as line 1 in the figure, the relationship is directional. The
Client class knows about
BookComponent, but the opposite is not true as
BookComponent does not have a or know about
Client. Note that there are also other annotations that can appear on association relationships, such as multiplicity or class roles.
The next line is the line that connects
BookComponent. It's an association, much like the line between
BookComponent. However, the annotations at the points I labeled 2 and 4 add additional information about the relationship. Line in point 1, the arrow at point 2 means the same thing -
BookComposite is aware of
BookComponent instances, but not the other way around (a directional relationship). The annotation at point 4 indicates an aggregation relationship -
BookComposite is a collection of
BookComponent. However, it's not a strong relationship (as is the strong composition relationship), so aggregation indicates that a
BookComponent can indicate in places outside a
BookComposite (you don't need a
BookComposite to have a
Something to note is that the arrow used to show directional associations is typically not a solid black arrow as shown in this image. I typically see it as an open arrow that looks more like a
v than what is shown in your image.
Finally, the point labeled 3 is the inheritance relationship that you mentioned in your question.
If you're interested in more about UML modeling, I'd recommend purchasing UML Distilled. It's a good book by Martin Fowler that covers class, sequence, object, package, deployment, use case, state machine, activity, communication, composite structure, component, collaboration, interaction overview, and timing diagrams.