[ACCEPTED]-Is UML practical?-diagram

Using UML is like looking at your feet as 36 you walk. It's making conscious and explicit 35 something that you can usually do unconsciously. Beginners 34 need to think carefully about what they're 33 doing, but a professional programmer already 32 knows what they're doing. Most of the time, writing 31 the code itself is quicker and more effective 30 than writing about the code, because their 29 programming intuition is tuned to the task.

It's 28 not just about what you're doing though. What 27 about the new hire who comes in six months 26 from now and needs to come up to speed on 25 the code? What about five years from now 24 when everyone currently working on the project 23 is gone?

It's incredibly helpful to have 22 some basic up to date documentation available 21 for anyone who joins the project later. I 20 don't advocate full blown UML diagrams with 19 method names and parameters (WAY too difficult 18 to maintain), but I do think that a basic 17 diagram of the components in the system 16 with their relationships and basic behavior 15 is invaluable. Unless the design of the 14 system changes drastically, this information 13 shouldn't change a lot even as the implementation 12 is tweaked.

I've found that the key to documentation 11 is moderation. No one is going to read 10 50 pages of full blown UML diagrams with 9 design documentation without falling asleep 8 a few pages in. On the other hand, most 7 people would love to get 5-10 pages of simple 6 class diagrams with some basic descriptions 5 of how the system is put together.

The other 4 case where I've found UML to be useful is 3 for when a senior developer is responsible 2 for designing a component but then hands 1 the design to a junior developer to implement.

In a sufficiently complex system there are some places 9 where some UML is considered useful.

The useful 8 diagrams for a system, vary by applicability.
But 7 the most widely used ones are:

• Class Diagrams
• State Diagrams
• Activity Diagrams
• Sequence Diagrams

There are 6 many enterprises who swear by them and many 5 who outright reject them as an utter waste 4 of time and effort.

It's best not to go 3 overboard and think what's best for the 2 project you are on and pick the stuff that 1 is applicable and makes sense.

Using UML is like looking at your feet as 19 you walk. It's making conscious and explicit 18 something that you can usually do unconsciously. Beginners 17 need to think carefully about what they're 16 doing, but a professional programmer already 15 knows what they're doing. Most of the time, writing 14 the code itself is quicker and more effective 13 than writing about the code, because their 12 programming intuition is tuned to the task.

The 11 exception is why you find yourself in the 10 woods at night without a torch and it's 9 started to rain - then you need to look 8 at your feet to avoid falling down. There 7 are times when the task you've taken on 6 is more complicated than your intuition 5 can handle, and you need to slow down and 4 state the structure of your program explicitly. Then 3 UML is one of many tools you can use. Others 2 include pseudocode, high-level architecture 1 diagrams and strange metaphors.

Generic work-flow and DFDs can be very useful 4 for complex processes. All other diagramming 3 (ESPECIALLY UML) has, in my experience, without 2 exception been a painful waste of time and 1 effort.

I'd have to disagree, UML is used all over 18 the place - anywhere a IT project is being 17 designed UML will usually be there.

Now whether 16 it is being used well is another matter.

As Stu 15 said, I find both Use Cases (along with 14 the use case descriptions) and activity 13 diagrams to be the most helpful from a developer 12 point of view.

Class diagram can be very 11 useful when trying to show relationships, as 10 well as object attributes, such as persistence. When 9 it comes to adding ever single attribute 8 or property they are usually overkill, especially 7 as they often become out of date quickly 6 once code is written.

One of the biggest 5 problems with UML is the amount of work 4 required to keep it up to date once code 3 is being generated, as there are few tools 2 that can re-engineer UML from code, and 1 few still that do it well.

I will qualify my answer by mentioning that 6 I don't have experience in large (IBM-like) corporate 5 development environments.

The way I view 4 UML and the Rational Unified Process is that it's more TALKING about what 3 you're going to do than actually DOING what you're 2 going to do.

