1

I'm creating a plug-in which adds various functions on top of a core application. The plug-in gives administrators the ability to upload a CSV file and performs the following functions depending on the information entered in the file (by performing operations on the database of the core application):

  • Creating users
    • Can be administrators or normal users
  • Creating projects
    • Can be parent projects or sub-projects of a parent project
    • Sub-projects get copied from a given parent project (so the plugin also adds the option to create sub-projects which are copied from the parent project)
  • Assigning users to projects with certain permissions

I would like to draw a UML use case diagram for this plugin but can't figure out what should go where, especially the uploading of the CSV file. I'm also confused with how to draw the role of the core application here. The only thing it does directly is authorization in this case. The plugin also performs these functions by performing operations on the database of the core application and I'm wondering if there should be some associations coming from create users for example because of this.

One of my attempts can be found here:

Use case diagram

Thanks in advance for any help offered!

Itsme
  • 13
  • 4

1 Answers1

0

Foreword: My answer is based on Bittner/Spence (and others) and not on the definition found in the UML specs.

A use case is about added value the system under consideration brings to the primary actor. Your system has (as it seems) three use cases

  • Create user (what about deleting and modifying them?)
  • Create project (same here)
  • Assigning user to project (also here)

Those are your use cases and no more (to what I read from your explanation). All the other bubbles you put there are from a functional decomposition and are no use cases but (likely) some steps in activities inside the use cases. Simply throw them away.

The actor Core Application looks like representing the system under consideration. If so: throw it away since that would be wrong.

The Authorize bubble is (I guess) a constraint you need to attach to the use cases and shall mean that you have to authorize against the database. It's no use case.

Your system would look like

enter image description here

Now your plugin is just using the existing use cases and executes them based on some scripting in the uploaded CSV. So that's a new use case. Depending on the design this could simply be a new use case added to the existing system. A name for the UC could be Upload control file to describe what is actually done.

enter image description here

It would be a different story if you would allow sort of a a dynamic extesion of a system. You could design it just like so:

enter image description here

The Value added system just has the "upload" UC and uses the core system as an actor.

Why disregarding the norm? Well, for many and a simple reason: it's of no use. It's a pure technical description and following that your design will end up in spider webs. Focus on added value is just what needs to be at the start of a project. If you don't have that you are lost from the beginning. There are a couple of well known authors propagating this approach. I learned from Bitter/Spence and found it usefull ever since.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Thank you for your answer! But I'm still wondering about something. Create user, create project, etc. are use cases already offered by the core application (but it can only do these things one-by-one). I think the added value of the plugin I made to the admin may be that it can do these things in bulk (by letting the admin upload a CSV, processing the CSV and performing the right database operations). How would I make it clear in the diagram that the added value is in the bulk creation/assignment? Would the system then be my plugin or still the core application? – Itsme May 07 '20 at 17:04
  • I have updated my answer in order to address the add-in problematic. – qwerty_so May 07 '20 at 18:59
  • I like your answer, but I would be inclined to use «includes» from the three functional use cases to the `Upload control file`. For me that use case represent the shared behavior of all three. It just so happens that the shared behavior is the first step in the use case. – Geert Bellekens May 16 '20 at 08:33
  • @GeertBellekens It's a simple shot without enough background. The control file could probably do also other things _plus_ using the use cases. That's why I used the extends relation. Using include would (I think) imply that all UCs are actually involved which is probably not the intention. – qwerty_so May 16 '20 at 12:23