Comments on your own analyse
I was thinking the that renters and car company should be association
Yes, this makes sense: a renter may be a customer of a car company, and reciprocally, a car company could serve several renters. Renters are not owned by a car company and reciprocally.
and car company and renters renting cars should be composition.
No: composition means exclusive ownership, and that the composed objects would in principle not survive the composite. But here, if a car company is destroyed, the renters may stay and simply go to other car companies. So no composition.
Published solution's aggregation vs. your associations
solution shows all the relationships are aggregation.
The relations that you describe seem to correspond to UML associations. The fact that the published solution uses aggregation is not necessaritly false, but it’s not recommended:
From the point of view of the UML specifications, the semantics are not clearly defined. So there’s no real benefit to use aggregation in a design model. See UML 2.5 p.110:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation.
(...) Precise semantics of shared aggregation varies by application area and modeler.
From the point of view of the designer, aggregation is a purely conceptual notation that does not fundamentally change the meaning of the diagram. For this reason, James Rumbaugh, a founding father of UML, once called aggregation a “modelling placebo”. I found back the quote in the book "Unified Modeling Language Reference Manual", chapter 14:
Keep in mind that aggregation is association. Aggregation conveys the thought that the aggregate is inherently the sum of its parts. In fact, the only real semantics that it adds to association is the constraint that chains of aggregate links may not form cycle (...) In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo.
On the implementation side, object composition is one of the basics of OOP. Some practitioners and academics tend to represent object composition with an UML aggregation to show that the the aggregated element is a part of a whole aggregate (the UML composition would be too restrictive, especially for languages in which classes have reference semantics, as Java or C#). This argument is however discussable because the design should not be driven by the implementation techniques. Moreover, modern UML's dot notation expresses those semantics much more accurately.
Some really discussable choices are made on the solution diagram: If we take the example of the Renter and the Rental, from a design point of a renter has some rental contracts and would probably need to find them back. After all, the rentals are a part the renter business role. Conversely, from a contractual point of view, the renter is a party of the contract. So one could defend an aggregation in both directions, but you cannot have an aggregation on both sides at the same time. The arbitrary choice to show only one side of the truth could be confusing. And adding two aggregations in the opposite direction would not appropriately show that in fact it's the same relation. Another argument to avoid aggregation whenever possible.
Conclusion: since there’s no objective criteria to decide when to use aggregation, and in view of absence of other significant impact of using aggregation or association, just keep it simple: ignore aggregation when you read it in a diagram, and yourself, avoid using it in your own diagram and prefer association instead.
