Objects by Design is pleased to bring our readers this interview with Stephen Maguire, founder of Zicom Systems, the creators of Zicom Mentor - Visual Dictionary UML 2.0. This innovative reference guide to the Unified Modeling Language is a fully interactive, browser-based, electronic book which provides detailed reference material on the full UML 2.0 syntax.
The UML 2.0 specification has been long in the making and UML 2.0 products are just now starting to arrive. What do you view as the major improvements in UML 2.0 and how will they help the software development community?
Learning a new language gives us great powers of expression; we also become part of a community of UML speakers who can help each other. The power and promise of UML is in its ability to express the thoughts and ideas of people from all around the globe in a universal language that crosses industry, cultural and natural language boundaries. The new UML 2.0 appears a little daunting at first but provides some wonderful new ways for people to express their thoughts and I think is easier than its predecessor. Some examples of the way that different disciplines can benefit from the new features are as follows:
Business Modeling and Analysis
A great deal has been added for the Business Modeler and Analyst; even though at first glance there doesn't appear to be a lot of change for modeling the context of a system. The Activity Diagram has been completely revamped (now based on Petri Nets) and allows a great deal of expressiveness. The flow of data can be represented on diagrams. Business processes, represented as activities, can form hierarchies and can even be inherited. Swimlanes have become richer and more useful, and there are even elements to represent what happens when the process goes wrong, called Interruptible Activity Regions. There is a much easier translation from diagrams traditionally used to model information flow such as Data Flow Diagrams. Elements called ports can be used to show the way that business objects interact with their environments. The Interaction Overview Diagram provides new ways to model a number of other business concepts. A Timing Diagram could be used to model the events and the time it takes for an order to be processed or even the opening hours of an office.
Architecture Design and Programming
There are a great many changes in UML 2.0 that allow the modeler to be more expressive, resulting in models that are more useful and that close the gap between what is in the mind of the designer and the reality of a system. Composite Structure Diagrams have added ways to represent how an element relates to its environment, by the use of ports and delegations. Confusion around the use of interfaces has been removed with the addition of the new required interface. Sequence Diagrams have had a major overhaul and have added a device for reusing parts of the diagrams and ways of representing iterations, conditional branches, and parallel processes. This has always been a weakness with UML 1.x and the new syntax allows the dynamic aspects of systems to be represented very precisely. There are so many new UML 2.0 elements that come to the rescue and allow a modeler to represent a simple or a complex system.
Networks and Infrastructure Design and Management
Many new aspects of the UML allow a system's hardware and software to be modeled including development, testing and production environments. The UML 2.0 has added a number of new elements that allow the deployment of systems to be described very easily. These include new elements such as Devices, Deployment Targets, Deployments and Deployment Specifications amongst others. These new elements allow the modeler to create rich and expressive diagrams that completely describe such things as network topologies, routers, VPNs and the complex relationship between the software and the hardware on which it is deployed.
Project Managers Testers and other Roles
A great deal has been added and many elements and diagrams have been made more useful in the UML 2.0. Artifacts have been changed and a project manager can use these to model the inputs and outputs in the software development lifecycle. They can also be used to show the upstream relationship to the requirements and the downstream relationship to pieces of software and hardware. The addition of a diagram as an element in its own right allows a diagram to be composed of a number of different views. For example a domain model diagram with classes could include a Statechart Diagram to show important changes in an object's lifecycle. The new Interaction Overview Diagram provides ways of creating high-level pictures of a system. The Timing Diagram could be used to represent the release schedule and important business and technical events such as client demonstrations and walk-throughs. Testers can use a number of new aspects of Collaborations and Use Cases to specify test cases and identify points of potential system failure in both business and computer systems.
Zicom Mentor has taken a unique, interactive approach to teaching the UML notation. The product uses Macromedia Flash in an innovative way to highlight elements of a UML diagram using mouse rollovers. What inspired this approach to interactivity? Do you envision any additional interactive aspects in the future?
In the words of that famous twentieth century physicist - if you define a problem carefully enough the solution will simply jump out at you. A new language should be fun and engaging, the newcomer to the language should be given encouragement and shown how easy it is to start reading and writing UML.
How it is achieved
We have tried to remove all obstacles to learning and used a number of visual affects and interactivity to allow users to explore the example UML diagrams in an environment that makes learning fun and easy. UML books typically resort to the use of extraneous lines and arrows to point out aspects of the UML; as a result the reader becomes confused as to what is UML and what is just annotation and explanation. Mentor removes this confusion by using rollovers to illuminate elements and gives the user visual feedback in panels around the diagram. A toolbox shows the element that you would use if you were creating the diagram yourself. Color has been used to represent the UML grammar - in Mentor UML elements that are the same color have the same grammar and typically have many things in common. Users get this for free and just by using Mentor they are learning about the way elements can be combined. For example, an Actor, a Node and a Class are UML classifiers and Mentor represents them all with the same color, and while their appearance is vastly different, they have many similarities. The diagram explanations also use color to show the relationship between natural language meanings and the UML elements - click on the diagram text and the diagram illuminates and shows the relationship between UML and the written word.
Additional Interactive Aspects
We now have quite a sophisticated engine for representing and explaining the UML and are devising new ways to make it easier for people to become experts in UML. We are planning new releases of Mentor early next year that will take this interactivity to another level.
UML tool vendors have been slow to implement UML 2.0. There are also major shifts in the market with smaller, nimbler vendors rapidly producing new versions of their products while older vendors have slowed their release cycles significantly. There are a lot of promises being made for MDA while agile modeling is calling for less tool usage and more modeling at the white-board. What do you make out of this UML tool market? Do you see developers using and gaining real benefit from UML modeling? UML 2.0, with its added formalism, is
meant to bring better automation in the process of software development. Do you see any promises in recent UML tool releases that indicate that these intended advantages will become real?
UML - A language for both whiteboards and blueprints
Any language is there to help us express ourselves and share our ideas. English has hundreds of thousands of word but we don't use them all everyday. Sometimes we need to be formal and other times we can be informal. Shopping lists are scribbled on pieces of paper, but contracts are written in formal legal language. The same goes for the UML. I encourage the newcomer to UML not to be too concerned about the methodology and process debates. Both Agile modeling and Model Driven Architecture (MDA) have their place, and UML can be used with both. I love the fluidity of sketching on napkins and white-boards; sometimes these sketches never make it to a UML tool, and at other times ideas start in a tool and end up on the white-board. I do encourage the newcomer to UML to use whatever method is appropriate and whatever they find most useful to them and their team. The tool market is in a state of flux, everything changes - this is a natural part of the evolution of an industry, just look at other examples. Five years ago we all used a word processor. I hardly touch one now, spending most of my time in my favorite UML, XML, or HTML editor.
UML can give your ideas a profound clarity
The power of UML is really in shared ideas, and I do think that developers (and others) will gain a great deal of benefit from the UML. A tremendous clarity can be gained from mastering the UML and using it to model a system. Projects typically don't fail because a 'while' loop was used instead of a 'for' loop; that can be corrected in a few minutes. They fail because risk isn't managed, because the stakeholder's can't see what is being constructed, because the architecture was flawed or wasn't tested or because a requirement or constraint fell down the void between the project brief and the design team. Sometimes they succeed only to discover that the wrong system was built. These things are all addressed by UML. If you were a tradesperson you wouldn't attempt to start your work without a plan. The UML has great promise, as soon as we all learn a little more, and do a little more we will see the attenuation of these issues that have plagued our industry for decades.
What lies on the horizon for the UML tools
The key thing that is likely to happen is that the new syntax for the Interaction (Sequence and Communication) Diagrams in UML 2.0 has paved the way for the round trip engineering of the dynamic aspects of a model and system. So it is likely that the tools will be able to reverse and forward engineer any number of source files and create both Class and Sequence/Communication Diagrams. A movement towards business process analysis and modeling is also looming. This will see the merging of what have been two quite separate fields and possibly if the tool vendors bring them under a single umbrella this may provide the necessary impetus for the disciplines to merge - thus closing the interdisciplinary gap that so often leads to system failure.
The recently released Head First Design Patterns by O'Reilly is a good example of using a highly visual approach to teaching complex object-oriented concepts. Zicom Mentor has also taken a visual, interactive approach to teaching. What sorts of other multimedia techniques have you thought of that could augment Mentor? Have you thought of using audio or animation? How about a full-scale UML case study that would walk the user through each diagram type for a real application?
Interactive devices to help simplify the UML
I welcome anything that helps people understand and reduces the complexity of a subject area. Mentor has attempted to make the UML more accessible by using a number of visual and interactive devices. The elements use color to represent the underlying grammar of the UML, the examples are industry and role neutral so a business analyst working in a finance domain or a network designer working in manufacturing can both understand the example. We have built a powerful diagramming component that allows the user to interact and explore the diagrams. We are currently researching and testing a number of other techniques to animate the diagrams. Most of this will be focused on allowing users to explore the material and derive ideas for their own work. We hadn't thought of sound so we will give that some consideration.
UML case studies
I have thought very carefully about the case study and have started it a couple of times. The problem is that all projects are different in their own specific ways. Most projects don't go through the whole life-cycle. For example I have worked on projects where the system existed and the client wanted a UML model to be created retrospectively to explain the system to the support team. Another client had a choice of three disparate databases and just wanted the UML to model a proxy database so they could delay their decision and allow the developers to continue work coding to the proxy. Another client just wanted to use the UML to model the interfaces to external components and middleware. Another customer wanted to model their business problem well enough to allow them to use the UML as a problem statement that vendors had to respond in a uniform way so they could compare their proposals. The case study would need to address these real project situations. The other difficulty is deciding on a domain that everyone can understand, and isn't trivial is quite a challenge, the ATM examples are useful but tend to be a little dry. Having said this we are working on a case study with a slightly different approach - more of that in the next couple of product releases.
New to UML
What is your advice to newcomers to the UML?
If you were learning a new foreign language, I would say go out and practice your language, use it to help you get the most out of every situation. Don't be shy, you will make mistakes, let others correct you. Learn the grammar, get familiar with the bits of the language that are most useful to you and reuse them. So how about UML? Practice the UML, learn not to be precious about making mistakes, this is where scribbling on a white board or a napkin helps; doing this will help you become fluent without being fearful of the language. Before you draw a diagram, ask yourself what the purpose of the diagram is and who the audience is. If you can't identify at least one person (or computer) that will treasure the diagram you are thinking about drawing - consider not drawing it. Remember though that the audience may be yourself. Newcomers tend to draw tens of diagrams and when they are asked who is going to read them they typically answer - 'I don't know yet..' Find someone who will benefit from your diagram before you commence drawing it; ask them what would be useful to them. Draw a little, check it with them and draw a little more. The UML is a language for modeling systems and is therefore abstract. One way to get around this leap from concrete to abstract is to model concrete things. People often start modeling with Actors and Use Cases and then don't know how to continue. Most people have had the experience of working with a computer, so if the deployment environment exists, start by modeling the computers. It would be a mistake to think of the UML as like a computer language. Its audience is much broader than the audience of a computer language, which is typically a private conversation between a programmer and a computer program (compiler or interpreter). The UML is useful to stakeholders, marketing managers, company strategists, testers, project managers, support desk operators as well as all the conventional information technology staff.
A diagram for all disciplines
There has been a tendency to think that certain UML diagrams are specific to particular disciplines. For example newcomers tend to think that Use Case diagrams are only used for requirements or that component diagrams are only used for modeling software. Nothing could be further from the truth. Everyone of the diagrams can be used with any discipline. Use Case can be used to model the behavior of a subsystem or a computer algorithm. The Component diagrams can be used to model replaceable parts of a business system such as a filing system. So consider adding some new diagrams to your repertoire.
Not everyone speaks UML
Don't expect that everyone will speak UML. The detailed syntax of the UML will be meaningless to some people, so be prepared to explain or walk-though your diagrams. If people don't understand them, teach them some UML or change your diagram. I do encourage you to look at the Visual Dictionary, there is a wealth of knowledge and a simplification of the UML that makes it accessible to everyone, business and computer professionals alike.