Wikiquote

Executable UML

software development method and a highly abstract software language

Executable UML is a software development concept intended to enable Unified Modeling Language (UML) models to be compiled, translated or weaved into executable code such as Java bytecode or machine code and then executed.

Quotes

edit
Quotes are arranged in chronological order

1990s

edit
  • Today some evidence arises that UML will more and more be used not as a specification language but as a high level programming language. This has some advantages, as if the concepts of UML are executable, they can immediately be animated and tested, or the generated code even be used as implementation. Thus UML probably will have an implementation-oriented semantics describing this animation.
  • Originally UML was intended to serve as a specification language. But a specification is primarily intended to describe properties of systems that the system developers want to be valid, but to leave open other properties that are not clear already. Today this is partly achieved by having a semantics that is rather vague (and here we mean imprecise as opposed to not detailed). However, this is not an advantage, as the developer cannot fix this kind of impreciseness within UML, but can adapt the individual interpretation only. Furthermore, to get complete (and therefore executable) UML descriptions, often certain details have to be specified, which the developer does not yet know or wants to leave open to a later phase of development or even implementation. It is an intrinsic problem of executable languages that this kind of over-specification frequently occurs. Instead it would be of some help to have flexible concepts of under-specification to postpone detail decisions to situations, where the decisions can and must be made.
  • The Unified Modeling Language (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, lifecycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is intended to support most existing object-oriented development processes.
  • I assume that a precisely defined, verifiable, executable, and translatable UML is a Good Thing and leave it to others to make that case... In the summer of 1999, the UML has definitions for the semantics of its components. These definitions address the static structure of UML, but they do not define an execution semantics. They also address (none too precisely) the meaning of each component, but there are "semantic variation points" which allow a component to have several different meanings. Multiple views are defined, but there is no definition of how the views fit together to form a complete model. When alternate views conflict, there is no definition of how to resolve them. There are no defined semantics for actions...
    To determine what requires formalization, the UML must distinguish clearly between essential, derived, auxiliary, and deployment views. An essential view models precisely and completely some portion of the behavior of a subject matter, while a derived view shows some projection of an essential view...
    All we need now is to make the market aware that all this is possible, build tools around the standards defined by the core, executable UML, and make it so...
    • Steve Mellor in Andy Evans et al. (1999) "Advanced methods and tools for a precise UML." UML’99—The Unified Modeling Language. Springer Berlin Heidelberg. p. 709-714
  • In its current form UML is designed to support a wide variety of different modelling techniques and formalisms. This is evident, for example, in the state machine formalism which allows both Moore and Mealy formalism with hierarchical states including concurrent sub-states and both synchronous and asynchronous calling semantics. The result of this is not only that almost any state modelling style can be supported but also that many combinations of elements have no defined execution semantics. It is now widely recognised within the UML community, however, that considerable benefit can be gained by forming subsets of the UML with well defined execution semantics. Such subsets can form an “executable UML” which would enable the simulation, execution, testing and ultimately translation of UML models into target code. As part of this movement, work is progressing under the auspices of the OMG towards the definition of “profiles” that define such subsets and towards the more detailed definition of the contents of “actions” including a more precise definition of the execution semantics of UML models.
  • The use of UML collaboration diagrams for specifying complex real-time architectures has been the focus of some recent work. The central idea is to capture architectural specifications in a formal way. This has a number of important advantages. First, it means that the architectural models can be formally analyzed for consistency and completeness. It also means that the models are executable and allow early and precise assessment of the validity of different architectural approaches... Support for this form of UML-based architectural modeling is now available in a commercial tool from Rational Software (Rose RealTime). This tool allows the construction of executable UML models and has the capability of automatic generation of complete systems from such models.
    • Bran Selic (1999) "Turning clockwise: using UML in the real-time domain." Communications of the ACM Vol 42 (10). p. 53-54
  • The use of UML techniques in TRADE has implications for the semantics of these techniques when they are used this way. Class diagrams and statecharts are used in TRADE to represent software architecture at the essential level, where we can assume perfect technology. This means, for example, that actions do not take time and that all objects perform their tasks in parallel. A first version of such an essential-level semantics is presented elsewhere. This semantics differs from the OMG semantics, in which actions take time, there are several threads of control and one message queue per thread which can receive signals exchanged by objects. The OMG semantics is clearly intended for and appropriate to what I call the implementation architecture. This is called the design model in the Unified Software Development Process. The use of C++ as action language in the executable UML models of Rhapsody confirms this, as does the outline of the executable statechart semantics given by Harel & Gery...

2000s

edit
  • Ever wish you could draw a few diagrams, press a button, and have a working software system that meets your needs? Sound like magic? Perhaps, but that’s a major part of the Executable UML vision. The basic idea is that you will use a CASE tool to develop detailed UML diagrams and then supplement them by specifications written in a formal language, presumably the OMG’s Object Constraint Language (OCL). The basic idea behind Executable UML is that systems can be modeled at a higher level of abstraction than source code, simulated to support validation of your efforts, and then translated into efficient code. This higher-level of abstraction should help to avoid premature design, enable you to change your system as your requirements evolve, and to delay implementation decisions until the last minute.
  • In my opinion this sounds great in theory, but unfortunately there are several problems to making this work in practice:
    • The UML isn’t sufficient. The UML is clearly not sufficient for business application development, as I argue above, so trying to generate a system only from UML models at the present moment simply won’t suffice.
    • Integrating a collection of tools to support Executable UML is currently difficult. Let’s assume that one or more tool vendors decide to implement the Executable UML vision and fill in the gaping holes inherent in the UML... Because there isn’t a complete standard in place the various vendors will to add their own unique extensions making multi-vendor tool integration difficult.
    • A single vendor approach will likely prove too narrow. Another approach would be for a tool vendor to support both modeling and code generation features in their tool, something perfectly reasonable in theory. But, because of the wide range of platforms, and range of design options within those platforms, the tool vendors will need to focus on a single niche...
    I have no doubt that we will begin to see some interesting tools emerge over the next few years based on the Executable UML vision.
  • The entire history of software engineering is that of the rise in levels of abstraction. Executable UML is the next logical, and perhaps inevitable, evolutionary step in the ever-rising level of abstraction at which programmers express software solutions. Rather than elaborate an analysis product into a design product and then write code, application developers of the future will use tools to translate abstract application constructs into executable entities... This shift is made possible by the confluence of four factors:
    1. The development of the Model Driven Architecture (MDA) standards by the Object Management Group (OMG)
    2. The adoption of the Precise Action Semantics for the Unified Modeling Language specification by the OMG in November of 2001
    3. A proposed profile of UML—Executable UML—supports creating a complete and implementation-neutral self-contained expression of application functionality. Steven J. Mellor and Marc J. Balcer define this profile in their book Executable UML: A Foundation for Model-Driven Architecture
    4. The availability of high-quality Model Compilers and Virtual Execution Environments (VEEs) that provide "out of the box" platforms upon which Executable UML models can execute. These VEEs, which exist today in a somewhat incipient stage, will someday soon reduce low-level system architectures to near-commodity status.
  • Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change.
    • Stephen J. Mellor & Marc J. Balcer (2002) Executable Uml: A Foundation for Model-Driven Architecture. p. 5
  • Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem.
    • Stephen J. Mellor & Marc J. Balcer (2002) Executable Uml: A Foundation for Model-Driven Architecture. p. 10
  • Steve Mellor has long been active in this kind of work and has recently used the term Executable UML [Mellor and Balcer, 2002]. Executable UML is similar to MDA but uses slightly different terms. Similarly, you begin with a platform-independent model that is equivalent to MDA's PIM. However, the next step is to use a Model Compiler to turn that UML model into a deployable system in a single step; hence, there's no need for the PSM. As the term compiler suggests, this step is completely automatic.
    • Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 4
  • Models and simulation furnish abstractions to manage complexities allowing engineers to visualize the proposed system and to analyze and validate system behavior before constructing it. Unified Modeling Language (UML) and its systems engineering extension, Systems Modeling Language (SysML), provide a rich set of diagrams for systems specification. However, the lack of executable semantics of such notations limits the capability of analyzing and verifying defined specifications. This research has developed an executable system architecting framework based on SysML-CPN transformation, which introduces dynamic model analysis into SysML modeling by mapping SysML notations to Colored Petri Net (CPN), a graphical language for system design, specification, simulation, and verification. A graphic user interface was also integrated into the CPN model to enhance the model-based simulation. A set of methodologies has been developed to achieve this framework. The aim is to investigate system wide properties of the proposed system, which in turn provides a basis for system reconfiguration.
    • Renzhong Wang (2007) Executable System Architecting Using Systems Modeling Language in Conjunction with Colored Petri Nets - a Demonstration Using the GEOSS Network Centric System. University of Missouri--Rolla. Abstract, leaf iii.
  • What do you think of using UML to generate implementation code?
    James: I think it’s a terrible idea. I know that I disagree with many other UML experts, but there is no magic about UML. If you can generate code from a model, then it is programming language. And UML is not a well-designed programming language.
    The most important reason is that it lacks a well-defined point of view, partly by intent and partly because of the tyranny of the OMG standardization process that tries to provide everything to everybody. It doesn't have a well-defined underlying set of assumptions about memory, storage, concurrency, or almost anything else. How can you program in such a language?
    The fact is that UML and other modelling language are not meant to be executable. The point of models is that they are imprecise and ambiguous. This drove many theoreticians crazy so they tried to make UML "precise", but models are imprecise for a reason: we leave out things that have a small effect so we can concentrate on the things that have big or global effects. That's how it works in physics models: you model the big effect (such as the gravitation from the sun) and then you treat the smaller effects as perturbation to the basic model (such as the effects of the planets on each other). If you tried to solve the entire set of equations directly in full detail, you couldn't do anything.
    • James Rumbaugh in Federico Biancuzzi and Shane Warden eds. (2009) Masterminds of Programming. p. 339

2010s

edit
  • Executable textual modeling tools support automated code generation. For example, Ragel supports a number of high-level languages but is targeted towards text parsing and input validation. Ruby on Rails recently added built-in support for state machines. The State Machine Compiler (SMC) is targeted towards the specification of event driven systems. Microsoft is also developing a textual specification language, AsmL, based on state machine concepts. Those approaches do not incorporate class diagram abstractions and do not support development of complete applications. Executable UML supports a subset of UML textually but misses key features of UML and does not integrate with programming languages.
  • Regarding executability, it is clear that from the hypothetical day when a UML virtual machine would be universally adopted, UML-based process models would have a real benefit. Process modelers supposed to be already familiar with UML diagrams would then simply have to draw their process models using their usual UML tools. They would then be able to test, execute and debug them as everyone does with her usual programming language. UML 2.0 offers the potential to define such virtual machine thanks notably to the Activity and Action packages, which come with an operational semantics. Some ambiguities in this operational semantics (given in natural language in the standard), have however to be first fixed. This is one of the purposes of a recent initiative at the OMG, called Executable UML
  • Executable UML (xUML) consists of UML class diagrams, UML state machines and an action language which complies with the UML action semantics. There are several action languages in use; we refer to for a—somewhat limited—overview. The xUML models to be translated are expressed in the Cassandra/xUML dialect, as developed by KnowGravity.
  • We present a fully automated approach to verifying safety properties of Executable UML models (xUML). Our tool chain consists of a model transformation program which translates xUML models to the process algebra mCRL2, followed by symbolic model checking using LTSmin. If a safety violation is found, an error trace is visualised as a UML sequence diagram. As a novel feature, our approach allows safety properties to be specified as UML state machines.
edit
 
Wikipedia
Wikipedia has an article about:
Retrieved from "https://en.wikiquote.org/w/index.php?title=Executable_UML&oldid=3191064"