Why design with UML?
Author
In short what benifits does it bring to the table? One obvious one is that it is language independent, but what are others?
Regards
Chad
UML is excellent for communication, rather than design. It helps describe a complex system in a few words and a few strokes on a white board. It may also be useful for communicating with yourself, but it's not necessary (some people just don't have a visual memory).
It introduces universal grammar and syntax for describing how a system works.
When trying to explain to someone the relations between various parts of code, you need to use certain terminology. UML simply defines one for you, on top of it its language independant (spoken and computer).
It also has a side-effect of mildly enforcing good design, since complex systems quickly result in an incomprehensible mesh (unfortunately, to some that's fine).
Think of it as SQL. There's plenty of ways to describe relations between data. SQL is just universal way of expressing it.
When trying to explain to someone the relations between various parts of code, you need to use certain terminology. UML simply defines one for you, on top of it its language independant (spoken and computer).
It also has a side-effect of mildly enforcing good design, since complex systems quickly result in an incomprehensible mesh (unfortunately, to some that's fine).
Think of it as SQL. There's plenty of ways to describe relations between data. SQL is just universal way of expressing it.
It summarises the architecture more concisely than the code does, so it's easy to see class relationships at a glance.
A few reasons, some of which have been explained.
It allows someone to look at a system in code without looking at code. The ideas and functionality are more apparent to the reader when its laid out for you in a simle format. Thus, someone not privy to code (such as an executive) can understand to a degree what your intentions are and how a system will work.
Its not only used for code but for business models as well to communicate processes, ideas, organizational information etc throughout a team or executive staff.
Getting back to code, everyone deigns, if not they should. Designing with UML not only allows you to get your thoughts on paper and perhaps see what you are doing wrong, great, or what could be done better, but some UML programs have an added bonus; you can click a button and it will generate the code (if designed properly) and create the classes and functions you will need to implement the design you created. This helps cut back the time taken by design away from coding. Some people rely on design by code, which is to say the write code and design as they go. This UML feature lets you seriously design something with hard documentation for people not familiar with the system, but gives you back some of that time by writing the code for you.
However, you must be exceptionally well versed in UML to do this effectively, but the tool is there.
Design isnt something alot of people think they need, but everyone should do it. So documenting with UML is a step in the right direction as the 'U' states, it is unified. Having stepped into a new company never seeing their code or design specs would be tough, if they use UML and you know it you are that much closer to being familiar with their system.
It allows someone to look at a system in code without looking at code. The ideas and functionality are more apparent to the reader when its laid out for you in a simle format. Thus, someone not privy to code (such as an executive) can understand to a degree what your intentions are and how a system will work.
Its not only used for code but for business models as well to communicate processes, ideas, organizational information etc throughout a team or executive staff.
Getting back to code, everyone deigns, if not they should. Designing with UML not only allows you to get your thoughts on paper and perhaps see what you are doing wrong, great, or what could be done better, but some UML programs have an added bonus; you can click a button and it will generate the code (if designed properly) and create the classes and functions you will need to implement the design you created. This helps cut back the time taken by design away from coding. Some people rely on design by code, which is to say the write code and design as they go. This UML feature lets you seriously design something with hard documentation for people not familiar with the system, but gives you back some of that time by writing the code for you.
However, you must be exceptionally well versed in UML to do this effectively, but the tool is there.
Design isnt something alot of people think they need, but everyone should do it. So documenting with UML is a step in the right direction as the 'U' states, it is unified. Having stepped into a new company never seeing their code or design specs would be tough, if they use UML and you know it you are that much closer to being familiar with their system.
I find it best used on the project manager types who don't have any concept of what's going on. Even then it isn't UML so much as high level flow diagrams. There is no reason for him to see each class representation.
Add one more vote for the 'universal representation'. I think most people don't really speak formal UML, just an informal subset. Like when drawing a class diagram, I typically don't write down every friggin member, only the ones that are real important for the design. But it's a great tool when working out an architecture with a group of people, or when you have a fuzzy idea of what your project should look like, it's a great way of ironing things out.
It's a formalism. Almost every programmer, given paper and pen and asked to "draw a diagram of all the classes and how they interact with each other", would probably draw something similar (if considerably messier). The idea behind standardizing exactly how the things are drawn is (a) making sure the drawing makes sense to everyone else and (b) encouraging people to actually do the drawings.
OTOH, drawings are just drawings. Even with a tool for manipulating UML diagrams, making changes in real-time (e.g. while discussing the design with a peer) is pretty clumsy. You might consider this approach instead.
OTOH, drawings are just drawings. Even with a tool for manipulating UML diagrams, making changes in real-time (e.g. while discussing the design with a peer) is pretty clumsy. You might consider this approach instead.
Quote:Original post by chadsxe
In short what benifits does it bring to the table? One obvious one is that it is language independent, but what are others?
Regards
Chad
You don't design with UML, you represent a design. UML is a standardized language, it's the lingua franca used to communicate design ideas and implementation. Because it is standardized, it is the prefered way to communicate between teams (since you can expect the other guys to understand what you want to express).
It's also quite simple to get a first grasp to UML (only use a limited set of diagrams), and the language is quite coherent.
Quote:Original post by Zahlman
...You might consider this approach instead.
Oh, I had always considered CRC being part of the whole sofware analysis process somehow. This will help you find your classes and how they interact. (afaik) You might still want to have a standardized way of drawing it on paper where you can go to any developer on the planet, show it and be understood.
I always want to force myself that for once, I should go through all the UML stuff for my next project, do all the funny diagrams and all the documents. I end up being depressed and stop it. But just for the experience I think it might be good, let alone the many design mistakes I could avoid while doing a thorough plan.
I hate and like UML. I lack the experience to make good diagrams and plans but I really love to work after I did a lot of them. From then on it is just implementing all the arrows and boxes and circles. A little like drawing by numbers. At least there will be very little times when you have to admit to yourself "oh sh.., I've never thought of that before... I think I'll need to restart from scratch."
But Zahlman might be right. Maybe all the UML stuff is too much if you just want to plan something. CRC might be just enough to bring something to paper and avoid major design mistakes.
-- In Ulm um Ulm und um Ulm herum. UML? UML?!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
