Diagrammatic Alternatives To Uml

No one, except possibly the ThreeAmigos, likes the UnifiedModelingLanguage. We use it because the tools are there to support it. But gee, it really sucks. In particular it sucks very badly with C++ and Perl/Python, because it doesn't map well onto the structures of those languages.

So this page is about alternatives. Are there any decent ones?

To misquote Winston Churchill: "UML is the worst possible notation ... except for all the others"

How about making your own? (See http://www.metacase.com)

Or, as I used to call them, ChickenFeetDiagram.

Making your own modeling language has its benefits: You can

discard of everything you don't need (make it agile),
make it fit better to your own requirements, and
raise the level of abstraction beyond coding concepts.

The tighter fit between modeling language and problem domain creates better possibilities for true code generation (high to low abstraction level), in the same way as a compiler generates assembler from higher level code. You would need a tool that allows defining your modeling language and that supports it but these are becoming more and more available (MetaCase?, Eclipse MEP GEF and I hear MS Whitehorse is supposed to go a similar direction (Domain-Specific Languages).

More details on this subject and how it can be done is explained at

http://www.dsmforum.org

I often use event trace diagrams to help get people's heads wrapped around component interactions. At a high level, the fact that the component is in Perl (or whatever) doesn't matter. Visio works adequately well for capturing the initial whiteboard effort. -- DaveSmith

I'm curious. What kinds of diagrams are valuable? I've realized that class relationship diagrams are useless. First, I can read that from the code. Second, it places all classes on an egalitarian footing, which isn't helpful when you have lots of classes with vastly different importance. Third, I'd think the system dynamics are more important to diagram than static relationships. However, I've used MessageSequenceCharts and I find them difficult to read as well because they seem too detailed and too cluttered for very complex interactions. But then, I've found most diagram schemas/VisualProgrammingLanguages to be far behind textual languages. How do you diagram reflection?

(This question is hopefully on-topic because I'm assuming the alternatives you're using will be better fit to expressing meaningful information.)

There's some interesting writing on valuable diagrams in InstanceDiagram and OakTreeDiagram. Personally, I would answer you with a sentiment the opposite of Woody Allen's - If it seems dirty, you're doing it wrong. You don't need to express the entire system, or a large chunk of it, though a single diagram. Draw diagrams showing important interactions. If a class appears in more than one interaction, don't write all of its signatures in - only the ones used for this interaction. If you think people can just read stuff like that from the code, great, but in my experience code, too, is cluttered with minutiae that the diagrams are there to avoid. Diagrams are only a window onto a more complete model, if you're using tools, or as much as will fit on a beer-soaked napkin if you're not. -- BrianEwins

Donald Firesmith's OML, which he and Brian Henderson-Sellers proposed as an alternative to UML, seemed much cleaner and more expressive. Peter Coad's notation is also nice, although even Coad has acknowledged (through TogetherJ (TogetherJtool), which can generate Coad diagrams, but defaults to UML) UML as a standard. -- JimRussell (who loves diagrams, but questions the value of existing notations.)

[UML] really sucks. In particular it sucks very badly with C++ and Perl/Python, because it doesn't map well onto the structures of those languages.

Oh? A common criticism of UML is that it sucks along a different dimension: too much UML (class diagrams especially) is C++ with lines drawn round it. For example:

the black/white diamonds. Well nobody really seems to know what they're for, but there are explanations that seem to be talking about object valued member data and references in the C++ style
the strong (and very unhelpful) distinction between feature names with "argument lists" (->member functions) and feature names without (->member data)

Which UML features map poorly into C++? To Perl? To Python? Which map well into what other languages?

Personally I use UML for high level modeling. I am careful to avoid situations where that question is meaningful. My general approach is to translate the UML into XML (using my own schema, not XMI), and then to go through a number of stages of code generation (each step can generate different XML) until I reach a point where I can to a simple syntax switch into C/Perl/Verilog/C++/whatever. I even have the system bootstrapped: my code generators generate themselves (almost)!

For the solid vs outline diamond, I have developed my own definition (which seems compatible with the accepted ones: the diamond is used to define context, which is very useful when attempting to generate code that prints error messages. I follow outline diamonds to the container to get the context information: the container provides identity to the containee. The solid diamond is the opposite: the containee provides identity to the container.

Unfortunately UML doesn't handle the concept of identity very well. I have to use stereotypes for indentifying attributes; and tagged values for relationship formalization. My approach is to use UML where it works, and to use its extension capabilities when it doesn't. The advantage of UML is that, for the things it does well, it provides a standard notation. And, given that it works, that is far more important than technical merit.

p.s. refactor this: it doesn't really belong on this page.

-- DaveWhipp.

The most powerful diagramming notation I've ever used/seen is the Behavior Diagram notation in AscentLogic?'s RDD-100 CASE tool

http://www.alc.com

It's like a combination of a UML activity diagram, a state transition diagram, and a dataflow diagram, all in one notation.

-- RandyStafford

DataFlowDiagrams have a simple and powerful notation: You can diagram any process at all; it doesn't have to have anything to do with computers. They're easy to understand, can represent process and data to any level of detail (high or low) that you want, and can be very precise. -- JeffGrigg

Personally, I like class diagrams. But I find that UML lacks a "static" diagram (like class diagrams) that shows the level of detail of StructureCharts? (functional modules calling other modules). So, I've been using a variation of Booch, with method boxes nested within or crossing the boundaries of class boxes; and I show calls between methods with arrows between their boxes. It's a StructureChart? for methods within classes. It helps me; I've found it very useful. -- JeffGrigg

I also make custom diagrams whenever I feel the need:

I drew warehouse "buildings" with rooms for the major departments, and repair "trucks" on the outside -- so I could color code them as to how inventory was tracked in each location.

I did a combination of StateTransitionDiagram and DataFlowDiagram to illustrate how messages flowed between programs and systems in a distributed database. It proved extremely useful. -- JeffGrigg

See also the Journal of Conceptual Modeling, at: http://www.inconcept.com/JCM/

Just use scruffy looking circles with messy lines between them. People will get the idea and you can toss them later. The circles can be classes, objects, whatever.

I actually use this method quit a lot, and have no trouble with it. Besides, I usually end up changing the objects structure in my code several times, so the original diagrams are out of date any way. I use diagrams to sketch out my thoughts, not to document. -- BlakeMason

[It even has a name - the GalacticModelingLanguage (Galactic=slightly less than universal). Ascii in email can convey quite a bit also ie

  input--(process1)-->[state or server1]--(process2)-->[state or server2]-->...-->output

with text around it to elaborate. There can be more than one flow per email. Faster and less elaborate than UmlAsciiArt. Works well with off-site contractors that don't like attachments and who also store their WAN network diagrams as ascii.]

What do you all consider the main premise of UML or indeed any diagrammatical illustration.

Is it not to convey information? And for that to be truly powerful as many people as possible must understand the authors intent.

Regardless of personal preference UML is truly powerful because it stems the tide of competing illustration techniques and limits it to a manageable one. If I draw a state-chart diagram my counterpart in NZ understands my intent.

Instead of focusing on alternatives why not focus on improvements?

What has failed are attempts to include every detail in diagrams. Diagrams are often useful for higher-level viewpoints of a system or a particular aspect of it. When they start competing with code as a repository of details is when they get messy. Also, different diagrams may be needed for different aspects or audiences. There is no one right diagram.

U.M.L. activity diagrams seems to me as "reinventing the wheel" for standard flowcharts. I get confused when using diamons for both conditional and connectors. When I have a diamond for both cases, I split it in 2 diamonds, one for outcoming arrows (decision), another for incoming arrows (connector). I usually fill the diamond replacement for connectors, with gray or black.

Something similar goes for subactivities. In flowcharts calling a subprocess / subactivity, you have a (rounded?) rectangle, and add vertical lines, close to the left & right borders. In activity diagramas, you have to write a inversed fork close to a corner.

(UMLCat)

The Problem with UML seems to be (as I perceive it) that it is a BondageAndDisciplineLanguage that forces you to adjust your thoughts to match the standard. A really great Modeling Language would allow you to express your thoughts about the Software directly without transforming and restricting them by an arbitrary set of notation-elements.

@DaveWhipp: I would really like to see a demonstration of your approach. What is the effort of changes to requirements or basic design?

@All: I often have the problem that I forget details and thus traps of complex software - let's say after 6 months or so not looking at the code. For years I am searching a good documentation system. If I write everything down I will obtain a text which is much more complex than the code itself. I document my code, that helps, but often I need too long to get back to the little tricks hidden in the code. So, alternative: models. The problem with common notations, including UML, is that the stuff is really good for high level design. In other words: I have got lots of diagrams which illustrate mainly those aspects of my code I can remember easily without them. But it is quite complicated to model all the details. A model that tries to enter all these little traps and tricks will be much more difficult to understand than the code or even textual documentation. So what is the solution? A design pattern language perhaps?

---Tobs