Wiki pages might often benefit from illustrating a design using
. Unfortunately, it's hard to include graphical diagrams
in Wiki: you can make a GIF and embed a link to it, but the next person
can't easily edit it, so you lose some of the WikiNature
Check out jave.de. He has some diagram clipart that could be used for UML. We need to come to an agreement on standards though.
is software with an ASCII UML class diagram interpreter.
Wiki best supports ASCII text. Therefore, a good UmlAsciiArt
be useful. Especially if the diagrams are already vector, for example SVG.
Unfortunately, all ASCII art is compromise, and this goes especially
. This page is offered as a place for considering possible
conventions. Hopefully we'll come to a consensus and document it here, even
if the consensus is just "don't bother".
Unfortunately, the TabMunging problem has not been solved.
Limiting ourselves initially to class diagrams, the biggest problem is the
arrowheads. Trying to represent the official glyphs is unworkable (show me a
good upwards-pointing inheritance arrow!). So instead, we must choose our
own arrowheads. Here's one possibility:
Association: ^ Aggregation: O Composition: @ Inheritance: #
| | | |
<-+-> O-+-O @-+-@ #-+-#
| | | |
V O @ #
As an experiment, here's the DesignPatterns CompositePattern
in the above form of UmlAsciiArt
+--------+ +---------------------+ *
| Client |------>| Component |<-----------------------------+
+--------+ +---------------------+ |
| Operation() | |
| Add(Component) | |
| Remove(Component) | |
| GetChild(int) | |
| | |
+------+------+ +----------+----------+ children |
| Leaf | | Composite |O-----------+
| Operation() | | Operation() |
+-------------+ | Add(Component) |
| Remove(Component) |
| GetChild(int) |
It's a pity that something as important as inheritance gets such a
lousy arrowhead. Improvements encouraged! -- DavidPrice
"show me a good upwards-pointing inheritance arrow"...
Rather nice. But it doesn't work in the other directions. On the
other hand, my inheritance arrows almost always point upwards.
Maybe we should adopt this?
Or are there Unicode glyphs that we can use?
Why not the following?
Then it no longer fits the topic of the title (ASCII Art).
Could we also differentiate between "extension" and "realization" ("implements") inheritance? It would also be nice if it fits into AbbreviatedUmlAscii (below) easily. Perhaps # and % or some similar pairing?
| Base | | Interface |
/_\ /_\ _
| : (_) OtherInterface
| : |
| : |
| Derived | | Implementation |
This makes me think that an Emacs interface to Wiki would be nice, so that you could use things like picture-mode. Wiki's formatting is simple enough that you don't really need Netscape to get around. But I suppose copy-and-paste is ok. -- LukeGorrie
A good UML drawing tool is needed first. There might be hope with DIA.
Why not a white-board that you (and everyone) can scribble on?
is working on such an animal now I believe.
What it really means is extending Wiki to allow drawings. Give me a piece of chalk and an eraser - make it impossible to make the lines straight or to spend any time making it pretty. Maybe it should allow me to type text instead of having to hand-draw every letter, but that's about as fancy as it should get.
Take a look at jave.de (http://www.jave.de/
) ASCII JAVA very cool.
Those restrictions would cause a drawing tool to harmonize with WikiNature
If we were using COM, you could just embed a drawing straight into the page...
It's fun having a COM booster around. How are you going to make it work when I use the Wiki pages from my Linux box? I lean towards applets as maybe sorta kinda having a better chance of working on more browsers. The only problem is that applets are so... well... applety.
An applet a day keeps the browser away.
COM has been ported to Linux, Solaris, DEC Unix.
Oh, I read wiki from my Palm. Is there a COM port for Palm? I know you can get Java on your Palm - I've written programs for it.
COM is ported, but is ActiveX/OLE? Don't embedding interfaces rely on
definitions from the Win32 API?
Ie: embedding is implemented by passing an HWND (window handle) to the embedded component.
Also, the problem with using Automation (on any platform) to launch a diagramming tool is that there are no standardized interfaces for displaying diagrams, so wiki users would be tied in to one diagramming application.
produces SVG UML diagrams. Check it out!
XML would certainly facilitate the other efforts to get WIKI into a docbook.dtd format. There are native XML browsers. X-Smiles for example.
Ideally, Wiki would use XML as its markup, and allow SVG to be embedded with wiki pages, and browsers would recognize the SVG namespace and render it appropriately. However, I think we may have to wait a few years before browsers that can handle XML in this way are in common use.
Yes, a VisualWiki would be nice.
I also like the suggestion I've seen recommended for handwritten italics: Enclose the italicized text in slashes. For example ...
| /AbstractClass/ |
| ConcreteMethod () |
| /AbstractMethod ()/ |
You can use Wiki markup in preformatted text:
| AbstractClass |
| ConcreteMethod () |
| AbstractMethod () |
How about underlining to indicate class-scope features?
Oh, you want to _underline_?
Plain text type setting conventions use _underscores_ to signify italics, not underlines.
We can use the alternative UML notation for statics, $.
I've added some UmlAsciiArtExamples
. This is Wiki: please improve them if you can. -- DavidPrice
My two cents: Someone out there should create a UML font (I do not have a good font editor) and then have wiki change uml:inherit_up to that font and make the font publicly available (this enables anyone then with a font-selectable notepad to create UML diagrams. This could include such characters as uml:inherit_down uml:vert_bar, uml:horz_bar, uml:compose_up, uml:compose_down, uml:thin_whitespace, uml:med_whitespace, uml:wide_whitespace, .... Where the whitespace characters are used to clean up the alignment.
for a connected graph editor for emacs, also does some UML drawing. -- ShaeErisson
for a very simple ASCII UML wiki tool how do you run it? does not seem to say
There should be an AbbreviatedUmlAscii
format that allows "diagrams" to be made, sent discussed more easily
Where "*ij(sym)" denotes lines/arrow between classes ie ">" for association, "#" for inheritance, "@" for composition etc as above. The class with no (sym) means start of line, the one with (sym) means end of line/arrow. Just a very simple tree even leave out types and parameters in the [attrib...method] list but enough to give the essence of the diagram in ascii, but more than just a plain tree. This is for the ClassDiagram
perhaps a similar convention would work for UseCases
that should be enough to communicate uml with ascii quickly over a wiki, for instance. No need for other "tools" to generate from it just interpret it as is.
See also AsciiArtGuiShorthand
which I discovered after writing this but still looks too verbose to me and is specific to GUIs.
I chose Actors as the leaves because if UseCase
s are the leaves, relations between them have to be repeated. Actors might have to be repeated this way but that is easier than the relations.
It does not look
like the diagrams much but captures the essence without a lot of decorations, tab/space gymnastics, and extraneous characters, the SimplestThingThatCouldPossiblyWork
It would be interesting to have a utility that would read in such and automatically generate box diagrams from it (ASCII or vectors). If all the boxes are the same size, I have found some possibly fairly simple algorithms, but not if they are different sizes. Otherwise, one could use a grid more or less as the underlying placement model. Maybe if they were quantized such that a box takes up one unit, two units, etc. to simplify things. I was kicking around the idea of using a GeneticAlgorithm to place the boxes to avoid long tangly link lines. It is sort of a TravelingSalesman? kind of problem.
Perhaps something like that used in EveryLanguageFixesSomethingDotSource
Such diagrams are too subject to TabMunging
. Thus, perhaps some kind of "relationship language" needs to be built that is processed and turned into Ascii Art.
How about just using YamlAintMarkupLanguage?
The dot tool from GraphViz
does that. Maybe someone can write a backend to ascii art from it...
) glued to Grappa (http://www.research.att.com/~john/Grappa/
) would create class diagrams as images, based on textual declarations. UMLGraph generates GraphViz
output, and Grappa renders GraphViz
input. These are Java libraries.
Support for UMLGraph's sequence diagrams might take a bit more effort though, as they use pic macros.
Another variation might be PowerPointUml?
. A lot of tutorials I've found seem to have diagrams drawn in PowerPoint
has loads of them). Is PowerPoint
the most popular diagramming tool?
is a pretty basic but decent web based tool for doing this, only basic features but does most things for simple class/flow diagrams.
To convert from ascii art to a png, etc I've used ditaa, an awesome little tool.