[Shellvent] Happy 20th anniversary UML!

Hi gang!

Warning: although I'll definitely (mostly) stay to the facts I'm certain that some parts of my post will turn into a bit of an opinionated approach. The problem is simple: I'm honestly a little bit passionate about this and when that happens, especially on a Friday evening when I want to let off some steam.. yeah ;)

(minor) spam: Parts of this message were made with devel/visualparadigm. A commercial modeling tool (with a free to use community license), developed in Java thus supporting all major platforms and in my humble opinion pretty much the best software available today if you're interested in modeling languages. For full transparency: yes, I am biased. I've been using this software (licensed) ever since I started using NetBeans 4.1 in 2005, ergo I've been using Visual Paradigm for 13 years now. So yes, I am probably biased, but I also have good reasons for that :)

UML turned 20!

UML_map.jpg

UML is an acronym for Unified Modeling Language; it is basically a collection of diagram types used to describe several parts of a system and it's mostly used within the field of software development. The idea behind UML is basically to have an option to describe the functionality of a (software) project in a way which doesn't discriminate between languages. In other words: whether you program in C, Java, C#, Python or even with Perl, Awk and/or a plain shell script: UML can be a tool to display and/or document how your system works in a way which is fully independent of that programming (or scripting) language. Instead of showing code you'd be showing pictures. And you know what they say: a picture can often tell more than a thousand words.

Unfortunately, but this is just my opinion, UML is also a tool which is often misunderstood. As you can see in the diagram above the whole methodology consists of 14 diagrams in total which each showcase different aspects of your system. Which quickly led to some people thinking that in order to have a "valid" UML project going you'd need to produce at least 1/3'rd of the available diagram types. Madness... Or you can sometimes be dealing with people who are more concerned with the validity of their diagrams than the information which it should be showcasing which I consider just as stupid. And the worst case of them all: UML, and other modeling languages, are often associated with manager type beancounters who seem more obsessed with their (virtual) presentations than the actual happenings on the workfloor. This is because of good reasons mind you, but it still saddens me because it doesn't have to be this way.

UML: love/hate scenario?

I know there are many developers out there who either hate UML or simply don't see the use for it. I mean; why design something in theory if you could also spent all that time fantasizing on coding and actually get some work done?

Well... although it's definitely true that UML (or modeling / software design as a whole) is often (mis?)used by manager type beancounters who care more about their precious presentation and modeling standards there's still something to be said for designing. It's not so much the designing aspect mind you, but more so the attempt to think ahead of what might be to come for your project.

Sometimes a little planning can go a long way. What do MySQL, the Linux kernel and the NetBeans Java IDE all have in common? At some point in time these projects were either completely rewritten from the ground up or major parts of the project have been rebuild this way. Why? Simple: because in many cases the project slowly kept on growing and eventually ended up to grow so big that people fully lost track of the whole thing, often resulting in scenario's where certain parts were coded in such a way that it became seriously hard to build upon that; at the time of development they never figured that their work might be expanded on so heavily. Often leading to scenario's where a full rewrite would actually cost less time and effort than trying to fix all the nastiness that crept into the code over time.

Note that I'm not trying to claim that UML would have been the savior for all this, but I am saying that it could have been.

Although UML is often associated with those manager type diagrams it's actually much more than that. It's not just the diagrams which matter here: it's what they stand for and what those can do for you. At the very least UML can be a methodology to re-evaluate and go over your (software) project from a different perspective. So basically a means to try and help you think ahead about what... if.... What would happen if 250 people were using your software at the same time?

Unix mindset?

As you may know there is a philosophy behind Unix: do something small and be very good at it. Also make sure that others can use your efforts for their own purposes. This helps to build many small things which, when combined, can lead up to something much bigger.

A good example for this would be ls. By itself ls(1) can't sort your output. Yes, it can sort it on sizes but how about a reverse alphabetic list? Heck, once we have that list why not try to weed out any duplicates while we're at it? As said: ls won't be able to handle this on its own, but if you combine its output with sort(1) and uniq(1) you're really getting into the right direction.

