|
|
AS OF 7/4/2008 8:33PM EST
|
UML 2.0: Exploiting Abstration and Automation
By Bran Selic
March 15, 2004 —
Object Management Group Inc. (OMG) standardized the initial version of the Unified Modeling Language (UML) in 1997. Since then, UML has been very widely adopted by both industry and academia as the language of choice for describing the architectures of software systems. This is reflected in the fact that it is currently supported by literally hundreds of commercial tools.
In June 2003, the Architecture Board of OMG approved the proposal for the first major revision of UML, version 2.0. This is the initial step in the standardization process slated for completion by this summer. If the ambitious goals behind it are realized, UML 2.0 will represent a major milestone in the evolution of software development technologies.
This is because the primary driving force behind UML 2.0 is model-driven development, an approach to developing software that shifts the focus of development from code to models, and to automatically maintaining the relationship between the two. The essence of software modeling (as in all modeling) is abstraction: the removal of fickle and distracting detail of implementation technologies as well as the use of concepts that allow more direct expression of phenomena in the problem domain.
ART OF ABSTRACTION
Given the increasing sophistication of today's software applications, the solution to the current software crisis must inevitably rely on increased levels of abstraction when specifying software. Abstraction is really the only effective means that we have of dealing with complexity that overwhelms our cognitive capacities.
However, there is more to model-driven development than just the concept of models, which, after all, is an idea that has been around almost as long as software. The second key ingredient of model-driven development is an increased level of automation-that is, the use of computers to automate many of the mechanistic tasks involved with software implementation. Once again, we are on safe ground here: Automation has been the traditional technological solution whenever it was necessary to significantly improve productivity and reliability.
Automation in model-driven development is much more than just automatic code generation directly from models. It includes automatic verification of software specifications to ensure that the system satisfies its requirements.
This is an objective that is much more easily achievable using modern modeling languages such as UML 2.0, because the concepts in such languages can be made to behave much better than the concepts in traditional programming languages, where a single misaligned pointer can lead to multimillion-dollar system failures. Automation also includes the crucial ability to execute abstract and incomplete models using computers. In particular, it must be possible to do this with very abstract and incomplete models defined early in the development cycle because this is when all the key architectural decisions are made. Finally, automation also means the ability to automatically generate test cases and test harnesses for automatically driving those test cases.
The dual themes of automation and abstraction were the dominant design forces in the definition of UML 2.0. Their effect, however, is not immediately obvious. An experienced UML user will find most of the familiar landscape with some extensions of existing capabilities and a relatively small number of new features.
INNER WORKINGS
Most of what is new, however, is "under the hood": a more precise and more comprehensive definition of the runtime semantics of UML, and a much tighter and more formal definition of the meaning of the modeling concepts and their mutual relationships. These are necessary to support the automation objectives, since automation is usually only possible if there is no ambiguity. They reflect the extension of UML from being primarily a descriptive language to one that can also be prescriptive, as a matter of choice.
This does not mean that UML is a programming language in the traditional sense. The broad scope of UML still demands the possibility of semantic variation-the ability to customize the language for specific domains and purposes.
For example, the runtime semantics of UML, which are founded on the notion of causally connected event traces, are still open to different specializations. Thus, they can be adjusted to support either a synchronous worldview (i.e., a view in which all events occur to the discrete beat of some global clock) or an asynchronous one. This allows UML to be used in either type of situation and, possibly, in some combination of the two.
The necessary semantic tightening is easily achieved through the specification of the appropriate profiles. To support this, the profile mechanism in UML 2.0 was improved and simplified. Since proper UML profiles are always compatible with standard UML, people using profiles can reuse their knowledge of standard UML as well as any tools that support standard UML.
In addition to the semantic tightening required to support automation, several important new features and extensions have been added to UML. Perhaps the most notable is the ability to use UML to effectively model very large software systems (where the capacity for abstraction is needed most). This includes new modeling concepts for specifying dynamically and statically interconnected patterns of object structures, as well as concepts for specifying complex object interaction patterns. These capabilities have been distilled from existing architectural description languages and standards such as Acme, MSC 2000, SDL 2000 and UML-RT.
In addition, UML 2.0 has the ability to specify complex functions (activities) based on the capabilities defined in de facto industry standards, such as BPEL4WS (a de facto industry standard language for Web services and business process modeling), and traditional techniques used in systems engineering.
Because all of these capabilities can be applied recursively, they are useful at any level of abstraction, thereby covering the range from relatively small to the largest systems. This ability of UML 2.0 to scale up simply yet effectively is one of its most distinguishing characteristics.
MORE GIRTH
Of course, the introduction of new features means that the girth of the language has increased compared with previous versions. This raises reasonable concerns about the complexity of the language (so-called "language bloat" has led to the demise of more than one well-intentioned programming language). To counter this effect, UML 2.0 has been modularized into a set of sublanguages, many of which are independent of each other.
Hence, learning and using UML 2.0 is not an "all or nothing" proposition. Just like one does not need to know all of the English language to use it effectively, users of UML can select only those parts that are of use in solving their problem. The rest can be safely ignored.
In a sense, UML 2.0 has merely repeated the pattern of successful innovations introduced by the so-called third generation of programming languages, by increasing the levels of abstraction and automation. It holds the promise of releasing us from the programming language trap in which we have been mired for over four decades.
This is not merely a promise for the future. Powerful model-driven development tools are now available from Borland, IBM and other major tools vendors. These tools have been used successfully in numerous large model-driven development projects. The maturity of these tools and related techniques is borne out by the Model Driven Architecture (MDA) initiative launched by OMG, whose objective is to define a set of industry standards that directly support model-driven development. The UML 2.0 standard is one of the keystones of this initiative.
Bran Selic is principal engineer at IBM Rational Software Canada, and co-chair of the UML task force within Object Management Group Inc. responsible for ratifying UML 2.0.
|