Author Topic: Organizing Use Cases  (Read 1557 times)

acalbaza

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Organizing Use Cases
« on: February 23, 2019, 04:15:51 am »
Hello,

I've been taking a crack at loading use cases into Sparx and ran into a situation where I'd like to get guidance.

I have a number of use cases that rely on a common set of steps.  Namely: checking if an object exists and checking if the requester has access to said object.  I'd like to factor these steps out into their own standalone use cases so that I can include their behavior when necessary.

As a result, I created 2 use cases - "Check Authorization" and "Check Object Exists".  They are each self-contained and have happy/sad paths as you would expect.  In my primary use case, I "included" the auth check and exists check into the scenario steps where I expect them.  All seems reasonable, however...

If I try to generate test cases or activity diagrams, this inclusion is lost. Activity diagrams no longer show branching that in the primary use case.  Test cases don't generate variation.

My question is if the use of inclusion is recommended in this situation?  I'm really just trying to avoid repeating alternate flow definitions and I want all the goodness that the tool can offer.  How have you managed this kind of setup


Thanks,

Alejandro

qwerty

  • EA Guru
  • *****
  • Posts: 10504
  • Karma: +232/-190
  • I'm no guru at all
    • View Profile
Re: Organizing Use Cases
« Reply #1 on: February 23, 2019, 04:28:38 am »
<<include>> and <<extend>> are part of the UML specification. However, in most cases people do not use them the right way. Simply, they start functional decomposition (like you did). A use case is a use case. It has some value it brings to its actor. if you start decomposing that you end up with activities being use cases. Don't!  Read Bittner/Spence about use cases and stick to it.

If you really want to "reuse" things in use cases then re-use activities. However, that's also kind of nonsense. Activities should be on a level where there is nothing you need to repeat. E.g. if you have a login procedure you should just stick with the constraint. You might do some technical stuff with an authorization sub-system where you detail the authorization. But use cases are primary meant on a business level. None of the business people are interested in how the authorization actually works (that's technical stuff). The just might tell "user/password" or "iris scan" or whatever.

Actually this is a rather long story and can't be put in a short answer (except for: read the book mentioned above).

q.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 9395
  • Karma: +260/-27
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Organizing Use Cases
« Reply #2 on: February 23, 2019, 06:14:00 pm »
If you do it correctly and generate an activity diagram (with actions) from your scenario you should see a callActivityAction (Action with rake symbol) where you include another use case.
Doubleclicking on that callActivityAction will open up the scenario diagram for the included use case.

Geert

jfzouain

  • EA User
  • **
  • Posts: 124
  • Karma: +4/-1
    • View Profile
Re: Organizing Use Cases
« Reply #3 on: March 02, 2019, 06:24:20 am »
Hi Acalbaza

Just like both Gurus said you have to link the <<include>> and <<extend>> steps in the use case.
1) Right click at the step
2) Link Step to Use Case
3) Search for the Use Case
4) Save.

When generating the Test Case it will mention the test case to open and execute, it will not generate the steps for the include, invoke or extend because these belong to another use case, see here in page 186 of my eBook:
4. System displays the Inventory BOS03 -Add Mode
5. <extend> UIM02.01 Information Tab
6 ...

The User performing the test case will have to go the other test case UIM02.01 Information Tab Test case to test it.

Check my eBook for further informationon use cases and test cases.
https://leanpub.com/uml-erpworkshop

Regards

Best regards

Jose Zouain

Richard Freggi

  • EA User
  • **
  • Posts: 163
  • Karma: +7/-4
    • View Profile
Re: Organizing Use Cases
« Reply #4 on: March 02, 2019, 05:57:32 pm »

Here's my perspective
yes you can get down this rabbit hole but there's a better way.
You are mixing what the user wants to achieve with how the system does it.  This is the typical pitfall of functional decomposition.  Very non-UML and very non-object oriented.  It leads to very large, complicated and less useful models. 

My approach would be: neither is a good use case.  The use case should show WHO wants to check authorization and object existence and WHY they want to check it.  In other words, what are they trying to achieve?

The mechanics of HOW the system achieves the user goals should be completely out of the use case model.  The mechanics should be described in sequence diagrams, because the lifelines will guide you directly to define a good, simple and efficient class diagram. 

Activity diagrams are of very little value because they show procedural logic without reference to the objects or their classes.  So you don't get much benefit from them.  Activity diagrams are useful to define class methods and user interfaces.  If you need to describe complex object transformations, statecharts are much better.

End of rant: use case models (and package diagrams) are deceptively simple and easy to draw.  But it takes a few years of practice to use them correctly (system architecture, implementation approach, project management, vendor management, testing....).  Just keep practicing and eventually you'll get it!

Hello,

I've been taking a crack at loading use cases into Sparx and ran into a situation where I'd like to get guidance.

I have a number of use cases that rely on a common set of steps.  Namely: checking if an object exists and checking if the requester has access to said object.  I'd like to factor these steps out into their own standalone use cases so that I can include their behavior when necessary.

As a result, I created 2 use cases - "Check Authorization" and "Check Object Exists".  They are each self-contained and have happy/sad paths as you would expect.  In my primary use case, I "included" the auth check and exists check into the scenario steps where I expect them.  All seems reasonable, however...

If I try to generate test cases or activity diagrams, this inclusion is lost. Activity diagrams no longer show branching that in the primary use case.  Test cases don't generate variation.

My question is if the use of inclusion is recommended in this situation?  I'm really just trying to avoid repeating alternate flow definitions and I want all the goodness that the tool can offer.  How have you managed this kind of setup


Thanks,

Alejandro