UML illustrates useless junk.
They don't replace your text, they just compound more confusion onto your utterly horrid system design.
It can sully any development methodology by its presence, even XP.
UML is heavyweight in the same way a sledgehammer cracks a nut.
It is boxes joined up by lines codified and suitable for consumption by clueless enterprisey managers
You are allowed to colour in UML diagrams for contrast as long as you keep within the lines.
Should you use UML?
Short answer: no
Long answer: if what you're explaining needs a diagram, use a diagram to help communicate your ideas clearly. If you are competent enough you shouldn't need to rely on something like UML to get the idea across. However, if your project and/or your own skills are comparable to a steaming turd, use UML.
"If you are not saying much don't use a great big diagram"
What should you put in a UML diagram?
Some people link it with heavyweight processes and think the diagram should contain everything in the known universe plus a full proof of Fermat's last theorem. But they're wrong!
It's just about illustration.
If you need to express some relationships between classes, you draw a diagram showing the relationships. You probably do this anyway and don't need some crazy ruleset to help you do this.
Not many projects have a relationship diagram as interesting as (say) MediaWiki, and that's pretty dry stuff, so for the love of god don't do it. Every time you do so, you help some South American clear space to build a soy farm for 3 years, ravaging the environment in the long term. For your next trick, let's shoot an RPG at an oil tanker. 10 points for each oil-smothered penguin!
"A good report is one you can't put down."
An enterprisey report is one you can't lift up, unaided.
If you want to draw simple diagrams, you can use something small and simple like a pen and paper.
Alternatively, use UMLet.
There's more sophisticated tools like Poseidon.
Thinking of jumping off the suspension bridge? Try googling "UML diagram tools" first!
Use case diagrams.
People who can't program are IDIOTS. You need a SIMPLE diagram to get through their THICK skulls. URRRRR!
You draw users as stickmen. This is CUTE. Then you have some lines and a circle with what they're going to do.
Congratulations! Using a diagram you just drew a 7-word sentence in ten times the time.
This is good - the MORONS you are building software for can UNDERSTAND you now!
An actor is a user outside the system.
Imagine a mime artist trapped in a box, and you have an actor.
Like mime artists, actors are supremely irritating and have almost as many stripes/dashes.
An actor can also be a computer program/search engine, but draw it as a stickman anyway because your supremely THICK users wouldn't understand a graphic of a computer.
A use case is something the system is supposed to do. It's a global operation of the system. Diagrams help you think about the different uses of a system.
The basic format of a use case diagram is a stickman (of course), and a bulleted list. But instead of bullet points, imagine they've gone hollow and decided to swallow the list elements whole, like demented typographical macrophages. Nom nom.
The standard relationship is a line. For the kind of person who relies on a UML diagram, this is probably the only substantial relationship they'll have.
Occasionally the lines will have hollow arrowheads at the end. You can think of it as 'extends' in Java. Extending a thin line does little to impress the ladies, but I digress.
Apparently these serve to simplify diagrams. For some reason it isn't allowed to connect a line from one relationship to another. I don't make the rules.
One use case can be a generalization of another. Another relationship is inclusion: 'one thing is part of another thing'. This has a special arrowhead and a label, but be careful you don't confuse it with the hollow arrowhead. You might change the meaning of the system entirely and get confused because your addled brain can't cope with reasonable assumptions or critical thought.
Something about stereotypes were glossed over completely. Probably for the best.
There are other features but nobody gives a shit anymore. Honestly. What is the point of this crap.
It's simplistic, childish, devoid of real use... but it adds a buzzword. What more do you want?
NEXT! Class diagrams. These show the object-oriented structure of a program. Now, ignore for a moment the problems with object-orientation and assume all our problems can be solved completely by it. This is basically a code definition - something not very helpful to most people - of the class name, its members and functions.
In addition, these classes may or may not exist in the final code.
You can show the class at any level of detail that you like. You need to be reminded of this just in case you felt you had to mindlessly follow such verbosity all the time; to be fair, you honestly, probably do.
An empty-headed arrow is as stupid as the representation suggests, showing a superclass relationship. Italics denote classes without objects.
Relationships have diamondheads. Filled diamond indicates ownerships (harking back to an earlier time of dark shapes being owned... oh, I won't labour this point)
Hollow diamonds indicate non-owned parts.
Read the label in the direction you are going.
This is probably one of the only useful parts of UML, and you don't need a whole infrastructure to get you to the kind of database relationship diagrams they made you do for GCSE IT. Honestly.
Aaaand just as something useful came up the lecture on it ends. How ominous.
They don't replace your text, they just compound more confusion onto your utterly horrid system design.
It can sully any development methodology by its presence, even XP.
UML is heavyweight in the same way a sledgehammer cracks a nut.
It is boxes joined up by lines codified and suitable for consumption by clueless enterprisey managers
You are allowed to colour in UML diagrams for contrast as long as you keep within the lines.
Should you use UML?
Short answer: no
Long answer: if what you're explaining needs a diagram, use a diagram to help communicate your ideas clearly. If you are competent enough you shouldn't need to rely on something like UML to get the idea across. However, if your project and/or your own skills are comparable to a steaming turd, use UML.
"If you are not saying much don't use a great big diagram"
What should you put in a UML diagram?
Some people link it with heavyweight processes and think the diagram should contain everything in the known universe plus a full proof of Fermat's last theorem. But they're wrong!
It's just about illustration.
If you need to express some relationships between classes, you draw a diagram showing the relationships. You probably do this anyway and don't need some crazy ruleset to help you do this.
Not many projects have a relationship diagram as interesting as (say) MediaWiki, and that's pretty dry stuff, so for the love of god don't do it. Every time you do so, you help some South American clear space to build a soy farm for 3 years, ravaging the environment in the long term. For your next trick, let's shoot an RPG at an oil tanker. 10 points for each oil-smothered penguin!
"A good report is one you can't put down."
An enterprisey report is one you can't lift up, unaided.
If you want to draw simple diagrams, you can use something small and simple like a pen and paper.
Alternatively, use UMLet.
There's more sophisticated tools like Poseidon.
Thinking of jumping off the suspension bridge? Try googling "UML diagram tools" first!
Use case diagrams.
People who can't program are IDIOTS. You need a SIMPLE diagram to get through their THICK skulls. URRRRR!
You draw users as stickmen. This is CUTE. Then you have some lines and a circle with what they're going to do.
Congratulations! Using a diagram you just drew a 7-word sentence in ten times the time.
This is good - the MORONS you are building software for can UNDERSTAND you now!
An actor is a user outside the system.
Imagine a mime artist trapped in a box, and you have an actor.
Like mime artists, actors are supremely irritating and have almost as many stripes/dashes.
An actor can also be a computer program/search engine, but draw it as a stickman anyway because your supremely THICK users wouldn't understand a graphic of a computer.
A use case is something the system is supposed to do. It's a global operation of the system. Diagrams help you think about the different uses of a system.
The basic format of a use case diagram is a stickman (of course), and a bulleted list. But instead of bullet points, imagine they've gone hollow and decided to swallow the list elements whole, like demented typographical macrophages. Nom nom.
The standard relationship is a line. For the kind of person who relies on a UML diagram, this is probably the only substantial relationship they'll have.
Occasionally the lines will have hollow arrowheads at the end. You can think of it as 'extends' in Java. Extending a thin line does little to impress the ladies, but I digress.
Apparently these serve to simplify diagrams. For some reason it isn't allowed to connect a line from one relationship to another. I don't make the rules.
One use case can be a generalization of another. Another relationship is inclusion: 'one thing is part of another thing'. This has a special arrowhead and a label, but be careful you don't confuse it with the hollow arrowhead. You might change the meaning of the system entirely and get confused because your addled brain can't cope with reasonable assumptions or critical thought.
Something about stereotypes were glossed over completely. Probably for the best.
There are other features but nobody gives a shit anymore. Honestly. What is the point of this crap.
It's simplistic, childish, devoid of real use... but it adds a buzzword. What more do you want?
NEXT! Class diagrams. These show the object-oriented structure of a program. Now, ignore for a moment the problems with object-orientation and assume all our problems can be solved completely by it. This is basically a code definition - something not very helpful to most people - of the class name, its members and functions.
In addition, these classes may or may not exist in the final code.
You can show the class at any level of detail that you like. You need to be reminded of this just in case you felt you had to mindlessly follow such verbosity all the time; to be fair, you honestly, probably do.
An empty-headed arrow is as stupid as the representation suggests, showing a superclass relationship. Italics denote classes without objects.
Relationships have diamondheads. Filled diamond indicates ownerships (harking back to an earlier time of dark shapes being owned... oh, I won't labour this point)
Hollow diamonds indicate non-owned parts.
Read the label in the direction you are going.
This is probably one of the only useful parts of UML, and you don't need a whole infrastructure to get you to the kind of database relationship diagrams they made you do for GCSE IT. Honestly.
Aaaand just as something useful came up the lecture on it ends. How ominous.
Leave a comment