UML is necessary to...
a) communicate things to external teams, because it is a standard language, like english for everything IT;
b) describe big systems.
Everyone knows a sequence diagram. Those who say don't use UML is because:
- they just use words (a really bad solution),
- they invent diagrams nobody understands (ok if nobody complains),
- they produce documentation nobody reads,
- they develop small systems, or
- they just don't document.
UML is necessary and useful. The problem with UML is that people try to use UML to do things. No. First, you do things, then, you describe them using UML.
Another fallacy: UML is not a method (and if you download a tool that forces you to follow a routine to organize your diagrams, DELETE IT!). If you use a tool that starts describing a database, and then it expresses the solution in UML and then it generates objects for that UML, DELETE IT! System architecture and system engineering are domains where YOU choose the solution. If you choose a solution that is not yours a) you will lose a good solution, the one that is probably in your mind and b) you will feel not comfortable with the foreign solution, you will not understand it, etc., you will FAIL! Prepackaged UML solutions describe a developer's view, not your solution.
Ergo, MU-UML is Ok if you prefer it, and all the target readers can understand it.
Here are some simple rules to use UML:
a) You should understand there are TWO classes of diagrams: static and dynamic. If you want to describe a radio receiver, there are two things you need to describe:
- The radio, when it is unplugged (its components, parts, connections, structure, organization, security, etc.), that is, the radio as a thing, and the things that each thing is build of. The radio as a thing can be described using UML static diagrams.
- The radio, when it is plugged (how it starts, how do parts interact, how are signals converted, treated, etc.), that is, the radio as a function, and each function's functions. The radio as a function can be described using UML dynamic diagrams.
b) UML is a language, not a tool. You START by describing something in words, AND THEN you select an appropriate diagram type and make your drawing. There is probably your blocking problem. Exercise! Define a problem, describe the approach in words using a UseCase diagram, describe what your solution does using dynamic UML diagrams and describe how it is built using static diagrams.
c) When you describe a system, you typically (it depends on each architect) describe it from at least three perspectives:
- The system as a thing (using static diagrams)
- The system as a function (using dynamic diagrams)
- The environment where the system runs (commonly, using static diagrams)
These depend on you. You can add more (e.g. a stakeholders synthesized description, a developers chapter, etc. The order is not important, but you usually put the thing/function parts at the start. I start with the functional part, then, the static part.
d) You don't need all the UML diagrams. Normally, I use a UseCase diagram to describe what the client wants in an introductory chapter, synthesizing the approach of the solution, then, I normally start with the dynamic view, using sequence, interaction and activity diagrams (others can be added if required). Then, I enter in the details of each component (static description chapter), using normally class and component diagrams. Then, I add a deployment section to describe the conditions and the environment where the system runs, mainly using component and package diagrams.
Regarding the tool, I'm fine with UMLet, because it leaves me the freedom to do whatever I need.