- Save 10% when you spend $100 or more on textbooks. Enter code SAVE10 at checkout. Offered by Amazon.ca. Here's how (restrictions apply)
Executable UML: A Foundation for Model-Driven Architecture Paperback – May 14 2002
Special offers and product promotions
Customers who bought this item also bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your mobile phone number.
Would you like to tell us about a lower price?
If you are a seller for this product, would you like to suggest updates through seller support?
From the Inside Flap
At one time, the title for this book was Executable UML For Model-Driven Architectures (MDA) Using Aspect-Oriented (AO) Techniques with Extreme Programming (XP), Agile Modeling (AM), and Other Agile Alliance (AA) Processes as an Instance of the Rational Unified Process (RUP).
Eventually, we settled instead on Executable UML: A Foundation for Model-Driven Architecture. This title is snappier, but it's not as fully buzzword-compliant as the original.
So what is this Executable UML? It is a profile of UML that allows you, the developer, to define the behavior of a single subject matter in suffcient detail that it can be executed. In this sense, the model is like code, but there's no point in writing "code" in UML just to rewrite it in Java or C++, so it's rather more revealing to examine what executable UML doesn't say that code might.
An executable UML model doesn't make coding decisions. It makes no statement about tasking structures; it makes no statement about distribution; it makes no statement about classes or encapsulation. An executable UML model describes only the data and behavior, organized into classes to be sure, about the subject matter at hand. In other words, an executable UML developer describes subject matters at a higher level of abstraction than she would in a programming language.
To build a system, we build an executable UML of each subject matter. Typically, the system includes subject matters such as the application, a user interface, and some general services. The executable UML models for each of these subject matters are then woven together by an executable UML model compiler.
The model compiler targets a specific implementation embodying decisions about "coding:" tasking structures, distribution, data structures (which may be quite different from that suggested by the class structure), as well as the language. Model compilers can be extremely sophisticated, taking care of cross-cutting concerns such as transaction safety and rollback, or they can be sophisticated in a different way, targeting small footprint embedded systems with no tasking or other system support.
In general, a model compiler compiles several executable UML models, each of which captures a single cross-cutting concern to yield the running system. In this sense, executable UML makes use of the concepts in aspect-oriented programming.
Executable UML models support a new Object Management Group initiative, Model-Driven Architecture (MDA). This initiative is in its early stages, but its goal is to allow developers to compose complete systems out of models and other components. This goal requires at least an interface as contract and, behind the interface, the ability to express a solution without making coding decisions. That would be executable UML, or some variation.
This book does not describe model-driven architecture or its implications. Rather, this book focuses on one aspect of MDA that we believe to be critical: the ability to model whole subject matters completely and turn these models into systems. This ability, we believe, relies on being able to execute models. Hence executable UML.
Because the developer builds models as executable as a program for each subject matter, all the principles of extreme programming and agile processes can be applied. Indeed, many of the principles of these processes having nothing to do with coding per se.
You can use executable UML in a deliberate process or, because the models are executable, an agile one. Our preference is agile and incremental because it keeps the focus on delivering working software.
And what about RUP? As one of our reviewers, Martin Fowler, so memorably said: "My biggest concern with RUP is that it's so loose that any process seems to qualify as an instance of RUP. As a result, saying you're using RUP is a semantics-free statement." So we can reasonably assert that the process described by this book is an instance of RUP. (And if you want, we do.)Frequently Asked QuestionsIs this the only possible Executable UML?
No. This rendition views each object as potentially having a state machine that can execute asynchronously and concurrently. We view this approach as necessary for today's distributed computing environments. However, one could define an executable UML that relies on synchronous method calls between objects to produce a completely synchronous model of the subject matter. Similarly, our particular use of the statechart diagram is not the only possible one.Is Executable UML a standard?
Yes and No. The notational elements you see in this book conform to UML, and so qualify as a profile of that standard. In addition, the execution semantics defined here conform to UML, though we do both subset UML and impose certain rules to link the elements together. What is not yet a standard is the exact content of what can and should be interchanged so that we can guarantee that any and all model compilers, irrespective of vendor, can compile any arbitrary executable UML model.
Throughout this book, we use standards as much as they are established. In some areas, the book is intended to provide a basis for discussion of what should ultimately become a standard.Will there be a standard one day, and how might it differ?
Yes, we hope so. Work has begun informally to define a standard and we will encourage and support it. We expect the standard to define an underlying semantics quite similar to that outlined here, and to layer increasingly rich syntax on top.Does that mean I should wait?
Not at all. This technology is taking off, and the basic elements are already established. Get ahead of the learning curve.I know hardly anything about UML. Is this book too advanced for me?
We assume you have an intuitive understanding of the goals behind UML, but nothing more. We will show you all the elements you need to build an executable UML model.I'm a long-time UML user. Do I need this book?
If you want to garner the benefits of Executable UML, then you'll have to learn the elements that make it up. Focus on the deWnitions we use and the chapters that show how to build and execute models. Skip the notational stuff. Be prepared to unlearn some UML and habits of mind required to model software structure, but not required to specify an executable model.What happened to adornments such as aggregation or composition?
We don't need them for Executable UML. UML enables you to model software structure, but that's not our purpose here, so those adornments, and many others, are not in our profile.Some of this seems familiar. Is this just Shlaer-Mellor in UML clothing?Shlaer-Mellor focused on execution and specification of an abstract solution, not on specifying software structure. UML can be used for both the expression of software structure and the abstract model. Executable UML brings Shlaer-Mellor and UML together by using UML notation and incorporating concepts of execution. We hope this will make execution accessible to a broader community.I've used Shlaer-Mellor before. Is this any different?
A lot can happen in this industry in ten weeks, let alone the ten years since the publication of Object Lifecycles. First of all, of course, we all now use UML notation and vocabulary. (Resistance was futile.) Executable UML takes a more object-oriented perspective, no longer requiring identifiers or referential attributes, or other traces of Shlaer-Mellor's relational roots.
The addition of an action semantics to the UML is a major step forward. We hope the action semantics, and the very concept of an executable and translatable UML may one day be seen as a signiWcant contribution of the Shlaer-Mellor community.
Progress in tools has also made certain conventions, such as event numbering, less critical to model understanding, though they are still helpful in keeping our minds clear.Why do you say "Action Semantics?"
Because UML defines only the semantics of actions, it does not define a language.But how can you execute without an action language?
We use an action semantics-conforming language that is executable today. We show several other action languages to illustrate that syntax is unimportant.You use an Online Bookstore case study. Can I use this if I'm a real-time developer?
Yes. We chose a more IT-oriented case study to increase the reach of the approach. You can find a completely worked out real-time case study in Leon Starr's book Executable UML: The Elevator Case Study.How can I get an Executable UML tool?
All of the examples in this book were developed using Project Technology's tool, BridgePoint.First, compiling models produces the whole system, not just interfaces or frameworks. Second, there are many different model compilers available to buy, and even more that can be built, to meet exacting software architecture needs.Where has Executable UML been used?
Executable UML has been used to generate systems as large as two million lines of C++, and as small as handheld drug delivery devices. Executable UML has also been used in lease-origination, web-enabled executive reporting, and intermodal transportation logistics systems.Why did you write this book?
Because we had nothing better to do? No: There are lots of books out there that tell you about UML notation, but few of them focus on the subset you need for executability. Many books use UML to describe software structure. We explicitly spurn this usage.Why should I buy this book?
Because it describes completely everything you need to know about executable UML: It's the Executable UML handbook.
Stephen J. Mellor
San Francisco, California
Marc J. Balcer
San Francisco, California
From the Back Cover
Executable UML is a major innovation in the field of software development. It is designed to produce a comprehensive and understandable model of a solution independent of the organization of the software implementation. It is a highly abstract thinking tool that aids in the formalization of knowledge, and is also a way of describing the concepts that make up abstract solutions to software development problems.
This timely new book, Executable UML: A Foundation for Model-Driven Architecture, thoroughly introduces, documents, and explains this important new technology. The authors show how UML can formalize requirements and use cases into a rich set of verifiable diagrams, how it can be used to produce executable and testable models, and how these models can be translated directly into code. In addition, the book explains how individual system domains are woven together by an executable UML model compiler.
The book is full of tips and techniques to help you:
- Partition a system into subject matters based on individual aspects
- Pick the right level for use case modeling to speed subject matter comprehension
- Model classes and focus on relationships to capture subject matter semantics precisely
- Express behavior using the newly adopted UML action semantics and action languages
- Specify constraints using tags specified in OCL (Object Constraint Language)
In addition, this book tackles topics of particular importance in execution, such as how to:
- Synchronize objects by building lifecycles using statechart diagrams
- Model relationships and contention safely
- Distribute dynamics to avoid unmaintainable controller objects
- Verify the models by executing test cases against the statechart diagrams and constraints
A large-scale, fully developed case study runs throughout the book to illustrate concepts and techniques. These models, plus tools to translate and run Executable UML models, can be downloaded from the book's websites, www.executableumlbook.com and www.projtech.com.
There was a problem filtering reviews right now. Please try again later.
The backbone of the book is model driven architecture, which is a strong and practical way to approach design and development. In a nutshell, the BridgePoint tool suite, which consists of modeling and translation tools, allows you to 'draw' the design, using UML, to produce domain partitions, state charts, class diagrams and action specifications. The tool checks your design for consistency and correctness, then the translation tool turns your design into executable code. This is code generation on steroids.
Because this book uses a specific product it is most useful to BridgePoint tool users or those who are evaluating this tool set. If you are not in either audience you will probably be disappointed with the book. If you are in either audience, this book is excellent and justifies the 5 stars I am awarding it.
Mr. Mellor, and this book, are not for the faint hearted. It is his position that building software systems should be more about engineering a solution than artfully handcrafting one, and that to do this, one needs a disciplined process and a rigorous and precise engineering tool: Executable UML. If you agree with this tenet, and accept its implied challenge--or just want to know where they will lead you--this is a book for you.
In this book, Mellor and Balcer present a very lean and agile profile of UML and define the underlying execution semantics that enable it to be used as a valuable engineering tool for analyzing, designing, and implementing your systems. They also prescribe an engineering process to follow when modeling a software system, and thoughtfully walk the reader through this process and the various UML models with numerous examples and real-world experiences. If you use UML to model software, and aspire to engineer that software in the process, this book will give you a lot to think about and add significantly to your engineering tool chest.
The authors failed to realized that in contemporary, commoditized software market the winner is not the product that has the greater number of functional requirements implemented (they will all do), but the one that has better addressed non-functional requirements and software engineering "-ilities". Both non-functional requirements and "-ilities" originate design forces that can only be addressed by the model compiler. Not surprisingly, the authors delegate the OOA of model compilation domain to another, yet to be written tome.
The authors' analogies to high-level language compilation are, at best, incomplete. One must always remember that after decades of research a new compiler must still be built for every advanced "metal". Contemporary distributed object-oriented systems present a continuously changing landscape of such "metal".
Executable UML will be useful to System Engineers interested in "animating" functional requirements and analysis-level concurrencies. However, no incremental way of building OOA models has been suggested. It seems that the authors subscribe to "just do it" approach. The view-of-participated-objects (invented by Ivar Jacobson and popularized by Mike Ackroyd) could be a better alternative.
Software engineers may find some of the terminology confusing. A subsystem, for example, is not defined as a center of execution, but as a subdomain.
Overall, the book presents little added value to already skilled in Shlaer-Mellor OOA. For the newcommer to the world of translational methodology, the book raises a false hope for the out-of-the-box model compilation -- the claims of exponential growth in model compiler availability have already been made in the past.