What you call an attribute actually calls a field (I know, everyone learned wrong and teaches wrong).
If you have these two related classes you need to have a way to get to each other. At least one of them in one direction has to be sure, otherwise there is no relationship. If you need the other side, it depends. I don’t know what this is Hospedagem. When you access a hosting, do you need to find the related invoice easily? Then you have to have this field at Hospedagem. If you are going to access a receipt need to know which hosting it refers to? Then you need to have this field at NotaFiscal.
Then with Pedido and ItemPedido is the same thing. It always depends on what you want. As this is something better known it is almost certain that there is some indication about the items in the class Pedido. Depending on the solution may be some form of list somewhere, so it is a aggregation.
The list may be in the class Pedido and within the list are ItemPedido, at least everything indicates to be that by the description provided. There are other ways to deal with this.
Or any other way would be Pedido have only one reference to a class ItensPedido (note the plural) and this is where you would have this list. This can be useful because it may have some fields related to all items. It is not so common, it can conceptually be more interesting (the conceptual sometimes becomes too much for what it needs). One of these fields could be a reference for the Pedido, if necessary.
But looking at the way you’re doing, if each item should have a reference to Pedido will depend on whether you can access the items individually directly and need to know what order it belongs to.
Can help: Association, aggregation, etc. in practice?.
Did the answer solve your question? Do you think you can accept it? See [tour] if you don’t know how you do it. This would help a lot to indicate that the solution was useful for you. You can also vote on any question or answer you find useful on the entire site (when you have 15 points).
– Maniero