(In other words it's largely 1 a waste of time)

Throw away only in my opinion. UML is a 10 great tool for communicating ideas, the 9 only issue is when you store and maintain 8 it because you are essentially creating 7 two copies of the same information and this 6 is where it usually blows. After the initial 5 round of implementation most of the UML 4 should be generated from the source code 3 else it will go out of date very quickly 2 or require a lot of time (with manual errors) to 1 keep up to date.

I co-taught a senior-level development project 25 course my last two semesters in school. The 24 project was intended to be used in a production 23 environment with local non-profits as paying 22 clients. We had to be certain that code 21 did what we expected it to and that the 20 students were capturing all the data necessary 19 to meet the clients' needs.

Class time was 18 limited, as was my time outside of the classroom. As 17 such, we had to perform code reviews at 16 every class meeting, but with 25 students 15 enrolled individual review time was very 14 short. The tool we found most valuable in 13 these review sessions were ERD's, class 12 diagrams and sequence diagrams. ERD's and 11 class diagrams were done only in Visual 10 Studio, so the time required to create them 9 was trivial for the students.

The diagrams 8 communicated a great deal of information 7 very quickly. By having a quick overview 6 of the students' designs, we could quickly 5 isolate problem areas in their code and 4 perform a more detailed review on the spot.

Without 3 using diagrams, we would have had to take 2 the time to go one by one through the students' code 1 files looking for problems.

I am coming to this topic a little late 24 and will just try an clarify a couple minor 23 points. Asking if UML is useful as far 22 too broad. Most people seemed to answer 21 the question from the typical/popular UML 20 as a drawing/communication tool perspective. Note: Martin 19 Fowler and other UML book authors feel UML 18 is best used for communication only. However, there 17 are many other uses for UML. Above all, UML 16 is a modeling language that has notation 15 and diagrams mapped to the logical concepts. Here 14 are some uses for UML:

• Communication
• Standardized Design/Solution documentation
• DSL (Domain Specific Language) Definition
• Model Definition (UML Profiles)
• Pattern/Asset Usage
• Code Generation
• Model to Model transformations

Given the uses list 13 above the posting by Pascal is not sufficient 12 as it only speaks to diagram creation. A 11 project could benefit from UML if any of 10 the above are critical success factors or 9 are problem areas that need a standardized 8 solution.

The discussion should expanded 7 out from how UML can be over kill or applied 6 to small projects to discuss when UML makes 5 sense or will actually improve the product/solution 4 as that is when UML should be used. There 3 are situations where UML for one developer 2 could sense as well, such as Pattern Application 1 or Code Generation.

UML has worked for me for years. When I 3 started out I read Fowler's UML Distilled where he says 2 "do enough modelling/architecture/etc.". Just 1 use what you need!

From a QA Engineer's perspective, UML diagrams 2 point out potential flaws in logic and thought. Makes 1 my job easier :)

Though this discussion has long been inactive, I 17 have a couple of -to my mind important- points 16 to add.

Buggy code is one thing. Left to 15 drift downstream, design mistakes can get 14 very bloated and ugly indeed. UML, however, is 13 self-validating. By that I mean that in 12 allowing you to explore your models in multiple, mathematically 11 closed and mutually-checking dimensions, it 10 engenders robust design.

UML has another 9 important aspect: it "talks" directly to 8 our strongest capability, that of visualisation. Had, for 7 example, ITIL V3 (at heart simple enough) been 6 communicated in the form of UML diagrams, it 5 could have been published on a few dozen 4 A3 foldouts. Instead, it came out in several 3 tomes of truly biblical proportions, spawning 2 an entire industry, breathtaking costs and 1 widespread catatonic shock.

I believe there may be a way to utilize 21 Cockburn style UML fish,kite, and sea-level 20 use cases as described by Fowler in his 19 book "UML Distilled." My idea 18 was to employ Cockburn use cases as an aid 17 for code readability.

So I did an experiment 16 and there is a post here about it with the 15 Tag "UML" or "FOWLER." It 14 was a simple idea for c#. Find a way to 13 embed Cockburn use cases into the namespaces 12 of programming constructs (such as the class 11 and inner class namespaces or by making 10 use of the namespaces for enumerations). I 9 believe this could be a viable and simple 8 technique but still have questions and need 7 others to check it out. It could be good 6 for simple programs that need a kind of 5 pseudo-Domain Specific Language which can 4 exist right in the midst of the c# code 3 without any language extensions.

Please 2 check out the post if you are interested. Go 1 here.

I think the UML is useful thought I think 17 the 2.0 spec has made what was once a clear 16 specification somewhat bloated and cumbersome. I 15 do agree with the edition of timing diagrams 14 etc since they filled a void...

Learning 13 to use the UML effectively takes a bit of 12 practice. The most important point is to 11 communicate clearly, model when needed and 10 model as a team. Whiteboards are the best 9 tool that I've found. I have not seen any 8 "digital whiteboard software" that has managed 7 to capture the utility of an actual whiteboard.

That 6 being said I do like the following UML tools:

1. Violet 5 - If it were any more simple it would be 4 a piece of paper

2. Altova UModel - Good tool 3 for Java and C# Modeling

3. MagicDraw - My favorite 2 commercial tool for Modeling

4. Poseidon - Decent 1 tool with good bang for the buck

5. StarUML - Best open source modeling tool

UML diagrams are useful for capturing and 12 communicating requirements and ensuring 11 that the system meets those requirements. They 10 can be used iteratively and during various 9 stages of planning, design, development, and 8 testing.

From the topic: Using Models within the Development Process at http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

A model can 7 help you visualize the world in which your 6 system works, clarify users' needs, define 5 the architecture of your system, analyze 4 the code, and ensure that your code meets 3 the requirements.

You might also want to 2 read my response to the following post:

How to learn “good software design/architecture”? at 1 https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

I see sequence diagrams and activity diagrams 10 used fairly often. I do a lot of work with 9 "real-time" and embedded systems that interact 8 with other systems, and sequence diagrams 7 are very helpful in visualizing all the 6 interactions.

I like to do use-case diagrams, but 5 I haven't met too many people who think 4 they are valuable.

I've often wondered whether 3 Rational Rose is a good example of the kinds 2 of applications you get from UML-model-based 1 design. It's bloated, buggy, slow, ugly, ...

I found UML not really useful for very small 12 projects, but really suitable for larger 11 ones.

Essentially, it does not really matter 10 what you use, you just have to keep two 9 things in mind:

• You want some sort of architecture planning
• You want to be sure that everyone in the team is actually using the same technology for project planning

So UML is just that: A standard 8 on how you plan your projects. If you hire 7 new people, there are more likely to know 6 any existing standard - be it UML, Flowchard, Nassi-Schneiderman, whatever 5 - rather than your exising in-house stuff.

Using 4 UML for a single developer and/or a simple 3 software project seems overkill to me, but 2 when working in a larger team, I would definitely 1 want some standard for planning software.

UML is useful, yes indeed! The main uses 7 I've made of it were:

• Brainstorming about the ways a piece of software should work. It makes easy to communicate what you are thinking.
• Documenting the architecture of a system, it's patterns and the main relationships of its classes. It helps when someone enters your team, when you're leaving and want to make sure your successor will understand it, and when you eventually forget what the hell that little class was meant for.
• Documenting any architectural pattern you use on all your systems, for the same reasons of the dot above

I only disagree with 6 Michael when he says that using UML for a single developer and/or a simple software project seems overkill to him. I've used it 5 on my small personal projects, and having 4 them documented using UML saved me a lot 3 of time when I came back to them seven months 2 later and had completely forgotten how I 1 had built and put together all those classes.

One of the problems I have with UML is the 14 understandability of the specification. When 13 I try to really understand the semantics 12 of a particular diagram I quickly get lost 11 in the maze of meta-models and meta-meta-models. One 10 of the selling points of UML is that it 9 is less ambiguous than natural language. However, if 8 two, or more, engineers interpret a diagram 7 differently, it fails at the goal.

Also, I've 6 tried asking specific questions about the 5 super-structure document on several UML 4 forums, and to members of the OMG itself, with 3 little or no results. I don't think the 2 UML community is mature enough yet to support 1 itself.

Coming from a student, I find that UML has 12 very little use. I find it ironic that 11 PROGAMERS have yet to develop a program 10 that will automatically generate the things 9 that you have said are necessary. It would 8 be extremely simple to design a feature 7 into Visual Studio that could pull pieces 6 of the data, seek for definitions, and product 5 answers sufficent so that anyone could look 4 at it, great or small, and understand the 3 program. This would also keep it up to 2 date because it would take the information 1 directly from the code to produce the information.

UML is used as soon as you represent a class 10 with its fields and methods though it's 9 just a kind of UML diagram.

The problem with 8 UML is that the founders book is too vague.

UML 7 is just a language, it's not really a method.

As 6 for me, I really find annoying the lack 5 of UML schema for Opensource Projects. Take 4 something like Wordpress, you just have 3 a database schema, nothing else. You have 2 to wander around the codex api to try to 1 get the big picture.

UML has its place. It becomes increasingly 3 important as the size of the project grows. If 2 you have a long running project, then it 1 is best to document everything in UML.

UML seems to good for large projects with 8 large teams of people. However I've worked 7 in small teams where communication is better.

Using 6 UML-esque diagrams is good though, especially 5 in the planning stage. I tend to think in 4 code, so I find writing large specs hard. I 3 prefer to write down the inputs' and outputs' and 2 leave the developers to design the bit in 1 the middle.

I believe UML is useful just for the fact 7 that it gets people to think about the relationships 6 between their classes. It is a good starting 5 point to start thinking about such relationships, but 4 it is definitely not a solution for everybody.

My 3 belief is that the use of UML is subjective 2 to the situation in which the development 1 team is working.

In my experience:

The ability to create and 7 communicate meaningful code diagrams is 6 a necessary skill for any software engineer 5 who is developing new code, or attempting 4 to understand existing code.

Knowing the 3 specifics of UML - when to use a dashed 2 line, or a circle endpoint - is not quite 1 as necessary, but is still good to have.

UML is useful in two ways:

• Technical side: a 16 lot of people (manager and some functional 15 analyst) think that UML is a luxury feature 14 because The code is the documentation: you start coding, after you debug and fix. The sync of UML diagrams with 13 code and analisys force you to understand 12 well the requests of the customer;

• Management 11 side: the UMl diagrams are a mirror of the 10 requires of the customer who is inaccurate: if 9 you code without UML, maybe you can find 8 a bug in requires after a lot of hours of 7 work. The diagrams UML allow you to find 6 the possible controversal points and to 5 resolve before the coding =>help your 4 planning.

Generally, all the projects without 3 UML diagrams have a superficial analysis 2 or they have short size.

if you're in linkedin 1 group SYSTEMS ENGINEERS, see my old discussion.