Time to play with a new feature I discovered:
- I enjoyed this guide.
- I’m a bit indifferent; it’s not good but not bad either.
- Sorry, but I didn’t enjoy reading this.
0 voters
And thanks in advance for voting and testing this feature 
Hi gang!
It’s been a while since I posted something to this forum, blame work and Minecraft (
) This evening I reserved some time to study a few things related to VP yet that didn’t work out as I expected, so I figured… Why not add / post something new 
Note: This guide goes from modeler to professional level (both are VP license types) and my intention is to show you how to get the best out of your Use Case setups while not discriminating against license types, but I will show you some of the advantages which Professional has over Modeler.
Apologies up front because I will not take the community license into account here. This doesn’t mean that if you use community that this guide is useless to you, but there will be parts which most likely won’t fully work.
Shell’s guide to Use Case diagrams
Use Case: what is it and why should we care?
The Use Case diagram is part of the UML collection of diagrams and its main intent is to provide the viewer with a good overview of what a program can do. A good Use Case diagram should explain the functionality of a program from a users perspective. This means that programming concepts such as dependencies and inclusions are not to be used here, yet that also immediately touches a very sensitive issue because UML does allow you to showcase that a function (note: not a function(); as in programming but merely a feature which the software provides) can be part of another function (“feature”) or even extend on it. Extending on something?
Are we sure this isn’t subclassing?.
Trust me: it’s not. Yet this is also a good example why this is such a very delicate (and sometimes difficult) issue.
For example: take this forum. To my knowledge you need to register before you can write a message. Therefor the functionality “Writing a message” is depending on the function “Logging into the forum”:
But if you, as a programmer, see this then you might be thinking… “Wait a second! We also need to verify the account, check the password validity, deny access when it doesn’t match, and more! What’s up with that?”. And you’d be right, but also wrong 
Yes, the forum will need to verify a password before giving a user access but is that something which the user themselves would do? Note: the actor in the diagram above is a Visual Paradigm forum user, and trust me: I’m positive that the VP company doesn’t want us anywhere near their user database.
From our perspective we can read messages, but the moment we want to write one we have to log in and when done then can we do some writing. But we have no notion of anything happening in the background such as verifying our passwords.
And this brings us to the other question of this section: why we should care about the Use Case. Simple: because it can quickly show our audience what they should be able to do with our software. And we can go as in-depth or shallow as we want.
How to get started on a Use Case diagram
Fun fact: did you know that many data analysts use a Use Case diagram as a starting point for the rest of their analysis project?
The main problem which we’re facing is context. A Use Case diagram is usually set up with a specific user (or a group of users or entity) in mind. Everything associated with that should therefor also only exist within their context.
Yet this is also where plenty of problems arise. Take my previous example: of course the system needs to verify a password, but even though this is something used by the system it’s not something the user would have access to. It’s not a function in the direct sense of something being used. But as a programmer you might be tempted to include this aspect nonetheless.
So how do we prevent ourselves from falling into this trap?
Well, each to their own but have you ever considered using a Textual Analysis diagram?
Textual Analysis
A textual analysis diagram is a way in which you describe something using text (duh! ). This could be used for anything, but in my opinion it’s best suitable for Use Cases. And when you have something written out you can then continue to extract specific text snippets and convert them into model elements. You don’t even have to worry if the text snippet isn’t fully what you wanted, a mere edit is but a mouse click away.
And won’t worry: Visual Paradigm perfectly understands that not everyone is a fluent writer who can type out essays. And you don’t have to! Even a few lines can be enough to give you a solid head start. For example, take a look at this:
Only 2 lines of text already gave me most of the elements in my previous diagram example above.
But there are more advantages here. Once you written down some ideas why not let that rest for a while? Write out your issues, save, leave it alone for one or two days and then try again. Each to their own but taking that kind of distance from the project usually does miracles for me.
So we have a Use Case, now what?
In most modeling suites that I’m familiar with every diagram is a separate component of the project. So once you finished one and you need more then it’s time to focus on the second.
Not so much with Visual Paradigm though…
If you still feel strongly about the need to showcase that a login session also includes password verification as well as denying access then this is your moment. And the best part of it is that this doesn’t have to invalidate your diagrams where specifications are concerned at all.
Keyword being sub-diagrams:
If you click on a model element then you’ll notice an arrow icon showing up in the lower right corner. Click it to access the ‘sub diagram’ menu. Another way is to right click and find the ‘sub diagram’ menu section.
That login process can easily be showcased in more detail, for example by using an Activity diagram, so let’s add one:
Note that this isn’t the best of activity diagrams, my main concern here was to provide a usable example.
Fun fact: Did you know that you can quickly export diagrams as images using the clipboard in Visual Paradigm? This allows you to paste them into online fora (such as this one) without having to bother with saving and selecting.
How?
- Select all your model elements.
- Right click on a model element.
- Then use Copy => Copy to clipboard as Image
Like so:
… this is how I set up the example above.
So where do we go from here?
Are you familiar with the Unix philosophy?
In case you’re not: Unix is an operating system which tries its best to make things as easiest as possible on both its users and it’s developers. One part of this is the so called Unix philosophy: “Do one small task and do that to the best of your abilities”. The reasoning here is that other components (“programs”) can use the result for their own needs.
For example: if you want to get an overview of all your running processes on a Unix environment you’d use the ps command. Unfortunately this command doesn’t provide features such as alphabetic sorting. Something which can be easily solved by sending the output of this command to the sort command. While ‘ps’ only provides us with the process overview the ‘sort’ command makes sure that the sorting will be as we want it to be.
And you know what? This is actually comparable to the way VP handles their projects.
Take for example the Use Case diagram above. We set up the main features, we used a sub-diagram to highlight important details, and we’re done, right?
Well… maybe not.
Because if you happen to have access to the Professional version (or up) of Visual Paradigm then there’s a lot more which you can do.
Here I’ve opened the so called ‘Use Case details’ and although it might look as merely some simple lists looks can (and in this case are) deceiving. Because all these small items can help you build up much bigger overviews.
Let’s start with the screenshot above. Here I’m merely providing the steps within the flow of writing a message. Simple. But do you notice the green icon at the right? That gives me access to the wireframe diagram editor. Not only do I have a list of functions here: I can tie them directly into a concept of how the actual screens should look like. And don’t worry: you don’t have to bother with any (interior) design issues, this is all about the broad layout and its intended functionality.
And there’s more…
The “Use Case Notes” tab gives me access to a dialog in which I can provide more details for the workflow of my use case, the underlying business logic, a list of decisions involved with this function and finally anything following up on this. Of course, as usual for Visual Paradigm, it doesn’t have to stop here. That’s all up to you.
And we’re not done: If you look at the screenshot again you’ll notice some very important tabs:
- Requirements - This allows you to provide everything needed in order to make this function happen. It won’t affect the Use Case diagram itself but it will help you to set up a so called requirement overview.
Test plan - Although the Use Case itself should not have much to do with development processes, this is the exception to that rule. This tab allows you to specify what you have set up to test this functionality as well as provide more in-depth information about the involved configuration. - Details - This allows you to provide in-depth (background) information about the feature at hand. What is the complexity of the feature, what is the status of its implementation, are there any extra conditions involved?
And all of a sudden we went from a brief functionality overview within the Use Case to the building blocks for something much deeper such as requirements, wireframe and you even have ties into (project) managing your entire project.
And it all started with one Use Case…
And there you have it!
I hope this helped you to get an impression of the things you can do with a Use Case diagram.
