Martin@ TabletUML.com
The Unified Modeling Language (UML) is a standard graphical language for expressing software requirements (functions and business rules), architecture (high level components), and design (detailed structure and behavior). UML is powerful and flexible; but it can also be difficult to learn and to practice, so it is not used as effectively nor as commonly as it could be. One barrier to learning and to practicing UML is the state of current UML tools: difficult to learn, complex to use, frequently interfering with the practical use of UML, and costly. Tablet UML is a development tool aiming to provide powerful UML modeling with a simple user interface: simply drawing the diagrams by hand on a Tablet PC. Tablet UML will comprehend the symbols drawn on each diagram and construct a meaningful model from the drawings. Thus, Tablet UML will combine the ease of use of paper-and-pencil diagrams with the flexibility of an electronic modeling tool.
I’m a big fan of UML, and I like to show ways that analysts, architects, and developers in the trenches can use the Unified Modeling Language to solve real, everyday problems. When I teach UML, I have time to explore it in depth; but in my conference talks, there’s very little time to explore the nuances of UML. I have a very brief time to both introduce UML and demonstrate its practical use. So assuming my audience understands the basics of OO, I like to start with this overview, which is just enough UML to understand the diagrams I’ll demonstrate. (In my experience, it’s easy to read a well-drawn UML diagram. The trick is in the “well-drawing”...) There’s a lot more to UML; but this is enough to follow most of my demonstrations.
To understand UML, I think it’s best to start at the end and work backwards:
Within a use case is a lot more detail. In Writing Effective Use Cases, Cockburn describes a very wide range of topics to consider and document as part of understanding a use case, including the various scenarios that describe how the use case can be performed. And one useful way to capture these scenarios is in Activity Diagrams (such as this diagram for the Make Reservation use case).
An Activity Diagram is what I like to call “The Revenge of the Flowchart”: a simplified depiction of rules or an algorithm, including the steps (activities) performed and the choices made (branches). Activity Diagrams can be useful for scopes ranging from high-level business rules down to low-level coding techniques. Any given activity may have further detail inside it, shown in a more detailed Activity Diagram.
Once you know the activities your system must perform, you need components (units of executable code) to carry them out. Along with interfaces (the rules and mechanisms for communicating between components), components form the modular architecture of your system, depicted in Component Diagrams.
A Component Diagram shows how components (the rectangles with the rectangular attachments) provide interfaces (the circles). Providing an interface is shown by a line from a component to the interface. Component Diagrams also show components using interfaces (depicted via dashed arrows).
Within a component, you’ll likely find classes (categories of objects or information within the system). These classes can be related to other classes; and these relations can be depicted in Class Diagrams.
This is a very simple example of a Class Diagram (suitable for The World’s Shortest UML Overview); but the Class Diagram notation is much richer than this. With UML, we can show: attributes (properties or descriptions) and operations (behaviors) of classes; inheritance (subcategories); and a wide range of other details.
Your components must ultimately run on specific hardware; and the relationships between those hardware devices are shown in Deployment Diagrams.
The default icon for a node (a device) in a Deployment Diagram is a cube, as shown here.
There’s much more to UML. These diagrams are just examples of how UML can help you think about your problem and its solution.
As powerful as UML is, there are many reasons why it’s not used as commonly as it could be. We’ll explore some of these reasons below.
UML is huge. Really, really huge. That can be daunting, and can give people pause. And that’s a shame, because you don’t need very much UML at all to be productive in UML. That’s why, when I teach UML, I focus on basic UML as a communications tool. I get my students communicating in UML right away. Once students can communicate with UML fundamentals, then they can master UML with practice, and learn more esoteric features only as the need arises.
But practice is essential. I find that students who don’t apply their UML knowledge on projects shortly after class will forget how to communicate with UML. And the other UML problems make it more difficult to practice UML.
There’s a large number of UML tools available. The capabilities range from basic diagramming to powerful code generation and maintenance facilities. The larger and more powerful of these tools are a joy to use – if you know both UML and the tool well.
But that power comes with a very large cost in terms of complexity and concomitant learning curve. Even simple drawing tools like Visio® require a lot of thought about the tool, not just thought about the UML. Trying to learn a tool in order to learn and practice UML is too large of a burden for many to bear.
Even after you master the learning curve of a UML “power tool”, the day-to-day use can be just too complex. Mechanical tasks don’t move as fast as our thoughts do. Only very fast typists can type faster than they can speak. And analogously, not even fast toolsmiths can manipulate a traditional UML tool as fast as they can think. The UML tools, though useful, still present a “speed bump” between thought and expression. And in many phases of the development process, speed and ease of communication are far more important than “power tool” features.
That “speed bump” presents a real cognitive barrier; and even the “power tool” features can just get in the way when all you want to do is express an idea. The mechanics of the tool are not the mechanics of your thoughts. Your time and attention are disconnected from the problem and focused on the tool.
And the disconnect is even worse than that. UML is a very powerful language, not just for software design, but also for requirements gathering and analysis and for user feedback. Yet the typical UML tool is clearly aimed at programmers. It has all the power a programmer might demand, but not the simplicity an analyst or a customer representative – or even a customer – might need. And even programmers often need simplicity more than they need power.
The price of the best UML tools can also be a significant barrier to adoption and use of the tools, and thus a barrier to adoption of UML itself. The single-user price can be more than the price of a fully equipped developer’s computer, complete with code editor, compiler, debugger, and other common developer tools. Now I think a case can be made that with all the power these tools have, they’re worth every penny of the price; but for many corporate budgets, that perspective is irrelevant. After all, a 747 is also worth every penny of its price, but most companies aren’t buying their own jumbo jets. If you want widespread use of a language like UML, the tools have to be ubiquitous. That means they have to be inexpensive.
Then there are those who will argue that they have the perfect UML tool for resolving all of these problems: paper-and-pencil. It’s easy to learn; it’s easy to use; it works at the speed that you work; it’s available to everyone on the team; and it’s inexpensive.
But paper-and-pencil does not scale well. It fails what I call The Model Rule:
To use UML effectively, you should never be simply drawing pretty pictures; you should always be editing an underlying model, using the pretty pictures as your user interface.
Thus, the model should contain more information than is displayed in any one diagram; and information in one diagram should not explicitly contradict information in another diagram. (Information that is found in one diagram but not in another should not be considered a contradiction. Rather, this simply indicates that the former diagram displays more detail than the latter.) Details may be omitted from a given diagram to make it more comprehensible.
But how do you keep these diagrams consistent with each other? How do you maintain the underlying model? This is where a good modeling tool proves its worth, and where paper-and-pencil falls short: a good modeling tool will maintain the model as you create and edit your diagrams. If you’re not using some sort of modeling tool, this very mechanical burden will fall on you, rather than on the machine. That’s a poor division of labor: brains should do brain work and machines should do mechanical work. If you do the mechanical work, you will do it imprecisely and inefficiently, and you’ll have no time for brain work.
What we need, then, is a blend of the simplicity, ease of use, and shallow learning curve of paper and pencil and the power and flexibility of electronic document management. That pretty much sums up the strengths of the new Tablet PC platform: fully functional Windows XP computers with integrated pen-based digitizers to allow handwriting input and hand-drawn diagrams. These machines – manufactured by Toshiba, Compaq, Gateway, Acer, ViewSonic, Motion Computing, and others – are the latest evolution in portable computers. The Tablet PC API software allows natural pen-based input both on Tablet PCs and on standard computers equipped with digitizing tablets. A well-designed Tablet PC application works naturally, allowing a user to simply write and draw to control the application.
And that is the vision for Tablet UML, shown here in a series of screen shots:
After so much introduction, I feel like I should write at length to explain what Tablet UML is; but I can’t. It’s too simple. That’s the point: you draw UML diagrams in the pane on the right; and Tablet UML interprets what you draw, cleans up the picture, creates a model from it, and displays that model hierarchically in the tree on the left. With a familiar, comfortable Windows® Explorer-style interface and the simplicity of drawing, Tablet UML really is the UML tool you don’t have to learn.
Tablet UML is a Unified Modeling Language tool for Tablet PCs (and other computers running Windows XP Tablet PC Edition®). It lets you build UML models with a simple “Smart Cocktail Napkin” user interface: you draw, and it understands.
But Tablet UML is not just a drawing tool. It’s a full-fledged modeling tool: you create diagrams as a way to create rich UML models, and then view the details of those models through more diagrams and reports. Beyond the diagrams, Tablet UML maintains a model tree, containing all of your recognized model elements so that they can be reused in other diagrams. You can also:
Tablet UML is ideal for Agile Modeling, Agile Development, and eXtreme Programming, where the development process depends on rapid, easy communication with low overhead. The “Smart Cocktail Napkin” user interface means that you’ll spend very little time learning Tablet UML and very little time struggling with the tool. The goal is simplicity: the UML tool you don’t have to learn. That will leave you more time and more freedom to solve your development problems.
And there's a lot more to Tablet UML:
“Five Step UML Tutorial”: A simple introduction to requirements gathering, design, and analysis with the Unified Modeling Language.
In its early form, Tablet UML is already generating excitement and interest among experienced UML modelers. It needs neither introduction nor explanation: I launch the application, their eyes light up in an “Aha!” reaction, and they start drawing diagrams and nodding as Tablet UML understands what they draw. It’s just that simple. And that means it will be simple for new UML modelers as well, and for students. At an affordable price, it should be very popular with early adopters. As Tablet PC use grows,[1] Tablet UML can become a very popular UML solution with a respectable slice of the market.
To learn more about Tablet UML and to sign up for Tablet UML News (a newsletter on Tablet UML developments), please visit http://www.TabletUML.com.
[1] CDW sold 835 Toshiba Portégé Tablet PCs just in the month of March, 2003, satisfying a backlog that had accumulated since late 2002. That translates to gross sales of approximately $1.9 million. CDW is only one outlet for Toshiba Tablet PCs, and Toshiba is only one in a growing list of Tablet PC manufacturers.
Tablet UML™ is trademark Martin L. Shoemaker. Unified Modeling Language® and UML® are registered trademarks of the Object Management Group. Visio®, Windows®, Windows XP®, Microsoft Visual Studio.NET®, and Tablet PC® are registered trademarks of Microsoft Corporation.
UML® is a registered trademark of the Object Management Group. Tablet PC®, Microsoft Office®, and Microsoft .NET® are registered trademarks of Microsoft Corporation. PayPal® is a registered trademark of PayPal, Inc., an eBay Company.
Copyright © 2005 by Martin L. Shoemaker. All rights reserved.