I've done a lot of consulting on use cases and it has always been very problematic topic and hard to learn and master. It is definitelly a good idea to consider some other method to specify reqs and system functionality (like UI prototypes, wireframes, etc). In theory use cases are really neat tool, but in the practice it is ofter hard to learn, time consuming, unclear, confuses the team and the customers, hard to check/verify, even harder to keep updated, etc.
I've tried to clarify these two relationships here, using your example, slightly extended to cover both relationships and put the emphasis on the differences:
Note that "Place order" use case will have several scenarions, two of which are relevant here:
- "Place Order" with previous Authentication - in this scenario the "Authenticate" UC will not be invoked
- "Place Order" with no previous Authentication - in this scenario the invocation of the "Authenticate" is MANDATORY in order to place the order successfully.
Very frequent source of confusion and mistakes in UC modelling arises from this situation. Some modellers think that MANDATORY in the context of "include" means that it must be ALWAYS executed in the context of including UC, in every single scenario. If it is not the case (like here, there is only one scenario when it is mandatory) they use extend. This is an error, as it is enough that a UC is mandatory in at least one scenario. These details are not shown on the diagram level, but rather in the scenario descriptions.