Both diagrams are ambiguous, because of the naming of the red and green use-cases that are specialisations of the yellow ones. The specialisation means that for example Article
is a kind of Manage
. This is ambiguous already grammatically, but also because your first diagram shows that articles could be managed and viewed. Moreover, use case names must be unique.
One easy way to improve this would be to rename the ones in red and green, by repeating the more general verbal group together with the specialised noun group, e.g. Manage article
. This will disambiguate the diagrams.
The next step will be to address the remaining flaws:
- The disambiguation will help you to understand that the second diagram doesn't provide anything explicit for viewing articles.
- The first diagram , manage does not include view, which is not aligned with your requirements.
- There should be an association for each of the yellow use-cases with the actor.
- The blue use-cases are not real use-cases (login is not a use-case, see for example here on another question). They are activities that do not belong to the use-case diagrams but into an activity diagram.
Your approach is very explicit but has one problem: it multiplies the use-cases unnecessarily, without bringing really added value, at least at first sight. A better alternative would be to stick to generic use-cases, e.g. Manage Item
, View Item
and explain somewhere that Item can be articles, invoices, etc... (See also on this other question here)