When IBM acquired Rational Software Corp., the company gained the expertise of two technologists who have been instrumental in the development of the Unified Modeling Language (UML).
Grady Booch, Rational's former chief technology officer who is now an IBM fellow, is considered a father of UML, since the standard is based on the modeling language he created. Bran Selic, a distinguished engineer in IBM's Rational Software division, co-chairs a task force that is finalizing the new UML 2.0 standard with the Object Management Group.
Booch and Selic recently spoke with Computerworld about UML 2.0, which is expected to be finalized by midyear.
What are the major differences between UML 1.5 and the upcoming 2.0 version?
Selic: In 1.5, we introduced something called the action semantics, which is a way of modeling some of the fine-grain detail that comes in with specifying models, maybe even down to the level of individual instructions. Along with that came this idea of describing what that actually means in terms of the runtime. How is this thing executed? What does a program that this thing models look like? And that introduced something which was a key element of the UML 2.0 -- a very precise definition of the semantics or the meaning of these models in the sense that one could now, for example, take a UML model and directly translate it, in some cases, into programs directly. This is part of a much more general thing called Model Driven Architecture (MDA), which is shifting the focus from the programs toward models, because models are much closer to the way that people writing applications or at least using applications think about their problems. It's a higher level of abstraction.
One of the fundamental inputs to UML 2.0 was support for Model Driven Architecture and model-driven development [MDD]. That required a somewhat greater precision of UML than there was originally in the spec. ... The other one that I would single out as being a major influence is the ability to model very large heterogeneous systems so that one could describe the architectures of these systems quite succinctly.
The project in formulating UML 2.0 started almost three years ago, and we are now in the closing stages of adopting the standard. We have released one version so that people who are building tools that conform to the standard can look at it and come back with feedback. And various researchers and other people who are interested in UML and model-driven development are looking at the spec and giving us feedback.
For a corporate developer who has been using UML 1.0, how will UML 2.0 make their lives better?
Selic: They have choice. We were careful when we designed 2.0 that people who want to use UML as they've been using it to date are pretty safe, and they don't necessarily have to move up to the new features. The language is designed in such a way that you don't have to know about the new things in order to use the old things. But they would certainly benefit from the ability to scale up certain models to deal with heterogeneous and distributed environments. If they had that need before, it'll be a lot easier for them to use UML now. They could simply move up by starting to gradually introduce some of the newer concepts as they are needed. You can take parts of UML 2 that you need and discard or not use the parts that you don't need.
Many say UML adoption has been slow, in the range of 10%. Why do you think it has been slow?
Selic: One of the most significant factors is that there is a tremendous investment in existing technologies, both corporate and personal, and jumping to UML does require some incremental costs and investments on top of the existing one. There are also cultural issues. But in the end, I would say that UML and model-driven development have to happen because we can't develop software the way we've been developing it. The systems we're trying to build are so much more complicated than the systems we were building 30 years ago. I think MDA and UML 2.0 support the ability to go to higher levels of abstraction so that all that implementation stuff doesn't get in the way. UML does that. It abstracts out a lot of the underlying implementation, programming language stuff and so on. The second aspect of it, that has to do with MDA, is automation. For example, the ability to take models and automatically generate implementations from them is something that is a key theme of model-driven development, and that's what UML was adjusted to. So the adoption has to increase, and we are certainly seeing other large vendors that are realizing that model-driven development is something that has to happen.
Booch: Ten percent is not necessarily a bad thing, if we consider the worldwide developer market according to IDC is approximately 13 million or so IT professionals. Ten percent's a nice healthy number. That's a great penetration in the sense that we're dealing here with the community of people that worry about abstraction and design, and if we limit ourselves to just that community, I would dare say that the UML has a tremendous penetration. If you look at the community at large, perhaps it is 10%, 20% we've seen in some other cases. ... If we take a look at the acceptance of modeling by not just IBM but Microsoft and Sun's Jackpot project, in many ways this is a tremendous validation of the concept of modeling as a mainstream technology, because every one of these vendors is recognizing that systems are intrinsically complex. And the way we advance in dealing with complexity is by raising levels of abstraction. Ergo, modeling becomes fundamental, and the UML is indeed the open standard of choice for modeling.
Do you think Microsoft's Whitehorse project promotes greater adoption of model-driven development?
Booch: I'm delighted that Microsoft has recognized that modeling is a good thing. ... Rational's had a very long relationship with Microsoft providing tools for modeling with the UML in the context of Visual Studio.
In what types of companies and situations have we seen the greatest usage to date?
Booch: We can tell some wonderful stories of some of the predecessors of the UML, and we can carry that out to stories now with the use of the UML precisely for use in building real-time systems. We're talking cell phones, medical electronic devices and the like. ... At the other end of the spectrum, we see the UML being applied by business professionals dealing with business rules. In fact, this is an area where we're spending energy to provide tooling for business rules in the form of the UML. On the deployment side, we see the same thing in terms of people who are dealing with complex topologies. Game scenarios and grid computing is an area where I've seen some traction in this space. At a complete other end of the spectrum, the UML is pretty much the language of choice for patterns.
Selic: My biggest experience has been in the embedded real-time domain. The reason that community adopted it so broadly and enthusiastically is because their problems tend to be very complex, because they have to deal with the world that's very concurrent, unpleasant, things failing and so on. So they were seeking some help. ... But what we're seeing nowadays is that this complexity is no longer just something that belongs in the embedded world but in, for example, the business world with things such as Web services and so on. So I've seen an increase in the need for something like this even in domains which were traditionally thought of as, "Oh, this is just Cobol." The distinction between so-called real-time systems and business and data processing systems is diminishing.
How much automatic code generation can users expect?
Booch: I want to talk about the premise, which is that's one of the main benefits. It reminds me a lot of some of the early days of OO [object-oriented development], when we talked about the main promise of OO was reuse, and a few years later, everyone was all up in arms in the press because, "Oh, reuse didn't come to happen, and look how terrible it was and look how we overpromised." This really is not the main promise of where the UML is headed. It goes back to the larger theme that things are complex. We advance in our discipline by raising levels of abstraction. We see this with our language and our methods and the like, and that's exactly what's happening with UML. It allows us to raise the level of abstraction. That's the primary thing that we're seeking with UML. Now the issue of getting closer to code, that's a tremendous benefit, but I wouldn't consider that's the main thing that the UML should be judged against.
Selic: In terms of what people can expect, our experience is that it's an entire spectrum. People can use UML as what somebody once called a sketching facility -- just a way of describing high-level ideas without necessarily talking about "if" statements and things like that and then using that to communicate with the design team and the testing team and even possibly with customers and so on. That's a very informal way of using it. There are numerous examples of complete code generation. I know of systems that are, for example, generating a complete implementation from a single UML model in the order of millions of lines of code involving hundreds of developers and in some very complex domains. There may be situations where it's not desirable to have complete code generation because there are legacy systems to be taken into account. ... So people can expect anything from zero to 100% depending on their circumstances.
Can you cite any examples where people have gotten 100% code generation?
Selic: I've seen it in telecommunications software, and I have also seen it just recently in India, where it's being used in business process modeling, very successfully at a very high level of abstraction.
Through the use of MDA and UML, will we ever get to a point where business analysts can write their own applications?
Booch: All that's really changing is the language of expression. There is momentum in the marketplace that says to build a successful software-intensive system requires a larger set of stakeholders than we were used to in the past. The Web space just sort of hit us in the face with that. In the early days, you'd see hard-core code warriors writing graphical user interfaces, and it was a perfect scene out of "Dilbert," because those weren't their skills and vice versa. You'd find graphics students, graphics experts who'd try to write hard code and it would also be a failure. So ultimately we got to the point where we realize, "Oh, here's how these various people work together." Well, in the business rules space, you've got yet another stakeholder, and so the issue now is how do I get those people to play well, as well as with the security people, the networking people and all that. That's the fundamental problem in many development organizations. Does UML help? One of the key value propositions of the UML in that sense is it's a common language that allows people from multiple disciplines to talk with one another. Will we ever get to the point where all these people can write in their own language and do magical things? My personal opinion is that's multiple years out and even if it were in multiple years, technology is going to get sufficiently more complex that it's hard for me to judge beyond that.