I just lurk on this list. But UML modeling is not BS when used in some places.
In Linux or BSD programming, though, it would only really work for user applications that are more OOP; UML isn't easy to do in C. [No need to whack me, I know that OOP can be done in ANSI C but it usually is not.] If you are going to use Objects and go that route in your programming, then UML can be very helpful. Because UML is intimately tied to the understanding of the _state_ of an object looked at through multiple charts. Unfortunately there is a broad, learned consensus that most people that use OOP don't actually do OOP correctly. When you are looking at UML you are really getting a handle on the state transitions, and that is mostly a object understanding of programming. It _is_ very useful for user space applications if used correctly and used for object-oriented programming in C++ or Java or Smalltalk (or even Ruby or Python). It would help to define your objects that are needed and the states of the objects through the lifetime of the application. Ideally too, the use of UML helps to constrain your thinking, meaning you have to put the messages that the objects pass with the correct objects and not leave 'globals' that lurk around the application (which often happens in bad OOP design). And this modeling naturally leads to the code objects needed and object abstractions needed to do the code Interfaces, that will in turn be used to create the objects through the implementation of those interfaces. Two (very big) caveats, though, must be admitted straight off. First, UML is hard to work with in procedural languages. Since Linux or BSD is still mostly written and extended in C then it is really hard to use it successfully. Procedural languages don't have the same 'context' of thinking as OOP languages (even the hybrids like C++). C doesn't have the programming contexts (as usually written) that allow for language-based interface creation, or inheritance. And remember, C is usually used as a collection of small programs working together, not with a large monolithic 'driver' program that collects instantiations of objects that then pass messages to one another. What I mean to say is that the C requires (mostly) a different way of thinking as that which you are trying to ideally use in UML. Many Linux kernel people openly express hatred for C++ and Java - these people are very wedded to the understanding of smaller programs often piped together to do something useful. For those persons UML would be complete waste of time (and I'd agree with the characterization and the talent of these people). Secondly, UML is difficult to use without discipline. So UML doesn't fit (at all) the traditional (and useful) understanding of the software hacker who wants to get the program working and will happily rewrite and revise many times to get it just right. It is more a learned discipline, and I agree that initially it could seem heavy-handed and unnecessarily large and complex. But in your CS classes you are NOT designing a system with 5000 objects in three large modules with 15 programmers working in tandem. I'd argue that the state transition understanding given by good UML discipline can be helpful such larger projects, since you really, really want to know what someone else's code is supposed to do at a transition point. The model would clarify the issues AND constrain the required transitions expected from someone else. [If you are expecting a message of one type and get another from another programmer's code, then someone has not followed the model!] Also there is something else that should be mentioned if you are going to use OOP since there is at least one place that UML can really help you - especially if you are going to work in teams of programmers larger than 3. In addition to constraining your thinking along the lines of "where does the originator of message live?" it also (when done right) can work as a natural prototyping language. Fred Brooks (controversially) wrote that every programmer working with a new program should "Plan to throw one version of the software away - you will anyway." He meant, of course, that it is difficult to get all of the understandings of a program correct the first time. I would argue strongly that UML done correctly and thoroughly could help you design the first one or two versions of a system with modeling only, and then allow those to be thrown away with paper before coding actually begins. Used with disciple UML could really help to clarify what is needed, and can even help prevent scope creep if the objects are done correctly. But again, it really only cleanly works (in most cases) with object programming and those languages which naturally lend themselves to 'classes' and 'inheritance' and 'message passing'. Indeed, if you are working in C you could still do this prototyping with paper as well - though constraining yourself to UML would be somewhat pointless. Finally, you should know that RUP is a _process_ that uses UML. UML is a discipline that doesn't need RUP. I'm not a fan of RUP, but I can see how it might be helpful in large shops to clarify all of the issues in both programming and when planning business issues. UML can be done with pen and paper, or with a drawing tool. There is a free one from Cay Horstman called "Violet". And there are for-pay ones that are good as well for drawing the forms, etc. [I've used MetaMill and I like it. I think it is about 100 USD for a single user.] One negative of computer drawing is that the promise of code generation doesn't seem to actually work very well. No tool that I've ever worked with should be used for code generation apart from a starting point. Basically UML is a process of object-oriented design and you can take it or leave it. But I've never met anyone that understood and used it who did not become a much better object _programmer_ (without the procedural logic mixed with his objects, and the global variables needed to hold stray messages). YMMV --- On Wed, 5/5/10, Christiano F. Haesbaert <haesba...@haesbaert.org> wrote: > From: Christiano F. Haesbaert <haesba...@haesbaert.org> > Subject: OT - UML, can someone state that it works ? > To: "OpenBSD Questions" <misc@openbsd.org> > Date: Wednesday, May 5, 2010, 7:08 PM > Sorry for such an out of topic > thread, hear my pain: > > I'm really sick of hearing about UML/RUP and all this > boulshit about > software engineering in my university. > > My feeling is that someone wrote it, never implemented it, > and for > some stupid reason, the industry/academia bought it. > > So as I regard the openbsd folks as highly skilled > developers, I ask > for your opinion. > > Is my impression completely wrong ? > > Do any of you believe in it ? > > Thanks.
