3 added 5 characters in body
source | link

If a use case extends another is independent from the visible associations between actors and use cases. However, whenever there is an actor associated with a use case like "checkout items", it is clear this situation requires user interaction, which makes it mandatory to have a viewing feature part of that use case, not the other way round.

Therefore, I heavily recommend not to model "view items" as a use case on its own. An employee does not view items "just for fun", for real use cases, there should be a business purpose behind it. Some examples, which all will need this viewing feature:

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • "checkout items" (whatever that means in your context, since "checkout" and "item" are generic terms with many different possible meanings)

UML use case notation is intended for describing usage scenarios mostly independ ofindependend from the UI. This notation and the "extends" and "includes" relationships are designed for a differenthigher level of abstraction. Even if the use case "checkout items" will be started at the user interface by viewing the items first, that is nothing I would try to express through the model, it is just an UI detail.

If you wantstill feeel urged to do model "view items" as a separate use case anyway, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, it is IMHO obvious that almost everymost use casecases involving user interaction with items needsneed a viewing feature: users don't want to poke around with items blindly when operating on them.

If a use case extends another is independent from the visible associations between actors and use cases. However, whenever there is an actor associated with a use case like "checkout items", it is clear this situation requires user interaction, which makes it mandatory to have a viewing feature part of that use case, not the other way round.

Therefore, I heavily recommend not to model "view items" as a use case on its own. An employee does not view items "just for fun", for real use cases, there should be a business purpose behind it. Some examples, which all will need this viewing feature:

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • "checkout items" (whatever that means in your context, since "checkout" and "item" are generic terms with many different possible meanings)

UML use case notation is intended for describing usage scenarios mostly independ of the UI. This notation and the "extends" and "includes" relationships are designed for a different level of abstraction. Even if the use case "checkout items" will be started at the user interface by viewing the items first, that is nothing I would try to express through the model, it is just an UI detail.

If you want to do model "view items" as a use case anyway, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, it is IMHO obvious that almost every use case involving user interaction with items needs a viewing feature: users don't want to poke around with items blindly when operating on them.

If a use case extends another is independent from the visible associations between actors and use cases. However, whenever there is an actor associated with a use case like "checkout items", it is clear this situation requires user interaction, which makes it mandatory to have a viewing feature part of that use case, not the other way round.

Therefore, I heavily recommend not to model "view items" as a use case on its own. An employee does not view items "just for fun", for real use cases, there should be a business purpose behind it. Some examples, which all will need this viewing feature:

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • "checkout items" (whatever that means in your context, since "checkout" and "item" are generic terms with many different possible meanings)

UML use case notation is intended for describing usage scenarios mostly independend from the UI. This notation and the "extends" and "includes" relationships are designed for a higher level of abstraction. Even if the use case "checkout items" will be started at the user interface by viewing the items first, that is nothing I would try to express through the model, it is just an UI detail.

If you still feeel urged to model "view items" as a separate use case, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, it is IMHO obvious that most use cases involving user interaction with items need a viewing feature: users don't want to poke around with items blindly when operating on them.

2 deleted 5 characters in body
source | link

To give you a direct answer to your question: ifIf a use case extends another is independent from showingthe visible associations tobetween actors in the modeland use cases.

  However, IMHO your examplewhenever there is not well suited for reasoning about this, because it abusesan actor associated with a use case notation for showing application features orlike "checkout items", it is clear this situation requires user interface dependencies. UML use casesinteraction, howeverwhich makes it mandatory to have a viewing feature part of that use case, are for describing usage scenarios mostly independ ofnot the UI. This notation and those "extends" and "includes" relationships are designed for a different level of abstractionother way round.  

"View items" is actually not a real use case on its ownTherefore, I heavily recommend - annot to model "view items" as a use case on its own. An employee does not view items just"just for funfun", for real use cases, there is typicallyshould be a business purpose behind thisit. For exampleSome examples, which all will need this viewing feature:

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • I have only a vague notion of what exactly "checkout items" (whatever that means in your context, since "checkout" and "item" are generic terms with many different possible meanings, but lets assume "checkout items" has some business purpose, so this can be a use case.)

