[TriggaMike]

I've been "forced" to use UML since I started learning how to program. There are portions of the Language that I find useful, such as class diagrams. It's nice to have standards for these so I can say:

-counter:int

This is the definition of a private field (if I had included it in the second box of my Class Diagram) of type int with the name counter. This way can save you typing out public, private, protected, static, etc. Although I like this, it is heavily dependent on what language you are using, and how you are using it. For example, in Objective-C if I wanted an "instance" method, I would go:

-(void)IAmAnInstanceMethod;

UML does not seem to be very applicable to this language, since it only has two access modifiers, - and +, and class fields can be declared, and have getters and setters in a matter of 2 lines of code, less work than diagramming your class using UML.

My real problems with UML begin when getting into the more complex areas of UML.

One of these problems, sequence diagrams, seem to keep haunting me. These diagrams are used to model how classes are created, destroyed, communicate, loop, make decisions, where your program will end up, and more. Mapping this out mentally would give me nothing but a headache, but putting this on paper doesn't do much more for me either. Once I get to this point I feel like it would be much more beneficial to simply start programming. I don't see a point to mapping out every little detail of functionality visually for the sake of understanding the flow of my program.

Thoughts?

[Programmist]

I use UML to model my designs all the time. I find that it is especially useful before I have done any coding. If you are trying to make UML fit a language then you probably need to back off a few levels of abstraction and think about the design agnostic of implementation. My biggest problem with UML is other people. I find that my diagrams often don't get the critical eye that I would like because so few people seem to know how to read them. And without UML I end up having to resort to lengthy anecdotal descriptions and non-standard notation.

[TriggaMike]

Programmist, on 01 March 2010 - 08:24 PM, said:

I find that my diagrams often don't get the critical eye that I would like because so few people seem to know how to read them.

This point has been reinforced to me by a few people I know in industry as well.

I can understand what you're saying though. In my eyes the tool isn't as useful because the way it models things just doesn't make sense to me, or isn't obvious. I would find writing either straight code, or perhaps even pseudo code more beneficial.

So is it more determinant on how you think, or perhaps the complexity of the program, combinations of those elements?

[coden4fun]

I was watching a good video from htp://tekpub.com entitled, "Coders for Developers" and the overall theme from the video was to be open-minded and try tools out, and he hinted how it was in the book, which is entitled same as the video. The book itself talked about how too much of design, preparation, certain methodologies can be harmful to the overall development life-cycle. Here, I must agree. It is great to design UML's, to get wire-frames from designers, and to possibly write functional requirements to your designers, boss, other developers working with you; however, when can we step back and say enough is just enough.

My point if it is some how entangled up in the mess I wrote above is the following;

Sometimes we're going to be working with tools that we don't like, however, to become a truly good programmer we need to step back our prejudices and allow time to get use to them, and at least try them out.

On the other hand working with UML, functional requirements, and other tools and models during the development life-cycle can boggle you down, so as developers we need to find a balance. Sometimes a UML will be needed, but other times it's redundant if you have other information and designs in front of you before working on the project.

It's a good idea to learn how to do it, but only use it when it will come in handy. I have found that hard as a developer who does contract work. When I'm pressed for a deadline and I'm working on large projects I ask myself do I just use a whiteboard and write a psuedo diagram and psuedo functional requirements, or do I just start with code?

I have found it to be a very difficult question, but I always some how succeed, so I'm still learning.

[LetMeFinclOut]

I once listened to an MIT professor present his thoughts on various anti-patterns in the industry.

He essentially described UML as a very heavy (600+ pages) design-by-comittee specification which tries to be all things to all people and serves only functions as a descriptive language with no true validation capabilities. From my own experience, I've found UML to be of very little use for anything of medium complexity or above as there's just too much information compacted together for it to retain its organizational properties.

Regarding validation, his answer is an Alloy specification language created between him and his students which allows for various built-in model simulations and constraint checking. I can'y speak for it personally as I havern't used it myself, but it may be worth a look.
http://alloy.mit.edu

[Ace26]

One very essential part of any software development cycle is analysis and design. Get this wrong and you pay the price of extra and extra programming hours. If you work on a team then communication is impotrtant. And one very effective way to communicate your design is through a universal design language - UML. It is very necessary for "every" developer to understand the constructs of this modeling language so as to stay afloat when another programmer (maybe fom another part of this planet) communicates his own design to you.

Also UML greatly aids in reducing and abstracting the complexity of a system. You see it all pictorially-how objects collaborate; the entire structure of the system under contruction e.t.c. This goes to aid understanding of functionalities, structure and behaviour of the system-a very good guide for contruction.

Trust me, the usefulness of this modeling language can't be over emphasized.

[EvLSnoopY]

Guest, on 02 March 2010 - 03:55 AM, said:

Ace26, on 02 March 2010 - 03:33 AM, said:

