Why use a text-based diagramming tool? To some it sounds crazy. Even the developers I work with laughed it off as just the latest wild idea from someone who (in their minds) is overzealous about working at the command prompt. I transitioned a while ago from being a typical Microsoft programmer to more of a Linux / command-line sort of guy. My colleagues expect me to be at the command prompt for coding, doing server maintenance or managing source control. But creating UML diagrams from the keyboard? That seems a little nutty to them.
Why I built PlantText
I began working with PlantUML a few months ago, using all of the freely available tools out there, primarily the PlantUML QT editor. I was hooked right away. After investing a little time getting up to speed on the handful of keywords needed, all of a sudden I could quickly and easily create UML diagrams from text. Text is a powerful thing. Using text-based diagrams means they can be versioned in our version control system. We can run diffs on them to see what’s changed over time. It also solves the problem of developers creating pretty diagrams with little meaning.
PlantUML makes it easy to generate standard UML diagrams. Just like anything run from the terminal, it’s the only way to truly document work that you’ve done in a way that’s completely maintainable and reproducible. I can send a snippet of PlantUML to a colleague and know that when he drops it into the viewer of his choice, he will see exactly the same diagram that I’m looking at. Game changer!
Focus on the idea, not on the picture
Don’t get me wrong. I’ve used just about all of the graphically-based diagramming tools out there. Some of them I like a lot. Creately is one of my favorites. But what I noticed when I started working with PlantUML is that my thought process remained focused on the complex idea I was trying to model, instead of getting sucked into thinking about where to put the next rectangle and how big it should be. Using those graphically-based diagramming tools, you spend a lot more time than you realize dragging boxes around, coloring, and drawing connectors between them. It can hijack your thought process. And god forbid you have to change something; next thing you know you’re dragging 101 different connectors to new spots.
PlantText lets me stay elbows-deep in my class diagrams
For me, working with PlantUML is a better alternative. I simply don’t like learning proprietary tools that have their own menus and widgets and GUIs and do things in specialized ways specific to their own pieces of software. And those GUI based tools are prone to change arbitrarily from one release to the next. I want to write text, have diagrams generated for me, and know that I will get exactly the same diagrams returned to me each time.
PlantText offers something new
I was so drawn in by the power of PlantUML that I decided to build my own editor to fill in some of the gaps in the other available tools. There were several things I wanted from this new PlantUML editor.
- I didn’t want a desktop application; it had to be web-based.
- It also needed to accommodate really large diagrams.
- I also wanted the editor to be loaded with features.
PlantText supports VI Editor and Emacs bindings, it supports theming, and it handles tabs and other special character keystrokes very well. It uses the Ace Editor, a free, incredibly sophisticated HTML editor, as its foundation.
What’s next
Down the road I see the potential of adding some extremely powerful features to PlantText. Converting PlantUML to code in both directions is next on my list, so that code stubs can be generated from PlantText class diagrams. And, conversely, PlantUML diagrams could be generated from code. With that feature in place it opens the door to integrating with continuous integrations software, so that updated UML diagrams could be generated from your build server.
PlantText isn’t for everyone. It’s an expert’s design tool. It’s meant for people who see value in investing a small amount of time up front to reap greater rewards over the long haul.