I am wondering about a workshop for PUG Challenge Americas on using UML for ABL. This workshop, given by me or someone else, would be a hands on exploration of the different diagram types which are most useful in specifying and ABL system, either to simply specify work which is to be done or possibly to actually generate the working code for the system. The goal would be to give participants enough of a clue about the important diagrams in UML that they can open the box and start to work rather than feeling like they have no idea what is relevant, as is often the case with new users. Obviously, it can't be a complete tutorial in 3 hours, but I think we can cover a fair amount of ground.
What I am looking for is expressions of interest, either on list or off, for people who might be willing to pay $150 for such a workshop so I can tell whether it is worth proposing or not.
Thomas Mercer-Hursh, Ph.D.
Thomas@cintegrity.com
Wistful for the old face to face Exchange?
Come join us for PUG Challenge Americas, 5-8 June 2011
http://pugchallenge.org/
Registration is now open!
Call for Speakers is now open
Interesting... I have actually heard a lot over the last couple years about the waning usefulness of UML in general, but I guess that is another topic to be had.
Nothing waning about UML. It is going stronger than it ever has. Yes, there are certain movements which try to code first and design second, but I don't see that one needs to be taken in by that.
There are many different ways to use UML. Some people just use it as a common symbol library from which to make sketches to communicate design ideas. Others work out the designs in some detail. And some generate the code directly from the UML. That is quite a spectrum of usage patterns. Even the most aggressive agile team can use it the first way to benefit. Myself, I think it reaches it highest benefit when one actually generates the code from it, thus avoiding handwriting all of the code. Isn't that the direction which motivates 4GLs?
Totally agree about the spectrum of uses. I myself do find it useful as a "universal language" for quickly sketching a diagram to show another developer. I haven't done that in awhile, though, since noone at my current employer uses OO besides moi.
I should have qualified the use case that I always think of when I hear UML, which is the "write the code, then (hand) write the UML diagram for the code" that I had experienced and would care to forget (which is my own bias). It results in the same logic being stored in two separate places, which both have to be maintained and kept in sync. Of course, that isn't how UML has to be (ab)used, and probably isn't for the most part today.
In any case, good luck with your speech.
That is certainly the worst use case one can imagine. The one reason to consider post-hoc creation of the UML diagram is for analysis or modernixation, i.e., you weren't smart enough to start with the UML, but now have figured out that, at the least, it can help you to understand your existing system and, at best, it can serve as the foundation for transforming the system into something it is not. But, hand-write is extremely painful at best and, as you say, prone to error if there are two separately maintained systems. A number of 3GL languages have reverse engineering tools which will build UML diagrams for you from the code. Of course, at best, it is going to simply describe the as built system. It is never going to contain the use cases, requirements definitions. traceability, and the reasons why choices were made because those are simply not in the code. In ABL we don't have a full reverse engineering tool, but we do have ABL2UML ( http://www.oehive.org/ABL2UML ) which will build a component diagram of both the code structures and the data structures and show you how they are all connected. It is close to fully automated and one can easily regenerate the model after code changes.
For this workshop, I was thinking more about the OOA/D process rather than reverse engineering, i.e., how to go from concept to model to code using UML to produce predictable results.