In the following basic knowledge of UML 2.x is premised. If you are not yet familiar with UML then the UML® Resource Page of OMG  would be a good starting point to study.
Missing knowledge about the token flow in UML Activity Diagrams is a very common source of errors.
In Figure 1 a typical error is depicted. To execute an activity at each incoming connector needs one token - otherwise a deadlock will happen. In the wrong sample action X will wait for ever. Correct is an additional Merge Node before the action X.
A innocent question like 'How would you implement this in Java?' shows your real knowledge about token flows in UML 2 Activity Diagrams.
A similar token flow problem happens in Figure 2. Here the start node has two edges. This means that it is not clear if action X or Y will be executed. In the correct version a Fork Node splits the token for both actions.
In the aggregation relationship (not filled diamond symbol) the object does not take part in the life cycle of the component object. So, the related OrderItems can outlive the destroyed instance.
In Wikipedia  you find a good sample:
"For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors. In addition, a Professor could work in more than one department, but a department could not be part of more than one university."
Knowing the exact difference between composition and aggregation is crucial for a lot of design questions.