To me UML is no different. 14 diagram types means that you also have 14 different ways to explain ("visualize") your project, allowing you to go as easy or as indepth as you want....

But what IS UML anyway?

Simply put: 13 different diagram types (the last one (Profile) is hardly used) where each diagram type can showcase a different section of your project. I usually divide the whole thing into 3 major parts (as shown above):
  • Structure: This shows the inner working and layout of your project. A Class diagram for example would show all your classes and their properties / methods as well as the relationship they share with other classes. A deployment diagram for example would show how your project manifests itself when installed.
  • Behavior: In short: what does your project do? A Use Case diagram for example is well known for its ease of use and the things it can explain (Use case diagrams, as their name implies, explain the main functionality of your project).
  • Interaction: This isn't merely about your user(s) interacting with your software, but also everything involved. If your software checks for updates and downloads them then this would be an interaction of its own: one with the update server.
So basically UML allows you to showcase different aspects of your project so that others can understand it's inner working without having to read through your code. And quite frankly I think that this is one of UML's best aspects. It is both a way to help you plan ahead and think about the structure of your project, but it's also an option to document your work. Even indirectly: if a diagram can help someone else understand how your project works, then they might be able to use that knowledge to write the actual manual for you.

ports_deploy.jpg

An UML deployment diagram showcasing my (brief!) impression of the PKGNG system.

Yes, I know I messed up there: it's pkg(8). That's what happens when you do this on a Friday evening (I made this diagram on the fly, my tool of choice makes those quite easy to set up). And now I'm too lazy to fix that ;)

Also a standard!

But other than 14 diagram types UML is also an open standard set out by the OMG ("Object Management Group"), it even has its own website. But yeah, there is a formal specification available for download if you're interested in UML's inner working. Seriously though: if this subject remotely intrigues you then I'd seriously recommend to download and skim through the formal standards PDF file(s). You might be surprised at the amount of detail those provide.

Not just for developers or managers!

Look... UML is a tool. Just like a hammer. And although you may associate a hammer with a carpenter who'd use that to hammer in nails a hammer's use is not limited to that aspect alone. We may set out a "rule" that hammers are on this world to hunt for nails, fact of the matter is that they can also be used to form iron ("smithy"), break Windows, break glass windows ( :D I so couldn't resist) and a whole lot more destructive things.

UML is not much different. It's a tool which can be used in many different ways. Heck, I once used a deployment diagram to showcase my network structure because at that time my modeling tool was the easiest option I had available.

In the end it is but merely a tool, and it's effects are entirely what you might make of it.

And if you are interested in all this... my advice: please don't let the means turn into some kind of goal of their own.

Anyway, thanks for reading so far. I'd now like to share a Youtube video shared by the OMG group in which one of the founders of UML (Grady Booch) reflects on the whole development:


Each to their own, but in my opinion these are interesting times. 20 years is quite an achievement if you ask me.
 
I'm a card-carrying member of the "Save the clouds" foundation. I was there, doing OO A&D and software engineering, when UML hit. It was a disaster then, and it remains a disaster now. Instead of giving people training and tools to help them think and design, we've given them a complicated and rigid drawing technique, which doesn't clarify design.

20 years of Grady Booch selling crappy software, and making a fortune by hyping snake oil. He sells the lie that you can take dumb and mediocre programmers or software engineers, and by just giving them a drawing tool and a training class they will become intelligent systems architects and software designers. He was a scam artist then, he remains a scam artist now. Until recently, I would bump into him regularly while eating lunch, and I always had to bite my tongue to not tell him what I really think.

How many of you remember trying to run Rational Rose in the early days? It was a machine for crashing Windows NT. Awfully bad software. Which is sort of symptomatic for Grady's software design method: Instead of using lots of elbow grease, and good solid analysis and design, you do a superficial high-level OO analysis, and then do the actual implementation sloppily. The amazing part is that it was extremely expensive: We spend $30K per person on Rational Rose for every member of our team (of about a dozen), and we were very proud that we had managed to negotiate a good discount. For a tool that didn't actually run, and that ended up not helping with design at all, that's a lot of money. That was about 97 or 98, so roughly 20 years ago.

By the way, I'm very much in favor of object-oriented software design, and of thinking before coding, and of good engineering methods, and of writing up designs and reviewing them, and so on. Just not of Grady's operation.
 
Instead of giving people training and tools to help them think and design, we've given them a complicated and rigid drawing technique, which doesn't clarify design.
Have to disagree on that point. As I mentioned above: UML is a tool, it's specs are fully open and freely accessible to anyone interested which includes freedom of usage (you don't have to cough up a contribution to OMG before you're allowed to use their design for example..).

20 years of Grady Booch selling crappy software, and making a fortune by hyping snake oil.
To be honest I didn't even know the guy until recent news but what you're describing seems to be a different kind of problem. I mean... OMG.org is the driving force behind UML and they don't sell any software there.

Not to mention that the software I got (VP) did as was promised. No snake oil there.

He sells the lie that you can take dumb and mediocre programmers or software engineers, and by just giving them a drawing tool and a training class they will become intelligent systems architects and software designers.
I guess you drank a different brand of coffee than I did. Where does this "selling" come into play for example?

I mean.. by your definition the Umbrello project couldn't have be a thing. I mean: here is freely available open source software based on standards "sold" by others. BlueJ anyone? ;)

Could you at least try to share some more substantial arguments instead of spouting a lot of personal disdain? ;) Not to mention the fact that nothing was sold here. A standard was released for anyone to use as they wanted.

