This use case diagram isn’t what I would consider correct.

First, Login isn’t a use case. Use cases capture goals that an actor has when interacting with a system. Although logging in (and other forms of authentication) may be a prerequisite for achieving a goal, it isn’t a goal itself. That is, no one uses a system to log in and then says that they’ve accomplished their goal. Because of this, there is no need to include Login as a use case on a diagram and it often adds clutter, making the diagram harder to understand.

Second, meta use cases don’t belong. Again, each use case represents a goal. Because “pharmaceutical company management” isn’t a specific goal that an actor has, it isn’t a good use case. You seem to be using a use case to organize other use cases, which isn’t their purpose.

However, as always, I would generally discourage use case diagrams. To quote Martin Fowler:

Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value – the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.

Instead, I’d point to various textual and tabular methods to capture use cases. Alistair Cockburn’s Writing Effective Use Cases is one of the canonical texts going into detail on using use cases, including various formats and structures that may be useful.

There is an appropriate way to use the include and extends functonality.
(Many of the firms that provide UML diagramming tools have good tutorial
sections. I found the one for IBM’s Rational Software Modeler at
ibm.com/docs/en/rsm/7.50 apropos to the original poster’s needs.)

“Add Pharma Company” and “Edit Pharma Company” may have common features
as pharmaceutical company management functions. Perhaps it may just
be a look and feel. (Note, if pharmaceutical company management were
a separate system, one might put a box around it.) In that case one
can use the extends relation to indicate that. (Note that this is the same
as extending a class in a UML class diagram, if A and B use common features,
it may be appropriate to have them extend something (a C), whether they
be classes or use cases.)

It is appropriate if several use cases use a common functionality
like logging in, then the < is appropriate. But one
would have the pharmaceutical management functions <>
I did not do it, but it would be very appropriate to have the
super use case “Pharmaceutical Company Management Function” have the
<> arrow to the login function.

Of course, as several of the people making comments pointed out,
we all know that one must log in to a system prior to doing anything
else. Thus,
it might be superlative to indicate “<>” for login. But that
is a style issue whose discussion is beyond the scope of THIS forum.