3

Little background

I'm new to writing use cases and representing their scenarios. I'm dealing with a complex system. In the first step of analyzing the system, I created a use case diagram where each use case represents a distinct goal or value for the system. I have tried my best to keep the use cases independent. All these use cases require the initialization and activation of the system, so I decided to take out this common part and link it to the main use cases using include relationship. I understand that include and extend relationships need to be used only when necessary. Now I'm lookin into defining scenarios for each use case and then developing user stories and requirements based on scenarios.

Main issue

The use cases are very complex and the easiest way to analyze it seems to be mapping it into a sequence of steps/activities where each activity contains several scenarios and each scenario is represented using a sequence diagram. I understand that an activity cannot be a use case which is related to the main use case using include relationship; but having sequence diagrams for activities seem wrong too.

What is the best way to represent a use case where each step of the main flow is complex and can have several interactions between actors and systems as well as having error scenarios which can result in termination of the sequence at that step or possibility of the user cancelling/aborting the sequence? I have attached a simplified version of the activity diagram for "Initialize" use case. As I mentioned, each activity can have many scenarios. For example

  • "Perform Self check" has many steps and each step might result in a failure that can terminate the sequence and alert the user (via a HMI). The user then can either terminate the initialization or retry.
  • "Validate system configuration" include steps for obtaining the reference config versions and comparing that to the system config, then download the new config files if necessary and then update the system configs. Each step might have a failure resulting in some sort of message to user and termination of the sequence. In some cases user should be able to skip the failed steps and proceed without doing that activity. Same goes for every other activity in the diagram; many steps with exception or alternative paths.

Can I map these on one sequence diagram for the "Initialize" Use case? My attempt to put all these on one sequence diagram failed. I tried putting all these interactions on an activity diagram with swimlanes but things got so complex that stakeholders have a hard time understanding what is going on.
Maybe I'm trying to put too much details at the system level. Should I leave all these interim steps and interaction for the lower level of design? Should I create a hierarchy of use cases and roll down the complexity? I'm confused. :( What is the best way to deal with such level of complexity? Could you provide some good examples.

enter image description here

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
Parsa68
  • 31
  • 4
  • 1
    Start should be a filled circle and the terminations filled circle with a circle around. Anyhow, look for call behavior which is an invocation of an action. Btw. system start is never a UC. UC are ONLY the goals/added values. – qwerty_so Feb 01 '22 at 22:00

2 Answers2

4

The only way to represent a complex use-case, where every step of the main flow can have multiple scenarios, is fortunately very simple:

enter image description here

The complexity of the scenarios does not change anything to the simplicity of the actor's goals. And if the goals are not sufficiently simple, you're probably looking at things in too much detail. Or the things are not as clear as they should be.

The scenarios are often represented with a set of sequence diagrams. But if it gets really complex you'd better show the flow with an activity diagram.

By the way, you do not need to create an artificial extending or included use-case for the sake of modelling common steps. You may just create a separate activity diagram for the common part. Then, in each of your use-case activity diagrams, you'd insert a call action of the common activity. This also avoids to misleadingly include the common part in the description of one use-case and forget it for the others.

Last but not least, you also want to develop user-stories based on the use-case scenario. This is a mixed approach that requires some more thoughts:

  • user-stories are generally used without use-cases. Complex requirements are described as an epic. The epic would then successfully be refined into user-stories, that fit in an iteration;
  • it is possible to structure such user-stories according to stakeholder goals and tasks. This approach is called user-story mapping. This is closer to the use-case, but there is no term to describe the higher-level goals;
  • use-case driven development is generally used without user-stories: the scenarios and activity directly lead to development without intermediate user-stories.

Fortunately, the Use-Case 2.0 approach allows to combine both ways. Read the linked whitebook: it's short, it's free, it's written by the inventor of use-cases together with leading authors of use-case methodology; it offers a reengineered approach that allows agile developments, using use-case for the big picture and using use-case slices to break it down dynamically into units that can be developed in one iteration.

303
  • 299
  • 2
  • 10
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thanks for the response. So, would you recommend not using "Included Use Cases" if they independently don't bring any high level value and instead use activities that are referenced in various use cases? I'm a little confused as some people say use cases are not supposed to have any common requirements that traces back to them. Another question is that is there any limit on how many levels of decompositions I have for activities (is it ok to have nested activities that go several layer deep)? – Parsa68 Feb 02 '22 at 21:38
  • 1
    @Parsa68 Yes, this is what I recommend. Use-cases are meant to show the big picture, and moreover, show it from the perspective of the actor goals. It is not meant to model a workflow nor a user interface. Using «include» is ok if a use-case always involve some kind of subgoal which are meaningful for the actors. But «include» are not ok for functional decomposition, i.e. breaking down a use case behavior into smaller elements: Functinoal decomposition leads to over-detailed use-case. – Christophe Feb 02 '22 at 23:13
  • 2
    @Parsa68 For activity diagrams, it's ok to decompose and there's no limit. – Christophe Feb 02 '22 at 23:14
2

A complex use case can remain a single use case, but it may need multiple diagrams to specify its flows.

Your activity diagram (although not 100% UML compliant) gives a good overview of the flow of the use case. Keep this as the main diagram. I would decompose the complex steps in separate diagrams. To indicate that a step is decomposed in a separate diagram, you can display a rake symbol, as follows:

rake

See UML 2.5.1 specification, section 16.3.4.1 for more information.

www.admiraalit.nl
  • 5,768
  • 1
  • 17
  • 32