How many of you remember trying to run Rational Rose in the early days? It was a machine for crashing Windows NT.
Wasn't that software designed and sold by IBM?

So let me get this straight... Booch (OMG) sets up a freely available standard for software design which is soon being picked up by several companies to monetize on. Including IBM with their Rational Rose. Yet when the software turns out to be an utter failure then the author of the standard, - not the actual programmer of the pos software - , is to blame?

uuuhmmm, right.

Makes perfect sense!

Next time I guess we should just blame Linus Torvalds for some of the crappy software being made available on Linux. When being asked about it I'll just refer back to this thread :D

(edit)

Ok, small disclaimer here.. I don't necessarily disagree when it comes to monetizing. It has always bothered me that in order to get involved "professionally" with OMG then all you have to do is become a member. Basically it's a massive "pay to play" kind of scenario. Obviously they're trying to sell their stuff here. Just take a look at all the seminars and other sillyness.

But that does not take away the fact that all the specs are shared free of charge. I know because I downloaded all if them and used those as reference material. Not as easy as an out-of-the-box tutorial (you should try the CMMN specs), but still doable. I bought myself a Safari UML book back in the day and it really helped me, never looked back, these days I only refer to the formal specs (BPMN, SysML, CMMN, etc.).

Fact of the matter is that they're not trying to sell you anything. There are other companies who see a market and try to dive into it. Just like there are plenty of enthusiasts who developed and provided software free of charge, including open source software. That doesn't quite add up to your remarks up there about only trying to sell stuff :p

"Don't shoot the messenger".
 
Let me date myself: I'm old, in software years. I learned "Jackson Structured Programming" in the late 1970s, as a way to write better COBOL programs (I was still in high school at the time). I guess it must have worked, because I made good money programming in COBOL while I was a college student. While my job title has never been "programmer", and my degree is actually not in the computer field, I've done a lot of coding over the decades. Beginning in the early 90s, I switched careers, to something that was being newly invented right then: software engineering, which is the idea that producing software is an engineering field (not conceptually all that different from making blueprints for buildings or wiring diagrams for electrical systems, known as civil and electrical engineering). Software engineering introduced the radical idea that being organized about programming and applying good engineering principles would help it be efficient and predictable. I still believe that to be true, while at the same time, a lot of craftsmanship and hacker ethic also has to go into the handiwork of creating code.

