2

I am creating a system which makes static analysis on code when a commit to GitHub is made, the results are then showed as a GitHub review.
My problem is, this means that the developer (actor) will not engage with my system, as it is actually GitHub that does this. The developer (actor) is using GitHub and will see the result from my system in GitHub, hence they are never actually using my system directly.
I feel like the diagram below doesn't really capture this that well.

use case diagram - first

I then created another diagram, where the developer (actor) communicates with GitHub (actor) and GitHub then communicates with my system.
However this also seems wrong to be, but still better than before. One of my big problems with this is that GitHub is on the left side, however GitHub is kinda a primary actor, so it also makes sense. I have never seen any examples of use case diagrams doing this, is this actually valid and more importantly does it makes sense? Use case diagram - second

Side question: The CTO (actor) has a use case saying:

As a CTO, I want the tool to not save the code on the server running it, so that I won’t have to worry about our code being leaked.

For me this sounds like a valid use case, but when putting it into a use case diagram it feels off, as this is not really an action, it is more of a requirement. Should this just be part of like a functional requirement?

Edit: So I tried improving it based on the recommendations from you guys.
I ended up removing a lot of use cases, as they were more non-functional or functional requirements. Then I wanted to make the change to show that the tool is running remotely when a commit is pushed, not sure if I did that correctly. Improved use case diagram

5
  • 1
    Most of the bubbles do not contain use cases but actions.You need to fix that first.
    – user188153
    Mar 20, 2020 at 9:50
  • 1
    Your side question: This is also no use case but a requirement.
    – user188153
    Mar 20, 2020 at 9:52
  • @qwerty_so Thanks, I removed a bunch of the use cases, you were totally right, a lot of them were more requirements than use cases. Mar 20, 2020 at 12:52
  • Still work: A UC shows added value for the actor. Still there are just (NF) requirements in the bubbles. Honestly it's difficult to find UCs. I'd recommend Bittner/Spence about UCs. Excellent source. Though it took me a couple of years to get a full understanding.
    – user188153
    Mar 20, 2020 at 13:24
  • @qwerty_so Hmm thanks. I'll maybe check that book out then. Adding to the wish list :) Mar 20, 2020 at 13:56

1 Answer 1

3

One of my big problems with this is that GitHub is on the left side, however GitHub is kinda a primary actor, so it also makes sense. I have never seen any examples of use case diagrams doing this, is this actually valid and more importantly does it makes sense?

Nowhere is it defined that a primary actor must be a human. If, as far as your system can tell, Github is autonomously deciding to invoke your service, then Github is definitely a primary actor. It might then make sense to see the Developer as a secondary user of that use case.

Another way of looking at it might be that the Developer can run the tool locally on uncommitted code or remotely on a commit. In that case, the Developer would be the primary actor on the use cases and the use case for running on a commit would start with the action that the user commits/pushes to a repository (and with the precondition that the repository is configured to run the tool on commit/push actions). Depending on the audience, you then explain or gloss over that the repository is not actually part of the system, but included in the use case step to make it clear when/how the system is invoked.

Side question: The CTO (actor) has a use case saying:

As a CTO, I want the tool to not save the code on the server running it, so that I won’t have to worry about our code being leaked.

For me this sounds like a valid use case, but when putting it into a use case diagram it feels off, as this is not really an action, it is more of a requirement. Should this just be part of like a functional requirement?

It is a valid "user story", but it is not a valid use-case. It is not an interaction between an actor and the system and therefor it is not a use case.

Even as a user story, it is a bit problematic, because it is not a functional requirement that you can implement once and then mark it as done. It is actually a non-functional requirement that should be kept in mind continuously during the development of the system.

3
  • I like the approach of the developer being the actor. So I tried implementing what you said, not sure if I did it correctly though, could you take a quick look? (I edited my question to include the changes) Mar 20, 2020 at 12:53
  • @OliverNybroe, looks correct to me. Mar 20, 2020 at 13:06
  • @BartvanIngenSchenau Thanks a lot for the help! Really learned a lot :) Mar 20, 2020 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.