d level components, then the CPU. All of these more advanced technologies were built on transistors; the level of abstraction and the sheer power increased substantially, along with ease of use. There's a strong analogy between what happened then in hardware and what is happening now in software.
Years ago, assembly language was the basic implementation technology, then basic languages like FORTRAN, C, or COBOL. It was hard to use these technologies to create building blocks with well-defined interfaces that could be reused easily. Later advances, such as C++ and Java, and the development of object-oriented technology, made it easier to create and re-use these building blocks. Component-based development takes object technology to a higher level. Components build upon the object building block. Components tend to go beyond individual objects. A whole billing subsystem for a cell phone com
pany, which could have hundreds of separate objects in it, can be a component. Modules that sit on top of a core database are another example of components. What's happening now is components are getting standardized. CORBA can tie together components using standard message passing, and talk to ActiveX on the other side.
BYTE:
How does the Unified Modeling Language fit in with this trend?
Rudisin:
Using the hardware example again, there's only one notation used to design electronic circuits, shared by all circuit designers in the world. There are absolutely standard symbols for transistors, capacitors, resistors, and so on, and the ways in which their interconnections are described. Until recently, there was no standard way of expressing how software components are defined, what the interfaces were, and how the pieces could snap together. Instead, you had a number of different methodologies: Booch, Object Modeling Technique, Shlaer-Mellor, Coad-Yourdon, and so on. Wh
at we saw is people liked the idea of object technology, but the sheer absence for any common language was a real impediment to the rapid growth of the market. Rational Software set out explicitly to remove this fragmentation, and drive the creation of a single, open standard notation for describing objects and components. That's what we now call the Unified Modeling Language. The Unified Modeling Language has now been formally accepted as a standard by the Object Management Group, after an extensive public commentary process and rapid endorsement by Microsoft, Oracle, IBM, HP, Texas Instruments, and all the other major players in the business. Microsoft was the first co-sponsor, and has been quite enthusiastic about the UML.
BYTE:
What does UML mean for programmers?
Rudisin:
What that means is we now have the equivalent in the world of software for the standards for circuit design or the standards that exist among architects of buildings for describing how big build
ings are built. It's one of the few things that Microsoft, Oracle, and IBM agree upon. So if you're building an application with components from IBM, from Microsoft, or Oracle, before, where you might want to mix various connectivity technologies such as CORBA and ActiveX, it was awkward to model a system that had a CORBA and ActiveX piece. Now, with UML being a universally adopted standard, it's a lot easier to design and model systems that have components from any one of those sources. We view this as a very important evolution.
BYTE:
How is Rational delivering UML technology to the market?
Rudisin:
We are building a strong family of tools to automate different elements of component based development, for example, modeling the requirements for a system, modeling the components, various kinds of software quality testing, automating configuration manangement aspects of software, and automating the software process. That last one is the example of defining/enforcing
a formal software process. For example, if 50 people are working on a big software application, to be more predictable and reliable, there needs to be a process where if someone changes some code, it should be tested first, or analyzed first by a programmer.
BYTE:
Sounds good, and I have seen a lot of help wanted postings on the Net looking for programmers with UML expertise. But I've also seen comments that UML is a bit complex. How do you respond to those complaints?
Rudisin:
First, the UML is actually far simpler than many of its predecessors. We intentionally considered the usability of the UML, and so in its development sought to reduce the number of concepts it contained and to eliminate any gratuitous or grating inconsistencies in the language. The basic concepts of the UML can be taught in just a few pages of text. Second, software development is fundamentally hard, and there is no way to eliminate complexity. You can only aspire to manage it. Consider buildi
ng a multi-story office building. You can't exactly just sketch out a rough design on the back of an envelope, hand it to a contractor, and then declare victory. Yet, that's what a lot of software projects do, and that's why a lot of software projects fail.
The UML is squarely directed toward the problem of managing complexity -- and this not only means projects involving millions of lines of code, but also problems with teams of one or two people working on a multi-month project. To be able to visualize, specify, construct, and document, which is the focus of the UML, a Web-based, n-tier, distributed, and concurrent system with a large GUI and RDBMS element is not something you can do on the back of an envelope with a minimalist language. Like constructing a high rise, you need an expressive language that lets you explore lots of different views.
You have to realize that the 80/20 rule applies here: about 80 percent of your common modeling problems can be handled with about 20 percent of the U
ML. We made sure that modeling simple things was, well, simple. You can also model hard things. For example, consider the semantics of Microsoft's ISAPI mechanism in the presence of legacy DLLs and its interaction with the apartment threading model of Windows/NT: the UML is well-suited to modeling such problems, but this a) requires some of the more detailed parts of the language and b) these are not details that all users of the UML will ever have to know. But as they move to crafting more complex systems, they will be happy to know that the UML supports what they need to do. The UML is quite powerful and general, so it can apply to all kinds of software systems. However, like a programming language or a powerful application, people can effectively use parts of the UML without having to master the entire notation. And of course, numerous tools exist, including Rational Rose, that automate the creation of requirements, architectures, and designs using the UML.
photo_link (61 Kbytes)
Unified Software Building Blocks
