I have big use case which is `Manage Orders`, I want to expand this use case to a more specific use cases.
when the user ask to manage the orders he can do many options which represent use cases, my questions is : is the big use case Extends the new use cases ?
The other way around. Specific sub use-cases extend the main use-case. Look at it this way: you always invoke the main use-case when you want to manage orders but the additional behavior may vary - check order status use-case extends the core functionality of the manage orders use-case. Same goes for the order orders. In you diagram the extend relation direction should be reversed.
Rule for usage include and extend: common parts that always present in the use-case can be extracted out (and optionally used by other use-cases) and included by the larger use-case. Optional parts that may or may not present in the use-case should be extracted and they extend the larger use-case.
As icepack explained, if you want to use extend then the relationship is drawn the other way around. But I am not sure I would use extend in this case.
In fact, a use case should always represent a real functionality. Here, Check order status and Order orders sure are use cases, but I am not sure Manage orders is. Are you sure it represents something on its own? Or is just a way of grouping the other two? In this second case, you should use packages.
To answer the question, imagine the scenario describing the content of your use case. If, for Manage orders, your scenario is little more than "choose between Check order status and Order orders", then Manage orders is not a use case.