All the examples above requireUML use case notation is intended for describing usage scenarios mostly independ of the employee to viewUI. This notation and the items in stake, so this just"extends" and "includes" relationships are designed for a common detail of them, just an UI feature required in alldifferent level of abstraction. Even if the threeuse case "checkout items" will be started at the user interface by viewing the items first, butthat is nothing for which I would recommendtry to drawexpress through the model, it is just an own use case bubble "view items"UI detail.  

If you want to do thismodel "view items" as a use case anyway, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, don't be astonished if this leads to a diagram where anyit is IMHO obvious that almost every use case involving items where user interaction is necessarywith items needs an "includes" relationshipa viewing feature: users don't want to "view items"poke around with items blindly when operating on them.

To give you a direct answer to your question: if a use case extends another is independent from showing associations to actors in the model.

  However, IMHO your example is not well suited for reasoning about this, because it abuses use case notation for showing application features or user interface dependencies. UML use cases, however, are for describing usage scenarios mostly independ of the UI. This notation and those "extends" and "includes" relationships are designed for a different level of abstraction.  

"View items" is actually not a real use case on its own - an employee does not view items just for fun, there is typically a business purpose behind this. For example,

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • I have only a vague notion of what exactly "checkout items" means in your context, since "checkout" and "item" are generic terms with many different possible meanings, but lets assume "checkout items" has some business purpose, so this can be a use case.

All the examples above require the employee to view the items in stake, so this just a common detail of them, just an UI feature required in all of the three, but nothing for which I would recommend to draw an own use case bubble "view items".  

If you want to do this anyway, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, don't be astonished if this leads to a diagram where any use case involving items where user interaction is necessary needs an "includes" relationship to "view items".

If a use case extends another is independent from the visible associations between actors and use cases. However, whenever there is an actor associated with a use case like "checkout items", it is clear this situation requires user interaction, which makes it mandatory to have a viewing feature part of that use case, not the other way round.

Therefore, I heavily recommend not to model "view items" as a use case on its own. An employee does not view items "just for fun", for real use cases, there should be a business purpose behind it. Some examples, which all will need this viewing feature:

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • "checkout items" (whatever that means in your context, since "checkout" and "item" are generic terms with many different possible meanings)

UML use case notation is intended for describing usage scenarios mostly independ of the UI. This notation and the "extends" and "includes" relationships are designed for a different level of abstraction. Even if the use case "checkout items" will be started at the user interface by viewing the items first, that is nothing I would try to express through the model, it is just an UI detail.

If you want to do model "view items" as a use case anyway, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, it is IMHO obvious that almost every use case involving user interaction with items needs a viewing feature: users don't want to poke around with items blindly when operating on them.

1
source | link

To give you a direct answer to your question: if a use case extends another is independent from showing associations to actors in the model.

However, IMHO your example is not well suited for reasoning about this, because it abuses use case notation for showing application features or user interface dependencies. UML use cases, however, are for describing usage scenarios mostly independ of the UI. This notation and those "extends" and "includes" relationships are designed for a different level of abstraction.

"View items" is actually not a real use case on its own - an employee does not view items just for fun, there is typically a business purpose behind this. For example,

  • checking some item properties for the purpose of quality assurance - then the use case is "quality assurance of items"

  • given those items have a price, then "paying an item" might be a use case

  • I have only a vague notion of what exactly "checkout items" means in your context, since "checkout" and "item" are generic terms with many different possible meanings, but lets assume "checkout items" has some business purpose, so this can be a use case.

All the examples above require the employee to view the items in stake, so this just a common detail of them, just an UI feature required in all of the three, but nothing for which I would recommend to draw an own use case bubble "view items".

If you want to do this anyway, maybe for exercising purposes, then I would recommend to draw an "includes" relationship from a use case like "checkout items" to "view items". However, don't be astonished if this leads to a diagram where any use case involving items where user interaction is necessary needs an "includes" relationship to "view items".