问题
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:
Thanks in advance for any help offered!
回答1:
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
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.
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:
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.
来源：https://stackoverflow.com/questions/61624906/uml-use-case-diagram-for-a-plugin-performing-various-functions-through-importing