authorizationumlmodelinguse-caseuse-case-diagram

Different type of user extends use case


I am making a UML graph of UseCases of program i created. I am having a trouble with specific situation. My programm can be used by several types of actors. Guest, User(logged in Guest), Editor(User with special permissions). In programm all types of actors can read an article, but if you are a User, you can also extend reading of article by making a comment, and if u are a editor, you can extend reading of article by making a comment or editing the article. How should UML for this situation look alike?

I tried to make it look like this, but it dont really think it should be done this way

Example


Solution

  • Preliminary remark, it is not Read article that extends Edit article, but Edit article that extends Read article. The extend-arrows should therefore all be in the opposite direction.

    In a use-case diagram, each use-case should appear only once. So you should not show the same use case with different extensions for different actors, but have only one with all the extensions.

    What you try to express in your diagram is that Read article and its extension points have some constraints regarding the actor. This is best reflected with a plaintext constraint, e.g. { only if actor is Editor or User }. A further simplification could be to to specialise actors (inheritance), since Editor is a User with more responsibilities.

    But in reality, your use-case diagram seems not driven by the actor's goal, but by your user interface design: Editing an article is an objective that is very different from reading. In fact, at the beginning there is no article to read, and the editor starts nevertheless to edit. Of course, your user interface may be designed with a reading interface, and a special button to with to editor mode. But this is "how" the system meets the objectives of the actors, and not "what" these objectives are, which should be the prime focus of use-cases.

    I'd therefore rather recommend to redraw your diagram based on the user's objective, independently on how these are implemented in the user interface or the internal structure of your system.