The history of UML is way more complicated than you describe it. OO programming really started to get popular in the very late 80s and early 90s (before that, it was a niche in academia). At that time, there were three "gurus", who tried to teach everyone how to do it: Grady Booch, Jim Rumbaugh, and Ivar Jacobson. Each of them had a "method" to sell, and they went around writing books (on those days, people still mostly learned programming by going to places like the "Computer Literacy Bookshop"), giving talks at conferences, and being hired by big companies to teach how to do software designs. Actually, each of those guys (and many others) sold their technique as a "methodology", which is a great-sounding word. Each of those methods had a name; Grady's was called the "Booch" method, and the others had names that all followed the pattern "OOxxx". Clearly, the various providers of methods and teaching were competing with each other, which led to the "method wars".

Before UML, the most popular one was the Booch method. Why do I talk about the "Save the cloud" foundation? In the Booch method, classes looked like clouds. One of the reasons I liked the Booch method was that it is simple: Classes are clouds, arrows show inheritance, there were relatively few special annotations or graphical convention. It was really designed to be used on whiteboards in meeting rooms, which is exactly how we used it. When UML happened, we were all very upset that we had to switch from simple-to-draw "clouds" to complex rectangular boxes with internal lines, and we wanted to save the clouds.

In the mid 90s, both the software industry (the consumer of the methods sold here) and the people who created and sold methods figured out that having many incompatible ways to do the same thing was bad for business. So the three main protagonists got together, and decided to "unify" things, and bury the hatchet. Matter-of-fact, they adopted the name "three amigos" for themselves. UML is in a nutshell the attempt to take all the expressive power of the major methods that existed before UML, and integrate it.

