Archive
XML In UML
While learning XML, I concocted this UML class diagram of the conceptual structure of XML as a quick look refresher guide:
The diagram can be interpreted as:
- A typical XML document is composed of a “Document Element“, an optional “Prolog Element”, and many application specific “Element” classes.
- Besides a base “Element” class, there are two subclass types: the “Document Element” and the “Prolog Element”.
- In an XML file, the “Prolog Element” (if present) must precede the “Document Element”.
- An element contains content and, optionally, 1 or more “Attributes”.
- Each “Attribute” is comprised of a Name/Value pair.
- An element can also contain other nested elements, providing support for structured data representation.
Here’s a simple concrete example XML file and the mapping from concrete to abstract. Note that the “comment” and “xml declaration” lines aren’t represented in the abstract class diagram model. I left out that second order level of detail to keep the class diagram simple.
How’s Your GoF Swing?
I don’t think many software professionals would disagree with the assertion that one of the greatest and innovative software design books of all time is “Design Patterns” by the Gang of Four (GoF). According to these PGA GoFfers, one dimensional software developers who only cut code and are “above” documenting behavioral and structural views of their designs do everyone a great disservice, especially themselves. Here’s why:
An object-oriented program’s run-time structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A program’s run-time structure consists of rapidly changing networks of communicating objects. In fact, the two structures are largely independent. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa. With such disparity between a program’s run-time and compile-time structures, it’s clear that code won’t reveal everything about how a system will work. – Design Patterns, GoF.
Here’s the double whammy from UML co-creator Grady Booch.
The (source) code is the truth, but not the whole truth. – Grady Booch
I interpret these quotes to mean that without supporting “artifacts” (I use the less offensive “a” word here because “documentation” to most programmers is the equivalent of a four letter word.) to aid in understanding, maintenance developers and new team members and even the original coders are hosed. Of course, it goes without saying that their organizations and customers are hosed too. The hosing may be later than sooner, but the hosing will take place.
“The bitterness of poor system performance remains long after the sweetness of low prices and prompt delivery are forgotten.” – Jerry Lim
When one dimensional programmers are combined with one dimensional, schedule-is-the-only-thing-that-matters BMs who don’t care to know squat about software other than that the code is “done”, a toxic and self-reinforcing 2 X 1D brew of inefficiency and endless downstream rework is guaranteed. No superficial org restructurings, process improvement initiatives, excellence committees, or executive orders can solve deeply rooted quality problems like this. Bummer.
So what’s the advice that goes with this typical Bulldozer00 rant? Learn UML (on your own time; see the quote below) and develop your software from end-to-end with a process that interlaces coding and “artifacting” similar to PAYGO.
“I hold great hopes for UML, which seems to offer a way to build products that integrates hardware and software, and that is an intrinsic part of development from design to implementation. But UML will fail if management won’t pay for quite extensive training, or toss the approach when panic reigns.” – Jack Gannsle
My version of Jack’s quote replaces the “if” with “when”.
ImAnIdiot
A colleague recently sent me a cute little nerd-to-nerd poem:
A programmer started to cuss
Cos getting to sleep was a fuss
As he lay in his bed, going round in his head
was:
while (!asleep) sheep++;
Being a stage 3 type, I retorted with:
bool ImAnIdiot(true);
while(ImAnIdiot)
{
;
}
Unconstraining UML And SysML Modeling Tools
For informal, rapid, and iterative design modeling and intra-team communication, I use the freely downloadable and unconstraining UML and SysML stencil plugins for visio. These handy little stencils are available here: Visio UML and SysML stencils homepage. When installed and opened, the shapes window may look like the figure below. Of course, you can control which shapes sub-windows you’d like to display and use within a document via the file->shapes menu selection. Open all 11 of them if you’d like!
If you compare the contents of the two sets of shape stencils, since UML is a subset and extension of UML you’ll unsurprisingly find a lot of overlap in the smart symbol sets. Note that unlike the two UML stencils, the set of nine SysML stencils are “SysML Diagram” oriented. Because of this diagram-centric decomposition, I find myself using the SysML stencils more than the UML stencils.
To use the stencils, you just grab, drag, and drop symbols onto the canvas; tying them together with various connector symbols. Of course, each symbol is “smart”, so right-clicking on a shape triggers a context sensitive menu that gives you finer control over the attributes and display properties of the shape.
If you don’t want to open the stencils manually, you can create either a new SysML or UML document from the templates that are co-installed with the stencils (file->new->choose drawing type->SysML). In this case, either the 2 UML stencils, or all 9 SysML stencils are auto-opened when the first page of the new document is created and displayed. I often use the multi-page feature of visio to create a set of associated behavior and structure diagrams for the design that I’m working on, or to reverse-engineer a section of undecipherable code that I’m struggling to understand.
If you’re a visio user and you’re looking to learn UML and/or SysML, I think experimenting with these stencils is a much better learning alternative than using one of the big, formal, and more hand-cuffing tools like Artisan Studio or Sparx Enterprise Architect. You can “Bend it like Fowler” much more easily with the visio stencils approach and not get frustrated as often.
Reuse Based Estimation
“It’s called estimation, not exactimation” – Scott Ambler
One of the pragmatically simple, down to earth equations in Steve McConnell‘s terrific “Software Estimation” defines the schedule for a new software development project in terms of past performance as:
Of course, in order to use the equation to compute a guesstimate, as the table below shows, you must have tracked and recorded past efforts along with the calendar times it took to get those jobs completed.
Of course, not many orgs keep a running tab of past projects in an integrated, simple to use, easily accessible form like the above table, or do they? The info may actually be available someplace in the corpo data dungeon, but it’s likely fragmented, scattered, and buried within all kinds of different and incompatible financial forms and Microsoft project files. Why is this the case? Because it’s a management task and thus, no one’s responsible for doing it. In elegant corpo-speak, managers are responsible for “getting work done through others“. The catch phrase used to be “getting work done“, but to remove all ambiguity and increase clarity, the “through others” was cleverly or unconsciously tacked on.
How about you? How do you guesstimate effort and schedule?
Transfer Of Mental Ownership
I don’t know how to write code in the Erlang programming language, but ever since reading Bjarne Stroustrup‘s “The Design And Evolution Of C++“, I’ve been interested in the topic of programming language creation, development, and adoption. Sinisterly, I look for how much support, or lack thereof, that management provided to the language creators.
In this entertaining InfoQ video, “A Discussion Of Basic vs. Applied Research In The Software Domain And The Creation Of Erlang“, kindly and soft-spoken Bjarne Dacker recounts the development of Erlang. Here are some of my distorted notes:
Many problems that need to be solved by software are not computationally intensive, they’re symbolic.
The sequential and synchronous Von Neumann programming model does not map cleanly into the realm of real-time control systems.
The Erlang team asked: “Why are software academics obsessed with all these subtle, disparate, awkward, and complicated communication schemes like buffers, semaphores, mailboxes, rendezvous, regions, pipes? Why not just simply send messages between asynchronously running processes?”
Erlang designers took the goodies from Modula, Ada, and Chill and discarded the baddies.
By being devious and cunning, Dacker was able to subvert the corpo bureaucratic mandate that “everybody shall use the centralized IBM mainframe” and he miraculously secured approval to purchase a dedicated VAX (close to state of the art at the time) computing platform for his team.
Ericsson management wanted Erlang to be proprietary; a secret weapon that would allow them to develop their telecommunication products faster than their competitors. On the other hand, Ericsson management disallowed the usage of Erlang internally because it wasn’t an open standard (LOL!).
You can’t just throw new technology over the wall to product teams. You must create mixed teams; embedding applied researchers within product teams. You must facilitate the transfer of “mental ownership”.
In 2009, “something” happened. The number of Erlang downloads at Erlang.org started to skyrocket.
In keeping with my goal of providing a dorky graphic with each blog post, I present Mr. Dacker’s process for the successful transition of applied research knowledge into the marketplace.
Notice that going “backward” and cycling multiple times through the mistake prone experiment/evaluate activities (which most sequential, linear, forward-only management CGHs abhor and forbid) is an integral part of Dacker’s process. The mixing of researchers with product developers occurs in the production/exploitation stage.
The New Software Development Certification Fad
I like Alistair Cockburn‘s work, but I’m bummed. He, like fellow agilist Ken Schwaber, is on a certification kick. You know, like the phony belt colors in six sigma and the levels of “assessment” (<– psuedo-certification) in the CMMI and the “highly coveted” ISO-900X certification cartel.
InfoQ: Interview with Alistair Cockburn.
How well do you think certification/assessment systems have really worked to establish high quality products and services coming out of highly credentialed orgs and individuals? All it is to me is another way to extract snake oil money out of struggling orgs. You see, those few orgs that know how to develop high quality, value-added software products don’t need no stinkin’ certs. Those orgs that repeatedly screw up cuz of CCH mismanagement and misalignment need certs to give themselves a false sense of pride and to temporarily cloak their poor performance. However, when the money’s gone, the time’s gone, and the damn thang don’t work, the truth is revealed.
Greenspun’s Tough Love
In Founders At Work, Phil Greenspun recounts his tough-love approach toward molding his young programmers into well-rounded and multi-talented individuals:
For programmers, I had a vision—partly because I had been teaching programmers at MIT—that I didn’t like the way that programmer careers turned out. I wanted them to have a real professional résumé.
They would have to develop the skill of starting from the problem. They would invest some time in writing up their results. I was very careful about trying to encourage these people to have an independent professional reputation, so there’s code that had their name on it and that they took responsibility for, documentation that explained what problem they were trying to solve, what alternatives they considered, what the strengths and limitations of this particular implementation that they were releasing were, maybe a white paper on what lessons they learned from a project. I tried to get the programmers to write, which they didn’t want to do.
People don’t like to write. It’s hard. The people who were really good software engineers were usually great writers; they had tremendous ability to organize their thoughts and communicate. The people who were sort of average-quality programmers and had trouble thinking about the larger picture were the ones who couldn’t write.
So, did it work? Sadly, Phil follows up with:
In the end, the project was a failure because the industry trends moved away from that. People don’t want programmers to be professionals; they want programmers to be cheap. They want them to be using inefficient tools like C and Java. They just want to get them in India and pay as little as possible. But I think part of the hostility of industrial managers toward programmers comes from the fact that programmers never had been professionals.
Programmers have not been professionals because they haven’t really cared about quality. How many programmers have you asked, “Is this the right way to do things? Is this going to be good for the users?” They reply, “I don’t know and I don’t care. I get paid, I have my cubicle, and the air-conditioning is set at the right temperature. I’m happy as long as the paycheck comes in.”
FAW was published in 2008. Two years later, do you think attitudes have changed much? What’s your attitude?
Improving, Exploring, Ensuring, Promoting
In Michael C. Jackson‘s rich and engrossing “Systems Thinking: Creative Holism For Managers“, Mr. Jackson describes 10 holistic systems thinking approaches designed to solve complex social managerial problems. As the tables below illustrate, Mr. Jackson allocates the approaches to four classes depending on the main purpose of the approach. For example, he asserts that Stafford Beer‘s “Team Syntegrity” approach is employed primarily to ensure fairness during the process of solving a complex social systems problem.
I really like Jackson’s book because of its breadth, vocabulary, and the way he covers each of the 10 systems approaches from its philosophical roots, to theory, to methods. He also supplies a real application example for each approach. In the final part of the book, Jackson integrates all of the approaches into a supra-holistic (?) approach that advocates mixing and matching elements of each approach and tailoring the “Creative Holism” meta-methodology to the specific “mess” at hand.
The last book that I read twice in a row was the brilliant Quantum Enigma by Fred Kuttner and Bruce Rosenblum. I’m gonna do the same with this masterpiece.
Science, Philosophy, Systems Thinking
In Michael C. Jackson‘s rich and engrossing “Systems Thinking: Creative Holism For Managers“, Mr. Jackson describes 10 holistic systems thinking approaches designed to solve complex social managerial problems. As he progressed from the earlier, purely science based, hard-systems thinking approaches to the modern, soft-systems approaches that attempt to fuse science with philosophy, I composed the two pictures below to help clarify my understanding. As usual, I felt an internal urge to externally express my discombobulated thoughts on the topic; so here are the pics.
The main distinguishing difference that I see between the hard/soft models is the way that internal system “parts” are characterized. In the hard systems approaches, the system parts are conveniently assumed to have no self-purposes. This, as some people know from experience, is a horribly wrong assumption for systems composed of individual persons – social organizations.
Social org BOOGLs, SCOLs, and BUTTs are forever mired in the hard systems thinking mindset of yesteryear. Their simplistic solution for suppressing any externalization of self-purpose that is at odds with their own is to either consciously or unconsciously apply force to extinguish it. History has shown that this ubiquitously applied technique works – temporarily.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 