Hi gang!
Warning: although I'll definitely (mostly) stay to the facts I'm certain that some parts of my post will turn into a bit of an opinionated approach. The problem is simple: I'm honestly a little bit passionate about this and when that happens, especially on a Friday evening when I want to let off some steam.. yeah
(minor) spam: Parts of this message were made with devel/visualparadigm. A commercial modeling tool (with a free to use community license), developed in Java thus supporting all major platforms and in my humble opinion pretty much the best software available today if you're interested in modeling languages. For full transparency: yes, I am biased. I've been using this software (licensed) ever since I started using NetBeans 4.1 in 2005, ergo I've been using Visual Paradigm for 13 years now. So yes, I am probably biased, but I also have good reasons for that
UML turned 20!
UML is an acronym for Unified Modeling Language; it is basically a collection of diagram types used to describe several parts of a system and it's mostly used within the field of software development. The idea behind UML is basically to have an option to describe the functionality of a (software) project in a way which doesn't discriminate between languages. In other words: whether you program in C, Java, C#, Python or even with Perl, Awk and/or a plain shell script: UML can be a tool to display and/or document how your system works in a way which is fully independent of that programming (or scripting) language. Instead of showing code you'd be showing pictures. And you know what they say: a picture can often tell more than a thousand words.
Unfortunately, but this is just my opinion, UML is also a tool which is often misunderstood. As you can see in the diagram above the whole methodology consists of 14 diagrams in total which each showcase different aspects of your system. Which quickly led to some people thinking that in order to have a "valid" UML project going you'd need to produce at least 1/3'rd of the available diagram types. Madness... Or you can sometimes be dealing with people who are more concerned with the validity of their diagrams than the information which it should be showcasing which I consider just as stupid. And the worst case of them all: UML, and other modeling languages, are often associated with manager type beancounters who seem more obsessed with their (virtual) presentations than the actual happenings on the workfloor. This is because of good reasons mind you, but it still saddens me because it doesn't have to be this way.
UML: love/hate scenario?
I know there are many developers out there who either hate UML or simply don't see the use for it. I mean; why design something in theory if you could also spent all that time fantasizing on coding and actually get some work done?
Well... although it's definitely true that UML (or modeling / software design as a whole) is often (mis?)used by manager type beancounters who care more about their precious presentation and modeling standards there's still something to be said for designing. It's not so much the designing aspect mind you, but more so the attempt to think ahead of what might be to come for your project.
Sometimes a little planning can go a long way. What do MySQL, the Linux kernel and the NetBeans Java IDE all have in common? At some point in time these projects were either completely rewritten from the ground up or major parts of the project have been rebuild this way. Why? Simple: because in many cases the project slowly kept on growing and eventually ended up to grow so big that people fully lost track of the whole thing, often resulting in scenario's where certain parts were coded in such a way that it became seriously hard to build upon that; at the time of development they never figured that their work might be expanded on so heavily. Often leading to scenario's where a full rewrite would actually cost less time and effort than trying to fix all the nastiness that crept into the code over time.
Note that I'm not trying to claim that UML would have been the savior for all this, but I am saying that it could have been.
Although UML is often associated with those manager type diagrams it's actually much more than that. It's not just the diagrams which matter here: it's what they stand for and what those can do for you. At the very least UML can be a methodology to re-evaluate and go over your (software) project from a different perspective. So basically a means to try and help you think ahead about what... if.... What would happen if 250 people were using your software at the same time?
Unix mindset?
As you may know there is a philosophy behind Unix: do something small and be very good at it. Also make sure that others can use your efforts for their own purposes. This helps to build many small things which, when combined, can lead up to something much bigger.
A good example for this would be ls. By itself ls(1) can't sort your output. Yes, it can sort it on sizes but how about a reverse alphabetic list? Heck, once we have that list why not try to weed out any duplicates while we're at it? As said: ls won't be able to handle this on its own, but if you combine its output with sort(1) and uniq(1) you're really getting into the right direction.
To me UML is no different. 14 diagram types means that you also have 14 different ways to explain ("visualize") your project, allowing you to go as easy or as indepth as you want....
But what IS UML anyway?
Simply put: 13 different diagram types (the last one (Profile) is hardly used) where each diagram type can showcase a different section of your project. I usually divide the whole thing into 3 major parts (as shown above):
An UML deployment diagram showcasing my (brief!) impression of the PKGNG system.
Yes, I know I messed up there: it's pkg(8). That's what happens when you do this on a Friday evening (I made this diagram on the fly, my tool of choice makes those quite easy to set up). And now I'm too lazy to fix that
Also a standard!
But other than 14 diagram types UML is also an open standard set out by the OMG ("Object Management Group"), it even has its own website. But yeah, there is a formal specification available for download if you're interested in UML's inner working. Seriously though: if this subject remotely intrigues you then I'd seriously recommend to download and skim through the formal standards PDF file(s). You might be surprised at the amount of detail those provide.
Not just for developers or managers!
Look... UML is a tool. Just like a hammer. And although you may associate a hammer with a carpenter who'd use that to hammer in nails a hammer's use is not limited to that aspect alone. We may set out a "rule" that hammers are on this world to hunt for nails, fact of the matter is that they can also be used to form iron ("smithy"), break Windows, break glass windows (
I so couldn't resist) and a whole lot more destructive things.
UML is not much different. It's a tool which can be used in many different ways. Heck, I once used a deployment diagram to showcase my network structure because at that time my modeling tool was the easiest option I had available.
In the end it is but merely a tool, and it's effects are entirely what you might make of it.
And if you are interested in all this... my advice: please don't let the means turn into some kind of goal of their own.
Anyway, thanks for reading so far. I'd now like to share a Youtube video shared by the OMG group in which one of the founders of UML (Grady Booch) reflects on the whole development:
Each to their own, but in my opinion these are interesting times. 20 years is quite an achievement if you ask me.
Warning: although I'll definitely (mostly) stay to the facts I'm certain that some parts of my post will turn into a bit of an opinionated approach. The problem is simple: I'm honestly a little bit passionate about this and when that happens, especially on a Friday evening when I want to let off some steam.. yeah
(minor) spam: Parts of this message were made with devel/visualparadigm. A commercial modeling tool (with a free to use community license), developed in Java thus supporting all major platforms and in my humble opinion pretty much the best software available today if you're interested in modeling languages. For full transparency: yes, I am biased. I've been using this software (licensed) ever since I started using NetBeans 4.1 in 2005, ergo I've been using Visual Paradigm for 13 years now. So yes, I am probably biased, but I also have good reasons for that
UML turned 20!
UML is an acronym for Unified Modeling Language; it is basically a collection of diagram types used to describe several parts of a system and it's mostly used within the field of software development. The idea behind UML is basically to have an option to describe the functionality of a (software) project in a way which doesn't discriminate between languages. In other words: whether you program in C, Java, C#, Python or even with Perl, Awk and/or a plain shell script: UML can be a tool to display and/or document how your system works in a way which is fully independent of that programming (or scripting) language. Instead of showing code you'd be showing pictures. And you know what they say: a picture can often tell more than a thousand words.
Unfortunately, but this is just my opinion, UML is also a tool which is often misunderstood. As you can see in the diagram above the whole methodology consists of 14 diagrams in total which each showcase different aspects of your system. Which quickly led to some people thinking that in order to have a "valid" UML project going you'd need to produce at least 1/3'rd of the available diagram types. Madness... Or you can sometimes be dealing with people who are more concerned with the validity of their diagrams than the information which it should be showcasing which I consider just as stupid. And the worst case of them all: UML, and other modeling languages, are often associated with manager type beancounters who seem more obsessed with their (virtual) presentations than the actual happenings on the workfloor. This is because of good reasons mind you, but it still saddens me because it doesn't have to be this way.
UML: love/hate scenario?
I know there are many developers out there who either hate UML or simply don't see the use for it. I mean; why design something in theory if you could also spent all that time fantasizing on coding and actually get some work done?
Well... although it's definitely true that UML (or modeling / software design as a whole) is often (mis?)used by manager type beancounters who care more about their precious presentation and modeling standards there's still something to be said for designing. It's not so much the designing aspect mind you, but more so the attempt to think ahead of what might be to come for your project.
Sometimes a little planning can go a long way. What do MySQL, the Linux kernel and the NetBeans Java IDE all have in common? At some point in time these projects were either completely rewritten from the ground up or major parts of the project have been rebuild this way. Why? Simple: because in many cases the project slowly kept on growing and eventually ended up to grow so big that people fully lost track of the whole thing, often resulting in scenario's where certain parts were coded in such a way that it became seriously hard to build upon that; at the time of development they never figured that their work might be expanded on so heavily. Often leading to scenario's where a full rewrite would actually cost less time and effort than trying to fix all the nastiness that crept into the code over time.
Note that I'm not trying to claim that UML would have been the savior for all this, but I am saying that it could have been.
Although UML is often associated with those manager type diagrams it's actually much more than that. It's not just the diagrams which matter here: it's what they stand for and what those can do for you. At the very least UML can be a methodology to re-evaluate and go over your (software) project from a different perspective. So basically a means to try and help you think ahead about what... if.... What would happen if 250 people were using your software at the same time?
Unix mindset?
As you may know there is a philosophy behind Unix: do something small and be very good at it. Also make sure that others can use your efforts for their own purposes. This helps to build many small things which, when combined, can lead up to something much bigger.
A good example for this would be ls. By itself ls(1) can't sort your output. Yes, it can sort it on sizes but how about a reverse alphabetic list? Heck, once we have that list why not try to weed out any duplicates while we're at it? As said: ls won't be able to handle this on its own, but if you combine its output with sort(1) and uniq(1) you're really getting into the right direction.
To me UML is no different. 14 diagram types means that you also have 14 different ways to explain ("visualize") your project, allowing you to go as easy or as indepth as you want....
But what IS UML anyway?
Simply put: 13 different diagram types (the last one (Profile) is hardly used) where each diagram type can showcase a different section of your project. I usually divide the whole thing into 3 major parts (as shown above):
- Structure: This shows the inner working and layout of your project. A Class diagram for example would show all your classes and their properties / methods as well as the relationship they share with other classes. A deployment diagram for example would show how your project manifests itself when installed.
- Behavior: In short: what does your project do? A Use Case diagram for example is well known for its ease of use and the things it can explain (Use case diagrams, as their name implies, explain the main functionality of your project).
- Interaction: This isn't merely about your user(s) interacting with your software, but also everything involved. If your software checks for updates and downloads them then this would be an interaction of its own: one with the update server.
An UML deployment diagram showcasing my (brief!) impression of the PKGNG system.
Yes, I know I messed up there: it's pkg(8). That's what happens when you do this on a Friday evening (I made this diagram on the fly, my tool of choice makes those quite easy to set up). And now I'm too lazy to fix that
Also a standard!
But other than 14 diagram types UML is also an open standard set out by the OMG ("Object Management Group"), it even has its own website. But yeah, there is a formal specification available for download if you're interested in UML's inner working. Seriously though: if this subject remotely intrigues you then I'd seriously recommend to download and skim through the formal standards PDF file(s). You might be surprised at the amount of detail those provide.
Not just for developers or managers!
Look... UML is a tool. Just like a hammer. And although you may associate a hammer with a carpenter who'd use that to hammer in nails a hammer's use is not limited to that aspect alone. We may set out a "rule" that hammers are on this world to hunt for nails, fact of the matter is that they can also be used to form iron ("smithy"), break Windows, break glass windows (
I so couldn't resist) and a whole lot more destructive things.UML is not much different. It's a tool which can be used in many different ways. Heck, I once used a deployment diagram to showcase my network structure because at that time my modeling tool was the easiest option I had available.
In the end it is but merely a tool, and it's effects are entirely what you might make of it.
And if you are interested in all this... my advice: please don't let the means turn into some kind of goal of their own.
Anyway, thanks for reading so far. I'd now like to share a Youtube video shared by the OMG group in which one of the founders of UML (Grady Booch) reflects on the whole development:
Each to their own, but in my opinion these are interesting times. 20 years is quite an achievement if you ask me.
