Shell's "Diagram of the month"


Hi gang,

About this thread

Visual Paradigm supports a lot of different diagram types. This ranges from diagrams which are build upon official standards (think about the Use Case (UML), Business Process (BPMN) and even the Requirements diagram (SysML)) but also diagrams which were basically designed by Visual Paradigm themselves. For example the Textual Analysis (this is a really powerful tool to start a project by the way), The Brainstorm diagram (“sticky notes” in Visual Paradigm :wink: ), and there are several Grid based diagrams where Visual Paradigm basically used a commonly available grid in a new and interesting way.

Or what to think about existing diagram styles which Visual Paradigm severely enhanced? The Customer Journey Map comes to mind here.

Now… I think that the Visual Paradigm website does a really good job in displaying all the provided features. But it doesn’t always get into the detail of the individual diagrams. So I figured, why not showcase some diagrams individually and explore how they might enhance your workflow?

I feel the need for a small disclaimer, but if you had enough dry theory already you can safely skip to the first main header (you won’t miss anything important for following this thread).

Small disclaimer

I fully realize that the use of diagrams within the field of data analysis is driven by necessity and usually has little to do with personal preference. My purpose for this thread is simply to act as some kind of showcase to demonstrate some of the things Visual Paradigm can do. And not necessarily in the hands of a professional: the other reason I’m starting this thread is because it’s also a fun way for me to study some of these diagrams and learn more about them before sharing my findings.

And although I will definitely do my best I cannot rule out that some mistakes might happen (but if those do happen I will obviously admit to the mistake and correct it).

Also: some people sometimes wonder about me so let’s get some things out of the way: No, I do not work for Visual Paradigm. Yes, I am definitely a fan: I really enjoy working with Visual Paradigm in both a semi-professional way (= using UML / BPMN for my personal projects) as well as hobby based. I actually have downloaded several of the formal modeling specifications from the OMG group which I’m also studying (just for context). No, I don’t think Visual Paradigm is perfect. In fact, I even discovered quite a few flaws myself over the past the years. But I do think Visual Paradigm is one of the best modeling suites available and I seriously admire the dedication by the Visual Paradigm team towards their product.

And when I like something I tend to vent a little :wink:

But just so we’re clear: I share the same amount of enthusiasm for FreeBSD, NetBeans and the game of Minecraft. If you look up my nickname in combination with those then you’ll find me. Me “backing up” Visual Paradigm is only driven by one simple motivation: I seriously like the software as well as admire the company behind it. And when I like something, you get posts like these :sunglasses:

Sorry for the long intro but several people asked about some of my reactions / responses towards Visual Paradigm so I figured I’d share.

Business rules diagram

I know, I know: the official name is Business Rule Grid. But I’m still tempted to call this a diagram because we also have the Matrix diagram (grid based) and Chart diagram (also grid based). On top of that: this will really come to live if you don’t start with setting up the grid, but instead focus on the rule elements themselves.

Adding a broader view

What makes this diagram stand out for me is its accessibility. But first off: what is a business rule exactly? Well, according to Wikipedia:

Take note: operations, definitions and constraints.

So how would we apply this? Very simple: just add the rule to the diagram(s) they apply to. For this very purpose I gave the rules a specific format so that they would stand out.

Examples of usage

Let’s take this Use case into consideration:


And also the follow up on “cool stuff” (quite the description, eh?):

So here we are, 2 diagrams describing different aspects of our system and both contain a business rule. So the interesting part here is that you can apply those rules in any way you want. Your different diagrams describe different parts of the system and by adding those rules you’re basically applying a layer “on top” of what you already have:

So here I added a new business grid, and also added some custom columns to determine some aspects which are important to this situation. Within the individual diagrams all you have is an extra element. One which could easily be disregarded if need be (using layers for example).

But if you then open up the business grid you get a solid overview which showcases new directions and new possible bottlenecks to address. I mean… all I did was adding some concerns. For example: when looking at the above diagram (I know it’s kind of crude) I’d immediately raise a question: how does the admin get a copy of the log?

It has no direct impact on the rest of the diagrams (it could have of course) but clearly showcases a possible concern which may need to be addressed.

And all thanks to a ‘simple’ grid diagram which basically only contains specific model elements listed across different diagrams.

Which also somewhat explains why I like this so much. The Business rule grid is a feature only available in the Professional feature (and up) and although you most likely won’t miss this if you use a lower tier license its value really becomes obvious once you started to use it.

Sure: this is a simple looking aspect. But things which look easy…


The Business rule grid is available in VP Professional and up.

Official description

See this VP webpage: “A business rule is a statement that describes a business policy or procedure. Business rule grid is an ideal tool for accommodating a large amount of business rules in a manageable manner.”.


2 out of 5. But it depends on how you approach this. If you start by creating a grid and then adding rules (also possible) then it might become more difficult. But if you apply these rules as individual model elements to your existing diagrams (or diagrams you’re working on) then the “business rule puzzle” can easily fall into place fully automatically.

Personal impression

It is not something I use very often myself, but when I do I can’t help but be a little amazed at the impact of something as simple as a mere grid diagram. I think that Business Rules are well in place within the Professional tier, even though I wouldn’t be easily able to afford them as an individual user myself.

But if you do decide to invest then I think you won’t be disappointed because of the ease of use and the easily gained results.

