Why use a text based diagramming tool? To some it sounds crazy. Even some of the developers I work with laughed it off as just the latest wild idea from someone who transitioned from being a typical Microsoft programmer to more of a Linux / command-line sort of guy. They expect me to be at the command prompt for while coding, doing server maintenance or managing source control. But for creating UML diagrams?
I began working with PlantUML a few months ago. I started off using all of the freely available tools out there, primarily the really nice PlantUML QT editor. I was hooked right away. After a small investment of time getting up to speed on the handful of keywords needed, all of a sudden I could 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 diagramthat I’m looking at.
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. Using PlantUML allows me to 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 that change arbitrarily from one release to the next. I want to write text, have diagrams generated for me, and know that I can use the QT Editor or the .Net editor or PlantText, and get exactly the same diagrams returned to me.
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. I didn’t want a desktop application; it had to be web-based. It also needed to accommodate really large diagrams. I wanted something integrated with Google Apps, because I use Google Apps personally and professionally. 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.
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 that see the value in investing a small amount of time up front to reap greater rewards over the long haul.