How indepth should a programmer develop his understanding of the Unified Process and UML?

Question

I know a lot of places use UML and the unified process as their development model... but then there's a lot that don't. Would it be important to have more than a basic and functional understanding of these subjects or would it be better to focus on developing programming skills in other areas (i.e. language development, IDEs, etc)?

Answer 1

Unless you think watching paint dry while neck-deep in sewage is a jolly good time, ignore the Unified Process. Wait, ignoring it is not enough. Fear it. As far as I know, it's only used these days by enormous places that are beyond all hope of efficiency, quality, or sanity.

UML, on the other hand, can be a handy notation for important programming concepts. Get Martin Fowler's UML Distilled, give it a skim, and practice sketching diagrams while thinking about design. It's a skill I use regularly and I'm glad I have it.

Be aware that people try to over-use UML. Whiteboard UML while discussing things is awesome. An occasional diagram in published documentation can be nice. But the quest to document your entire code base in UML is pointless and wasteful. And the desire to "program in UML" is idiotic. If you come across people like that, flee. But first, brand their foreheads with a sequence diagram, so the rest of us are properly warned.

Answer 2

Don't spend too much time on UML. In my team I am the only one to know really well UML and therefore create use case, component, state, deployment and other diagrams. The other team members are better than me for codding but not as good for the UML diagramming.

The trick we use is to focus on the class diagram at modeling level to define the structure of the application and also let the developper/architect to code as they want. We then merge the model with the new code and update the model at each iteration. Really easy and very efficient. We develop in Java with Omondo EclipseUML.

I would recommend not to use any MDD which is for me a real crap !! Modeler will try to take more power inside development process but this will not create any value if they try to generate all the code from the model. The code belongs to the developer/architect but not to the modeler. UML should only be a view of the project requirements (e.g. usecase, sequence, etc....) the process (e.g. state or activty diagram), deployment (deployment, component diagrams). The class diagram should a view of the code and UML class diagram should only be used as a viewer of the code. Java coding should respect object approach and UML which is also an object language is really helpful to avoid crap and stupid codding.

The most important is the class diagram iterations between model to code and code to model. I don't really mean live synchronization, but to be able to merge code and model at each iteration. I use Omondo EclipseUML and think they are the only one to have merge java, database entities and model IDs. The ID merge is really a powerful concept and is perfect for our agile projects.

My recommendation is not to buy any book. You should have an object approach and use class diagram language to visualize your objects in order to create better architectures. If one of the team member knows UML then use the other diagrams, if not the class diagram would be sufficient.

Answer 3

The Unified Process and UML are a set of structured thinking and communication tools. These tools help in a few ways; both by defining a way of talking about designs, and by helping us work through the details and facets of our designs.

Improving your own thinking is critical for completing the details of a design and for finding your path to a sane and coherent product. Personal disciplines help you focus, keep track of details, think through the edges, and remember what your thinking is months later.

Improving how the design is talked about and improved is critical for getting a group of designers get further, faster. Group disciplines help get more from the group.

But remember tat UML and the Unified Process are only one of many thinking tools. They're reasonable, but they may or may not fit you or your group (which is as important as any other factor).

Answer 4

In my mind there is now way around UML. Get a book and learn it. You need it to :

• read technical books that use UML (there are a lot)
• use it as a sketching tool to discuss idea's/solutions with colleges.
• give yourself a quick way to visualize the solution you are thinking of and reason about it.
• read/reason about technical/functional designs at certain companies

The unified process I think is a different story, it depends on the employer you are at. I would read a book at least to know what it is and when the time comes that you really need it study it.

Hope this helps.

Answer 5

I don't think that you need an extremely in-depth knowledge of UML but you should definitely be able to look at a diagram and be able to tell what's going on. What you SHOULD try to get an in-depth knowledge is different design patterns (buy a book). When you come up with your own designs, it will help you to know both the design pattern and UML pattern even if you don't actually draw it out. It also helps you in understanding a UML diagram when you see it, because you might understand a little better why the UML looks like that.

Answer 6

I've been in this biz since 1987 and the only times I've dealt with UML and the Unified Process was a few occasions when some misbegotten consultant got paid some very big bucks to force feed the staff with all the minutiae of these overhyped, overblown, and tendentious methodologies. In the aftermath of every attempt to apply this unadulterated crap we ended up generating enough almost-immediately obsolete documentation to fill the Library of Congress to overflowing and beyond, while simultaneously slowing the design and development of our projects unconscionably.

If your business product is to be measured in pounds of paper and/or the size of the documentation, will never be read more than once (if that many), and will forever afterwards be obsolete, and that will be the basis on which you are paid, then by all means, go whole hog with this crap.

If otherwise, run screaming for the hills upon the first mention of UML and UP. Or better, beat the first person who utters it to a pulp.

Answer 7

You may mention that you could use U.M.L. WITHOUT the Unified Process. I use a lot of U.M.L. at the same time than programming, but, for me is important to be in a practical way, not just use it because "its a shinny new tool".

Class diagrams, use cases and sequential diagrams are my favorite. I don't require use other kinds of diagrams as often, as these ones.

Many companies doesn't use the Unified/Rational Process.