Also UML greatly aids in reducing and abstracting the complexity of a system. You see it all pictorially-how objects collaborate; the entire structure of the system under contruction e.t.c. This goes to aid understanding of functionalities, structure and behaviour of the system-a very good guide for construction.

I would have to agree. After reading the above posts I get the sense that people have forgotten what a UML diagram's purpose really is. UML diagrams are not meant to be an exact copy of a program, and thus only the elements that are important to the pattern (design pattern) under consideration are shown.

Wow that was weird. I guess I got logged out while I was typing this post. Sorry for the double post guys.

This post has been edited by EvLSnoopY: 02 March 2010 - 04:58 AM

[NeoTifa]

Bitch, don't even get me started! You know how I feel about preplanning and documentation!!!

I use them all the time. Mostly, though, for small projects I do a half-assed one on paper, but for like P:N and stuff I have MS Visio files. ^__^

[Lang14]

UML is a great way to help you conceptually plan out an application and any programmer would benefit from creating one.

I've heard from colleagues from previous employers that they have been forced to create UML diagrams and all it did for them was slow down development.

There are some that need UML diagrams and some that don't.

For larger projects a UML diagram is a boon.

That being said forcing should be a non-issue. Programmers go to college/university to learn proper coding techniques, let them be the judge on whether they need a conceptual map or not.

[TriggaMike]

Looking over this topic I guess I was thinking about this a different way. I have learned UML and think that it does aid in design of larger programs, and does save large amounts of work.

I guess what I'm getting at is, do we use UML as the tool because it's good at what it does, or do we use UML as a tool because everyone uses UML and that's what we're expected to know.

For example we could tell people to learn English because it's the "International Business Language". Does that mean English is better than other languages, or does it just mean it's more common? English isn't exactly an easy language to pick up for numerous reasons. There are many special cases, caveats, tones, and literary vehicles that make ideas conveyed very rich, but also difficult to understand for those who are not English speaking. Japanese for example doesn't use tone, and yet it still performs the same function as English.

I'm just wondering if there is a simpler way to communicate software ideas.

[MentalFloss]

Quote

I'm just wondering if there is a simpler way to communicate software ideas.

Yeah, they're called design patterns.

In context to UML though, some diagrams are more beneficial than others. If you use them in the right spot, it can be pretty elucidating.

For example, very high level operations might be modeled in an activity diagram. This makes sense because you're focusing on concepts interacting with each other. Alternately, you might use a use-case diagram instead.

When you are attempting to model a multi-threaded application, perhaps a sequence diagram will make things clearer. It'd just be this facet of the application though - not the whole thing. Another useful diagram might be the state diagram.

When you want the ability to view hierarchical relationships between objects, a class diagram is really good at that.

There shouldn't be just one diagram of the whole system. That would be insane to work with. The diagrams should instead attempt to explain a self-contained portion of the entire application. Everything outside of a given diagram should be treated as untrusted code. Pretend you aren't writing it, don't know anything about it (except for the public interface), and cannot modify it.

When you do this for all parts (and each diagram can be taken as its own entity) then you will end up with a wonderful mapping of all aspects of the application in manageable enough chunks to be useful.

So, yes - UML is pretty useful. Don't worry too much about the standards and such though. Really, it's just a tool to visualize concepts. If you're constantly having to look up whether to use a dotted open arrow instead of a solid closed arrow then obviously the scope of the tool is being lost.

[TriggaMike]

Thank you MentalFloss! Fantastic description! Very helpful!

[NeoTifa]

Well, I would say both, Mike. I do it because I find it a useful tool when programming AND because everybody else uses it. I am a big fan of standardization and organization. If everyone does their charts way differently, how can anyone understand what's going on? (or supposed to go on rather )

[NickDMax]

Quote

So, yes - UML is pretty useful. Don't worry too much about the standards and such though. Really, it's just a tool to visualize concepts. If you're constantly having to look up whether to use a dotted open arrow instead of a solid closed arrow then obviously the scope of the tool is being lost.

+1

There are various efforts to make code generators off of UML and they usually work OK-ish for specific languages but fall apart when trying to support others -- generally though UML is most useful for conveying the design ideas and less so with the details. So I personally tend to get a little lax with the "standards" and just try to communicate the ideas that I need so that other developers/architects/"project managers" can understand what I am talking about.

Generally speaking one should not try to pack all of the details of a program into a diagram. The diagrams quickly become unusable with detail. So with UML paint with broad strokes and try more to convey the essence of the design and less so the details of implementation (unless there is some "trick" or other oddity that needs explanation).

I think if you stick to using at a design & documentation tool and less of a development tool then you will find that it works well. Because it is pretty standard you don't have to spend a lot of time explaining the diagrams and because it is a structured language there are many tool out there that can help you generate the diagrams.

(though I personally don't have much use for many parts of UML -- I have never understood "use case diagrams" myself... they might be more useful than I gave them credit for though, I used to be confused by sequence diagrams and now they are actually my favorite)