UML --- the Good, the Bad or the Ugly? Perspectives from a panel of experts

TL;DR: The dynamic semantics of UML are defined quite generally and cover a wide range of possible specializations and have led many (including, obviously, several of my co-panellists) to conclude that “UML has no semantics”.

Abstract: ion is the process of removing or hiding nonessential detail from view so that the principal characteristics of interest and their relationships are more clearly visible and, thus, more easily understood. This obviously depends on the area of concern, which means that abstraction is always done from a particular viewpoint. With the exception of the very earliest ones, thirdgeneration programming languages provided two fundamental and clearly separated viewpoints for specifying software: the structural and behavioural. This basic partitioning, although quite useful, is not sophisticated enough for today’s complex needs. In a modern objectoriented programming language, for instance, one can clearly see which objects are declared in a program (the structure), but it is very difficult to determine from looking at the code how their mutual interactions combine to realize an overall end-to-end use case (the behaviour). This is because these languages do not provide constructs that allow direct specification of interaction sequences – a common failing of all “modern” object-oriented programming languages. Instead, you specify how each component responds to individual inputs and then cross your fingers and hope that these increments add up to the desired end-to-end sequence. Unfortunately, quite often they do not. When that happens, it is very difficult to find out why, because it is not easy to discern the high-level sequence out of the mass of fragmented behaviour code. In contrast, UML provides a number of high-level viewpoints through a series of diagrams. This gives users the ability to specify systems using any convenient combination of diagrams. Since the semantic relationships between these viewpoints is specified by the underlying UML metamodel, it is often possible to automatically detect inconsistencies in the specifications – “often”, but not always. As Steve Mellor points out in his discussion, there are examples where one would like to be able to detect inconsistencies but where UML does not help. (What he fails to point out, however, is that the problem of determining this type of inter-viewpoint consistency is still an unresolved theoretical problem in the general case, particularly when concurrency is involved.) Still, UML 2.0 has done much to allow detection of such inconsistencies. In particular, it has done a much more thorough job of defining the dynamic (run-time) semantics of UML. At the most fundamental level, these semantics consist of an explicit specification of the essential structural entities involved at run time – elements such as objects, attributes, variables, and links – and the effects that individual actions have on these entities. This is complemented by a trace-based model that defines the semantics of inter-object actions (interactions). At the next level up are the semantics of higher-level behavioural formalisms, such as state machines and activities. These are layered on top of the semantics of actions and interactions. Although these semantics are not definedusing amathematical formalism, they are certainly open to such formalization and at least one major research project is currently under way to do just that. Of course, in the ideal situation, a formal model of these semantics should have been included in the standard, but this is hardly ever the case in practice (after all, how many modern programming languages have a formal semantics included in their definition)? The dynamic semantics of UML are defined quite generally and cover a wide range of possible specializations. This is because UML is intended to cover a relatively wide range of diverse domains. For example, the same semantics can be specialized to support either a synchronous worldview (i.e., a view in which all events occur at discrete intervals according to the beat of some global clock) or an asynchronous one. The organization of the UML 2.0 specification document is such that the sections describing semantics are not gathered in one place but are, instead, fragmented and scattered throughout the text – this is due to the nature of a specification document, which is not necessarily optimized for readability. Unfortunately, this has led many (including, obviously, several of my co-panellists) to conclude that “UML has no semantics”. However, a closer examination of the spec would clearly reveal that this is not the case. While it is fair to argue that the semantics of UMLmight be incomplete, imprecise and, perhaps, inconsistent, and it is fair to complain about the organization of the document itself, it is definitely incorrect and unfair to claim that UML has no semantics. As noted, some of the latitude in the semantics of UML is intentional, to allow a range of different domainspecific specializations. Still, UML was never intended as a universal base that covers all possible domains. Where the semantics of UML or its syntax are inappropriate, users have the option to use the Meta-Object Facility (MOF) to define a language that is independent of UML. However, in those cases where UML is suitable, it provides a very rich catalogue of pre-packaged, expertlydesigned modelling capabilities that are likely to be shared by many modelling languages. These include the foundational run-time semantics model described above as well as facilities for modelling system architectures, event-driven behaviour, high-level end-to-end interactions and complex hierarchical procedures. 12 B. Henderson-Sellers : UML – the Good, the Bad or the Ugly? Clearly, this capability is valuable to language designers. However, much more significant is the benefit to users who may already have knowledge of general UML. It is useful to recall that, since its adoption as a standard in 1997, UML has been taught and used more than any other modelling language and, consequently, has a significant and growing base of users. This large and growing community is able to reuse all of that knowledge when working with domain-specific variants. On top of such semantic reuse there is also the potential for tool reuse because a tool that supports standard “general” UML can, in principle, also support any profile of UML. Since there are very many commercial tools that support standard UML the benefit of this should not be underestimated. It is muchmore likely that such tools can be used to support domain-specific variants than custom tools for domain-specific languages. In many ways, the success of model-driven development in general is predicated on the availability of sophisticated and powerful tools, comparable to the kinds of sophisticated tools for supporting current programming languages (e.g., configuration management tools, compilation tools, build tools, debugging tools etc.). If a whole new array of such tools has to be developed for each new domain-specific language, it is unlikely that tool vendors would ever be able to keep up. Model-driven development would look a lot less attractive to its potential beneficiaries under such circumstances. Another distinguishing and highly useful characteristic of UML 2.0 is its support for constructing higherlevel abstractions. This includes concepts for specifying complex interconnected object structures, concepts for specifying either complex functions (UML activities) and for complex object interactions (UML interactions). Because most of these capabilities can be applied recursively, it becomes possible to define custom abstractions at practically any conceptual level. The net result of this is that UML 2.0 scales up much more easily to allow modelling of very complex systems of different kinds. Inevitably, one of the drawbacks of supporting multiple domains is a relatively large number of language features. This leads to another often repeated complaint about UML: that the language is just “too big and unwieldy”. But this ignores the fact that UML has been carefully modularized into a set of sub-languages many of which are independent of each other. Hence, it 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 pick and appropriate only those parts that are of use in solving their problem. The rest can be safely ignored. To summarize, the support for abstraction in UML 2.0 is based on a proven set of capabilities that seem to be shared across many different domains. For such domains, this makes it much a more suitable foundation for constructing domain-specific languages. Support for automation Automation is, by far, the most effective way to boost reliability and productivity. The objective is to mechanize repetitive and uncreative tasks, where human fallibility causes problems. There are a number of ways in which automation can be applied in model-driven development. Perhaps the most obvious one is automatic code generation or, to put it differently, model compilation. While various historical and other incidental aspects may force us to compromise and use partial code generation that is supplemented by manual programming, fully automated code generation from models is clearly the ultimate objective. There are many examples of industrial modelbased systems that use full automatic code generation, so this is not merely a promise for the future but state of the art. Another way in which automation can be applied to models is in formal verification and validation. This has been a long-standing objective in software development, but has been thwarted in the past by the highly complex and non-linear nature of current programming languages. A single misaligned pointer can spell doom for a multimillion-line program and its users. Because of this, it is very difficult to mathematically formalize these languages in a way that accurately reflects their semantics. Therefore, results of formal analyses of modern software are often inaccurate and untrustworthy. The advantage that modelling languages provide is that their con