Because, unlike the Booch or OOxxx or OOyyy or ... method, UML could not be owned by one company, its standardization and definition was given to the OMG, which had already existing long before that, when it created the CORBA standard, and the IDL (data description language) used by CORBA. When did I use CORBA? Must have been around 92 or so, on Motorola VME boards with 68040 chips and physically shared memory (multiple CPU boards, one memory board, that's how you build a cluster in those days, SMPs and NUMA were hard to come by without spending millions).

Initially, Rational Rose (the software) was a product of Grady's company, called Rational, which had come out of the Ada market. A lot of what today we call "software engineering" came out of the military, and a lot of that was done in Ada in the 80s, and Rational sold development tools for Ada. Rational Rose started out life pretty much as just a drawing program, which was so slow it was unusable (yes, we ran Rose 1.0, and it was horrible). It quickly grew the capability of analyzing and generating source code, and was quickly converted from Booch notation to UML when that transition happened. I ran Rational Rose in about 97 or 98, and it ran fast enough, but was such crappy software that it kept blowing up, and taking the NT kernel down with it. Our company was a large enough customer that we got Grady to come give a few talks, and then had his staff teach training classes. One interesting factoid we heard from the instructor was that Rational had attempted to develop Rose themselves, resulting in the Rose 1.0 train wreck. Then then threw the wonderfully OO-designed source code away, bought a small company that had a competing product, and hired a team in Bangalore to do the development; that was the first time we heard of outsourcing software work to India (it seemed like a radical and risky idea back then). In those days, Rational was a pretty large company, which made really good money. In the market of computerized OO design code generation toolsets, Rose was the 400 pound gorilla, and undisputed market leader. The idea that you could get freeware OO design tools that implemented UML was laughable in the mid- to late 90s. At the same time, Rational branched out into other software and consulting tasks: In addition to telling you that you had to use UML and Rose for design and code generation, you had to use the Rational Process to organize software development, and their tools for metrics and SCM source control (people who have been forced to use ClearCase are probably having a seizure when I remind them).

IBM came in a decade later, long after all these events. By the time IBM bought Rational in the mid-2000s, I had long stopped using Rose and ClearCase, and was instead developing either with Eclipse, or just with a text editor and make files, and using RCS/CVS for source control. And I was making my class diagrams either with Visio, or by having meetings with other developers, photographing the white board and the end of the meeting, and checking the .jpg file into source control.

Today, UML-based design tools are available form many sources (some free). I don't even know whether Rational Rose is still for sale; haven't had the urge to buy a copy in over a decade. Sure, you can get the specs for free. I don't think you can learn how to develop good software efficiently by downloading the UML spec, and that's the understatement of the year.

My criticism of the UML itself is two fold. First, it has become extremely complicated. You really need a training class and months of experience to learn all the diagrams, all the various symbols and annotations. Just the different types of arrows are highly confusing. The kind of object diagrams I like have simple circles for entities (whether they are classes, objects, processes, nodes, ...) and lines or at best arrows for connections, and it is clear from context what the diagram refers to. Second, and this is where the snake oil salesman aspect comes from: When the great method wars happened, and when people like Grady and Jim and Ivar and their companies were making big money from this, they really did go around claiming that *their* methodology and toolset would improve software engineering productivity by huge margins, and lead to a nirvana of easy-to-develop, high-quality, bug-free software that would be delivered on schedule and under budget. This was the same time when there was a veritable explosion of software engineering and software development management textbooks. Remember "Code Complete", which sold millions of copies? I used to spend probably $1K per year on books in those days (there was a "Computer Literacy Bookstore" on the way home from work). Many of these books are actually pretty darn good (in particular Steve McConnell has written insightful and helpful stuff), but there is simply no silver bullet: engineering is hard, and software engineering is particularly hard, and managing software engineering is extremely hard. Unfortunately, a lot of their promises were outright lies, or self-delusion. At the same time there were lots of academic groups (primarily at CMU, but also at Stanford, where I had been an employee a little earlier) that were studying software engineering (not teaching how to do it, but researching how well it is done), and their conclusions about the inefficiency, brittleness and planning difficulty were disheartening.

The older I get, the more I believe that there are only two really good books about software engineering: The tar pit book ("The Mythical Man Month" by Fred Brooks), which shows how nasty a badly managed software project can go wrong, and whose lessons are still important, even though everything about software development has changed. To begin with, a software development group no longer needs a "librarian", whose job is to put the punched cards with source code into cabinets as a form of source control. I recommend the 50th anniversary edition of the book, which has some nice essays added to the end. Disclaimer: Because of where I worked, I've actually met a few people who lived through the events of the tar pit book and have the scars to prove it: writing the operating system for the IBM 360 was the defining moment for the crisis of software engineering and project management; it was like the "Tower of Babel" for the management of building construction.

The second book is there to demonstrate that software is written by humans, and that the most important thing about software development is to keep those humans productive: "Peopleware", by Tom de Marco. Again, technically that book is laughably out of date (look at the description of how to set up the phone system for a software development group to get a good laugh), but the underlying message is still correct: To get software written well, you need to hire good people, and you need to keep them wanting to work for you and stay happy. Everything else is secondary. If you have good, motivated and happy engineers, they can use the newest and fanciest languages (Go, Swift), or they can use cuneiform on clay tablets, and it will work pretty well. If you hire bozos, keep them in the dark, feed them manure (that's called the mushroom theory of management, except the word used for manure starts with "s"), you'll get the results you deserve: none. What method or drawing technology they use does not really make a big difference, in either case.

P.S. Today I went to lunch with an old colleague from the early 90s, at the corner of Lawrence Expressway and Arquez Avenue, in Silicon Valley. Today, it is a strip mall with many restaurants of interesting ethnic backgrounds, and a classic burger place (which caters to silicon valley nerds at lunch, and motorcycle riders in the evening). Right across the street was the first "Fry's Electronics" (I think today it's a sporting goods store). And exactly in the strip mall where we ate falafel and shawarma today was the original "Computer Literacy Bookstore". There were also many cheap computer parts places there, and several electronics surplus stores (only one of which remains, and it is in danger of closing if no new owner is found). The idea of buying a book to learn something seems quaint today.
 
ShelLuser and ralphbsz, thanks to both of you for this topic (I'd never heard of Grady Booch before, and I had the wrong idea about what UML was; I think I was getting it mixed up with Universal Configuration Language).

I remember spending many happy and hopeful hours browsing in Computer Literacy with my father Hugh, as a teenager in the 90s.

All of the wonderful computer books being written back then gave me a nice feeling; their high quality made deep technical know-how feel easily attainable; it was a real comfort to see rows and rows of them in there.
 
Let me date myself: I'm old, in software years. I learned "Jackson Structured Programming" in the late 1970s, as a way to write better COBOL programs (I was still in high school at the time).
Meh. Kids these days.
The older I get, the more I believe that there are only two really good books about software engineering: The tar pit book ("The Mythical Man Month" by Fred Brooks)..."Peopleware", by Tom de Marco
freebsd.png
 
ralphbsz now I remember ClearCase. Thank you. Please put me in the shade and fetch my meds, would you? Yes, the 40 year old cask strength will do. Man that was mean of you ;)

CC was one CF which was sponsored by the shrink union, if I am any judge. It would think the update complete when you pulled the second network cable from your machine. Or if the embedded target on the other end would crash or power down. That left you with a partial version which would not build or (worse) run. And RR got us to have directory with the class prototypes to import into RR, followed by generating the same class set again just to get management happy. Changing the import set was faster and easier than navigating this tool.

But when it comes to literature, I put Leo Brodies "thinking forth" in the reading list for new colleagues. Feedback was good.
 
We had a team of roughly 120 software engineers, when management decided that we had to use ClearCase. Because management wanted to have the best software process, so the most complex and expensive solution was desired: our management confused "good software process" with "expensive and inefficient software process", a common mistake. We hired 3 full time source control engineers, and bought a large multi-processor sun server with RAIDed disk arrays to run ClearCase on. It replaced a single Windows NT machine with a half dozen disk drives, which had done the job of source control perfectly well beforehand.

And then came week-long training classes: the old system (Microsoft "SourceSafe") one could learn in 10 minutes. The fact that ClearCase used a "file system" interface instead of checkin-checkout contributed to the insanity. Every network outage meant that we couldn't get to the source code, or couldn't build, or couldn't check in and out. Working from home became impossible (for the few of us who had portables powerful enough to edit source code or do a compile, in the last 90s that was not common yet). Most engineers ended up working from stolen (unofficial) copies of the source code, and when you had your changes all done, you would really quickly checkout-patch-checkin. It made the whole idea of a good software process into a mockery.

One of these days, when I have more time, I need to tell the story of bringing my laptop to a repair shop (about 97 or 98, when one still drove to repair shops), and the lady at the repair shop taking her clothes off. Right now I'm busy, so perhaps this evening.
 
I went to an interview at Pixar in Marin north of San Francisco. When I went back to the airport, in 1992, I helped Ed Catmull put a Pixar box on the shuttle. (How many here knew Pixar once made their own hardware?)

I used to eat lunch next to Jim Clark at Silicon Graphics when I was there as a new hire for a couple of weeks at a time. I overheard him talking about meeting some guy who wanted to start a company to make software for viewing documents on the internet. He looked at me and asked me what I thought. I had to tell him I didn't know what the internet was. (Who, here, can tell me who Jim had met with and what software they were talking about?)
 
I had to tell him I didn't know what the internet was.
In 92, that was a perfectly reasonable answer. The idea that all disparate networks that had existed earlier should all interconnect with each other was new, and not universally known. And "web" traffic had barely started. I think the first web page in the US was served only in late 91 (I can date that pretty accurately: I got hired at SLAC in November 91, and met Paul Kunz within a few days, and he was busy doing something wild and crazy with his NeXT cube that involved running some software he had gotten from CERN.
 
This thread has some really interesting history in it. Thanks :)

I am a big fan of UML class diagrams when writing OO code (i.e in both C and C++). However I find some of the other UML diagrams less useful. There is just too much complexity in software than I find can be expressed in some diagrams.

I use Dia. It is light weight and doesn't drag in *too* many dependencies. If you only need something simple, it is certainly worth a try.

However, sometimes I also find that just writing the C/C++ header files is pretty much stating the exact same information as a class diagram and is also immediately useful to the compiler.
When using diagram tools, I always find myself asking if I can just do this in plain-text... And I suppose the answer to that *is* just write the darn header files ;)
 
Back
Top