Diagram of the month for March: Business rule grid.

And there you have it!

Thanks for reading and hopefully until the next post in this thread! (approx. 4 weeks from now, give or take; one entry per month). I hope you enjoyed.


Editorial: It’s been a little longer than I anticipated, but I haven’t forgotten about this thread. I had to deal with a two-faced problem: first I set a little too high standard for myself (a very complex yet also very impressive diagram, I will address this in a later post) and my available time also got severely limited due to work obligations.

June 2018

The Data Flow Diagram (DFD)

The data flow diagram (“DFD”) is one of those hidden pearls within Visual Paradigm and it is easy to overlook. You can think of a DFD as a combination of a Use Case and a Communication diagram, both of which you can find within the UML specification.

There is no official standard for a DFD (just try looking it up on Google Images) and that’s also where its advantage lies. Sounds weird? It’s simple really: this allows you to set up a rough overview of your project and the involved data without having to worry about invalidating your diagram.

And that allows you to fully focus on the data and less on ensuring that you correctly comply to the current standards. To emphasize on this I added a small square and a shout-out box which provides us with some extra information.

Overview of used model elements

The diagram structure is really very simple, the whole diagram actually consists of only three main model elements:

  • External Entities: These are entities which somehow interact with your system.
  • Process: The specific task(s) which are supported by the system.
  • Data Store: This represents the manifestation of certain data.

Specific enhancements

Visual Paradigm wouldn’t be Visual Paradigm if it didn’t provide us with some specific features unique to working with VP :wink: As you can see I can number my processes, I can create relations between them, but what if I want to further describe the detailed inner working of a process?

We could always consider to add a sub diagram but VP has something even better set up for us:


Although this is basically the same thing as creating a new sub diagram it also provides a specific advantage: all the model elements which are related to your current process can be automatically added to the new diagram, which will make it a lot easier for you to work out your subprocess!

And as mentioned before: you don’t have to worry too much about specifications.


The Data Flow Diagram is available in Visual Paradigm Modeler and up.


On my personal difficulty rating (which goes from 1 to 5) I give this a 2 out of 5. The limited amount of required model elements combined with the resource catalog makes this a really easy diagram to get started with.

The reason I still set it to 2 is because despite its simplicity the DFD actually has some hidden settings which could slightly add to its complexity. For example, those Data Store model elements? They actually have 4 types for you to use:

  • Computerized data (as shown in my example).
  • Manual
  • Transient data file
  • Transient manual

Although this doesn’t make it too complex it’s still something to keep in mind.

And there you have it!

The next time you’re struggling a little bit with structuring your project, especially if that involves compliancy with current standards, then maybe this diagram can help you focus by setting up a rough overview.


July 2018

The Entity Relationship Diagram (ERD)


Some people think that designing a database is pretty easy. After all: you simply make the database itself, add several tables and containing fields and you’re done. Well… maybe not so much. There’s a huge difference between “a database” and an optimized database.

If done right then you want to store your data in the most optimal way possible. Not only does this save storage space, it will also ensure that your database can quicker access the data it needs.

Take for example the diagram above. Many people would be tempted to set up a database like that with one table containing name, address, and city. Not necessarily wrong, but there is a problem with that design. Because although each user may be unique, the same can’t be said for the cities they live in. It’s easily possible that many users live in the same city.

The result of this would be that you’d store the name of the city multiple times within the users table. And that’s not very efficient.

Fortunately there are tools to help us with these designs, and ERD is one of them.

VP’s three phases of database design

What really sets the ERD in Visual Paradigm apart are the three different data models which you can use:


What this means is that you can make the diagram design as complex or as abstract as you want. If you take another look at my first example then you’ll probably notice that it is actually a bit of a weird database.

After all: how would the relationship between ‘Users’ and ‘Link’ work when there are no matching fields?

Well, it wouldn’t. But in this stage of my design that’s not important at all. What does matter is that I showcased the underlying theory behind my database design. In fact; although I did add some fields to the tables I could have easily skipped that part as well. All which matters is to get a good overview of the general concept of my upcoming database.

The conceptual view, as shown above, is the most abstract one. It shows tables, some optional fields (yet without any details) and it’s meant to focus on the tables and their underlying relationship(s).

When you’re satisfied with the first stage then you can transition your diagram to the next level of complexity; either a logical or physical model.


The logical model, as shown here, adds more detail to your design. It now shows primary keys, it can (automatically) set up foreign keys which will help to establish relationships between tables and it also shows much more details about the fields as well.

Although it is still somewhat abstract (by hiding specific aspects of your design such as automatically generated keys) this model sits a lot closer to the actual database design which will be eventually used.

That design will only be displayed in the final model which is the physical design, as shown below.


Now we’ve reached the phase where our design should match the setup of the actual database. In other words: what you see here should eventually fully match the situation as it would be used within a database server.

Even better: it actually does, thus allowing you to export your design(s) and apply them onto a real database server. You can even use Visual Paradigm to start inserting actual data.


The Entity Relationship Diagram is available in all Visual Paradigm editions.


On my personal difficulty rating this scores a 3 out of 5. Although setting up the diagram itself doesn’t have to be all that difficult the involved theory on database design can be tricky to apply correctly. Designing a good database can honestly be a professional in itself.

And there you have it!

I think that the ERD provides a good example why Visual Paradigm is much more than just a modeling or general design tool.