Executable Books

This book does a good job of giving the reader an idea of the potential of modeling, but it reads like the US tax code. After a while it is numbing. There must be a better way to teach these concepts to humans.

Having worked for an organization that has implemented a model-driven architecture technology approach to create highly robust software applications I can attest to the practical value of translatable models and the information and techniques in this book.

I have always been a fan of the rigor and completeness of the Shlaer-Mellor methodology and this book distils this rigor into a profile of UML that hopefully will inspire a wider audience to look at the reality of creating executable and translatable models.

I found the book extremely well written and very complete in its treatment of every aspect of the subject from basic UML ideas through to model compilers. Unlike many technical texts I found absolutely no fluff in this book - each sentence and section has been carefully worded to be clear, consistent and unambiguous - a breath of fresh air for a pedant like myself.

I have used this book (along with Leon Starr's "Executable UML: How to Build Class Models") as a reference for my course development work on executable UML and found it invaluable. The table of contents and index are complete and well put together - something that I feel is crucial in any reference text.

I highly recommend this book for anyone using UML for software development who wants to explore this new technology of building executable and translatable models - and have it explained clearly and comprehensively.

Two events at the Object-Oriented Systems, Languages, and Applications Conference of 1996 were memorable for me. The first was the opening address given by one of the more insightful architects/designers of the 20th century, Christopher Alexander. And the second was a debate between Stephen Mellor (one of the authors of this book) and Grady Booch on the topic "Translation: Myth or Reality?". Six years later, with the addition of Action Semantacs to UML, the Model Driven Architecture initiative of the Object Management Group, and the publication of this book, it appears that Mr. Mellor is as persistent in his position that executable (and hence translatable) models are indeed a reality, as Mr. Alexander was that the resonance between the structure of a solution and the corresponding problem is a measure of the solution's quality. Good ideas bear up well over time.

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 review from "A reader" is erroneous. There is no review from "Leon Brooks," so it is unlikely there is any business relationship with a non-existent person.

I imagine "A reader" meant Leon *Starr* who runs an entirely separate business from those run by either of the authors. Sure, we talk and refer business each other's way, but that is to be expected. Please delete "A reader"'s review.

(If you know Leon, you'd know he says what he really thinks, even if--especially?--it's bad!)

If you have ever diligently tried to implement a software system using a graphical modeling technique such as UML, I suspect your first attempts,like mine, were less than satisfying. It probably went something like this. Starting with some shiny new UML tool you start drawing diagrams. After a while, things seem "squishy". It's hard to know exactly where to stop modeling. Some things have a clear correspondence to the implementation that you know you have to get to, but many, many other issues crop up that you decide you have to defer to the details of the implementation. At some point in time you convince yourself that you understand the problem very well and then just start coding the implementation. It can be a bit like the Twilight Zone. In the end you wonder just what all those diagrams, which are probably out of date with respect to the implementation, were for.

Fortunately, Mellor and Balcer have given us some real help here. This book is a comprehensive presentation of how to give UML executable semantics. I feel that the emphasis on execution semantics is key. When you write code, you are able to execute it in your head and verify that you think it's correct. You may still make mistakes and introduce bugs, but the process
is concrete. The same definiteness needs to be there when you are modeling. If the model is to be truly a more abstract representative of the system you are designing then you must be able the "execute" the model and predict how the system will behave in its ultimate implementation. And, of course, if the model is that definite then it should be possible to derive automatically the implementation from the model. All of this and much more is discussed in detail in this book. If you struggle, like I do, to deal with your systems problems at a higher
level of abstraction, this is a book you need to read.

The best way to learn a new method is to study an example of how the method is used in real life. This the example!

The introduction to this book goes trough the essentials of the Shlaer-Mellor method from the practising users point of view. About every other page you say to yourself: "Ah - yes - that's how it is...". This since Mr. Starr keeps reminding the reader of some of the odds and ends of the Shlaer-Mellor methodology that might be forgotten while you are busy modelling some small corner of your problem. Very useful.

Even more useful is the rest of the book: - a thoroughly worked out example of how an elevator can be controlled. By choosing a system that we all understand how to use, everything becomes real. The mission of the application and the separation of the service domains become very obvious. Although the models in the elevator example are not fully complete, they give you lots of information and insight.

Especially I like the way Mr. Starr documents his problem space using sketches and figures that clearly explains what's going on and also helps out in the process of finding the right classes and relationships in the model. Studying an example like this helps a lot when building your own models.

Examples are tough for authors, especially in software. As most software people know, a good example can be as big as the book itself. Often the examples in a book just seem overly simply. Mr. Starr has avoided the problem and has given us an entire book as a complete, worked out example. For those familiar with Executable UML, the efforts to combine UML notation with precise execution rules, this book will be a welcome addition. The Introduction chapter is excellent, tracing many of the pitfalls of current software practice. The choice of an elevator as the project subject matter is also inspired. We all have experience with elevators and think we know how they work. I know I have stood waiting for an elevator to arrive, convinced that I could write a better control program that would result in shorter waits. The model in this book reveals how subtle application problems can be even when the subject is superficially familiar. Most important is the fact that the Executable UML is just that -- executable. The software that comes with the book allows you to do load up the model and try it out. And this is an important point. The intent here is to build a formally executable specification that can then be automatically translated into a running system. The model contains all the semantics to do that. For those of us that have practiced this method professionally, one is struck by the fact that these models have the characteristics of real world models. There are small problems that need to be fixed or reworked Fortunately, Mr. Starr promises additional versions in the future. There are additional domains that also need to be modeled. But in many respects the elevator model is not like what one might see in real world practice. The model descriptions are much better than most I have seen. The quality of the descriptions indicates profound depth of understanding of the problem. It is that depth of understanding which is the key to solving any problem.

This book was an excellent reference for me as I am still learning the Shlaer/Mellor method, but I really needed to see the Device I/O service domain and the Transport domain to complete my personal project. Hopefully, you can get this out in the next version, as promised, so the model starts "clicking". Well written and documented.

Blues immortal Muddy Waters sang:

Well, if the river was whiskey, and I was a divin' duck
Well, I would dive to the bottom, never would I come up.

While many of us have worked on at least one software development project that could "drive one to drink," we borrow here only the singer's craving, which, like that of the duck, is hard to satisfy. With "Executable UML - The Elevator Project," Mr. Starr gives those who drink from the waters of software development a river that flows from its plentiful and pure headwaters, the Shlaer-Mellor Method. So, "... if the river was an Executable UML modeled system..."

But, before we drink, the book is a case study, and, as such; the author is challenged to build a bridge that meets the needs of the communities on both sides of the river. Viewed from one bank, we need some understanding of Executable UML, the author's objectives, the Elevator problem and the logistics of the tool. From the other bank we need to see the Elevator project artifacts just as they would be produced, without the commentary and critique of a case study.

Mr. Starr constructs that bridge in the following manner. On one bank it is anchored with the Introduction and the Guide to Printing Model Diagrams Technical Note. On the opposite bank the bridge is anchored with the Elevator Application domain analysis model diagrams (the Project Technology BridgePoint repository is also included) and two design documents, the Elevator Project Domain Model and Class Model Descriptions. Each span is constructed from a set of five additional technical notes that describe the system requirements and the approach to fulfilling those requirements.

Now, let's swim into the waters of the system's domain model and taste model based design. Dive to the bottom of the executable Elevator Application model, and drink from the completeness of an unambiguous domain specification. Nudge any object and observe its behavior, savoring the flavor of continuity between the data, state and process model elements, and quench our thirst for verification in the Automated Simulation Exercise. Let's sip translated code generated with the BridgePoint model compiler, which is provided on the demonstration disk. Finally, we relish the ability of the process to be repeated, documented, standardized, managed and optimized.

"Executable UML - The Elevator Project" is an excellent study in what is probably software engineering's best practice. Through the book's comprehensive detail, we can increase our understanding of Executable UML and its fundamental, distinguishing characteristics: separation of subject matter, executable analysis models, implementation through translation and adaptability to a comprehensive engineering process. "... Well, I would dive to the bottom, never would I come up."

At the price ([price]on my door step), I expected to find something that put all the xUML pieces together, that was worthy of the author's name. What I did find, though, was a book that provided only the most basic information and examples of the topic, and very incomplete at that. You can find xUML white papers freely available on the web which literally contain 100 times more detail and usable technical information. Not only were many parts of the model missing (specifically key service domains), but key elements such as bridge definitions, use cases, etc., were also missing.

Also, there were many self-serving references to both Leon's company and a future book on xUML. Hopefully, THAT book will contain the useful detail that is missing from this one.

For anyone who is considering purchasing this book, wait for the next one and locate the white papers on the web!

I've had one of Leon Starr's other books, "How to Build Shlaer-Mellor Object Models" on my bookshelf for many years and used it as a constant reference for my OO training and documentation work. I have always liked the way Starr manages to simplify conceptual information in an engaging and down-to-earth manner - something that is close to my heart as a veteran educator.

"Executable UML" builds on the models he introduced in his previous book and moves from the S-M world to the executable UML world. I thought the book was very well written and gave a good, clear explanation of what Executable UML actually is and how it extends the UML. The examples Starr uses to explain some of the more abstract ideas and concepts were great and his treatment of relationships and associations was excellent I thought. As well as the clarity of the writing I particularly appreciated the sense of humor in this book - something sadly lacking in many methodology texts.

I've been using this book as well as Mellor and Balcer's book "Executable UML - A Foundation for Model-Driven Architecture" as references in developing xtUML online-learning courses and found them both invaluable.

Great book - highly recommend it.

I bought this amazing labeled book "Executable UML", but its contents is a deception, at least. The author didn't respect the book title, filling the book with a lot of uml basics concepts. The most adequate rating for this "book" is not zero star, but a black hole, to preserve it far..far way from us.

Any developer who is currently using or is planning to use UML on a real project should read this book. Successful completion of one or more Class Diagrams is an essential step for every UML project. This book provides the developer with the information needed to create rock solid Class Models (Class Diagrams augmented with supporting documentation to enable review by other developers). The book is very detailed and yet is written in an easy-to-read and entertaining style. Numerous informative examples are included to reinforce comprehension of the essential topics.

For the beginning UML developer:
-----------------------------------
The basic elements of the Class Diagram (Classes, Attributes, and Relationships) are defined simply and clearly. Categories of each of these elements are then enumerated. Each category is then supported by at least one easily understood example.
An especially useful spectrum of Class categories spanning from the concrete to the abstract is presented. The class categories of hard/physical, discovered, invented, simulated, specification, incident, interaction, and role are covered in detail.

For the intermediate UML developer:
--------------------------------------
Even if you have been building class diagrams for some time, you will likely benefit from several chapters on advanced relationship topics. These topics include Loops and Constraints, Advanced Generalization Relationships, Reflexive Patterns, Network Patterns, Linear Patterns, and Tree Patterns.

For the advanced process-aware developer:
--------------------------------------------
You will be intrigued by the introductory section "What is Executable UML?". This section contains a concise yet exciting description of where the UML is currently headed. For more details on this evolving aspect, you can read about the Action Semantics extension to the UML and the Model Driven Architecture initiative (MDA) of the Object Management Group.

I was disappointed with this book because there is nothing here about UML action language or constraints. That's what I thought "executable" meant, but I obviously got something wrong.

The book is the best I have read class modeling, though. If you want to learn practical UML modeling, I strongly recommend this book.

I've read more than my share of technical texts over the years. With a few exceptions, most are dry, difficult to understand and cover too much material without developing any topic particularly well.

Leon Starr's book "Executable UML: How to Build Class Models" is refreshingly different. Not only is it written in a uniquely engaging style, but it does a fantastic job of developing the concepts that go into Executable UML class modeling.

Furthermore, his introduction "What is Executable UML?" is the best concise overview of the topic I have *ever* read. In under 25 pages, Leon hits every major point of discussion in Executable UML in enough detail to provide real value for the reader. Although it's well worth reading for anyone who's interested in Executable UML modeling, I would especially recommend this chapter to anyone who is *new* to Executable UML, and wants to understand what all the fuss is about.

Leon's approach to the subsequent chapters on class modeling doesn't bog down the book with a complicated discussion of an abstract (and potentially complicated) topic. His discussion is clear, concise, with frequent use of examples to hammer home his points.

He always provides a brief scenario before he launches into a modeling example, giving a excellent context for why he used certain modeling techniques. For beginners in Executable UML, this is an excellent way to get into the mindset of modeling. More experienced readers can also benefit a great deal from the best practices discussed.

Another myth about technical texts is that good content = dry read. Not so! Leon's book is *very* entertaining. This has got to be one of the most pleasant technical reads out there. Interestingly enough, when I turned the final page, not only had I enjoyed the journey, but I found that I *really* understood the topic.

More books should be written like this! "Executable UML: How to Build Class Models" is the exception that *should* become the rule.

The book is synonymous with the Kennedy Carter iUML product it describes, which in turn is simply not able to support large scale, commercial software development. If your project is more complicated than the included examples of a Stop Light, or a Rail Way Station, you will find the book and the development environment lacking. I have been involved in one of the largest projects that attempted to use Kennedy Carter. The project was prominently featured on the KC website. But, in the end KC was not up to the task. There is no support for refactoring, for source control diff and merge, nor even a simple text search of the whole project. I can not recommend either the book or the tool.

Bad news first. For building executable UML models they use Action Specification Language (ASL). ASL is not a part of UML standards. Not so bad news - "Action Semantics for the UML" (OMG ad/01-08-04) imposed as an "unofficial OMG standard". Not by me, but by Anneke Kleppe, if you know, who is this person. And the "Action Semantics ..." is based on the ASL.

Currently ASL is not widely supported by popular UML tools (hah! how many of them really support OCL?). But the lite version of iUML CASE tool comes with the book. I don't want to discuss is this tool good, or is not. At least it gives you the ability to feel the concepts, not only read about them.

In any case, for building truly executable models, you need some kind of action language. And OCL is not that kind of a language. If you think Java is portable enough for PIMs development - use it. The authors did not recommend it, but they did not prohibit it also. You may use ASL, C++, Java, production rules, your own action language, etc. It's up to you.

If you know nothing about MDA and executable UML - don't worry. This book could be used as a start also.

When I sent this feedback, there was no ability to search inside the book. So, let me describe it. This book:
- gives some review of OO methods genesis
- gives an introduction to MDA and executable UML concept, including the difference between a method and a notation
- shows how to fit the method into the development processes
- shows how to gather the requirements with use cases
- shows how the method uses other kinds of UML diagrams to achieve the goal to make them executable, not just a pictures
- exlpains why some of UML diagram types are not used by the method at all, and brings only one extension to UML (state transition tables)
- describes how to build both state-independent and state-dependend behaviour models using UML and ASL
- describes how to integrate different PIMs
- describes how to generate code from models
- contains samples

What could I say. Maybe you have an opportunity to meet the standard of the future. Maybe not. But this book is not just a iUML or ASL tutorial. This is a good book. It was written by real professionals, followers by Shlaer & Mellor school. It's full of useful ideas. Strong, but not boring. Must have.

This book provides and clear and detailed introduction to the method of developing complex software systems indicated by its title. It speaks with an air of authority clearly rooted in the authors' breadth and depth of experience yet retains a light and occasionally amusing style and includes many anecdotes that seasoned software professionals can readily relate to.

The book covers the full software development lifecycle and illustrates a pragmatic and proven approach to adopting a Model Driven approach to software development. The author's are clearly from the so-called `translational' camp that firmly believes in a detailed `Platform Independent Model' from which code generators derive up to 100% of a working system. While detractors might be sceptical of such a claim, the `Executable UML' provides the clue as this is made possible by an `action specification language' that augments standard UML and effectively provides an abstract programming language for the operations defined on the UML model.

While the books intends to be of general application to all types of software development its clear origin and emphasis is on real-time, control, embedded and safety critical software. However there are clearly good lessons that can be applied equally well to Enterprise IT systems and indeed one can see clear parallels and more similarities than differences between the advanced modelling approaches proposed here and in more Enterprise IT oriented texts such as `Domain Driven Design' by Eric Evans. What distinguishes the approach in this text say from Evans is its stated goal and claimed desirability of achieving complete separation of the domain model from the target software architecture.

Overall I thoroughly enjoyed reading this book. It tackled problems I recognised in a practical way and gave me a clear insight into how the method is used. I believe it represents a valuable contribution to the field of complex systems development and worthy of the time of anyone who wants to deepen their understanding of practical MDA.

First, let me warn you that I gave a 3-stars ("medium") rating because I have not read this book. But just reading the peek that Amazon allows, I am very confused as to its purpose and the author's lack of touching on accessibility issues. Let me explain.

If you read through the table of contents, it seems the book is mainly about how to build a multimedia website -- glaringy overlooking the biggest problem with the vast majority of multimedia websites today, that is, lack of accessibility to the deaf, blind, handicapped, visually challenged, and more. But more about that in a minute.

In contrast, reading the introductory pages gives you the feeling that the author is trying to predict what the future of the Internet and the Electronic Age will be. We are already beyond the era of "simple webpages" and well into the Internet as a business medium. However, most Internet-connected devices are currently very specialized and limited in scope and function. The author attempts to paint a vision of the future, where most devices are connected to the Internet and applications are "pushed" to them when they connect...but the amount of data a device receives is "limited"??? That confuses me, because what would be the purpose of on-demand applications, except to access data of one sort or another.

This is why the author's lack of a chapter (or 2 or 3) regarding the poor state of Internet Accessibility is so unexplainable...as long as most writers of software, hardware, websites, business applications, multimedia, and so forth choose to ignore the lack of accessibility to the disabled and those with other challenges, which prevent a large proportion of using the Internet right now (relatively simple though it is, compared to this vision of the future) -- how could this vision called "X-Internet" even get started?

Also, I wonder how these people can propose to call this vision "X", considering "X" is currently a Window Mangement system for computers running Linux. I could see people getting the terminology more confused when you consider that in Linux and Unix, the desktop can be run by one computer for the benefit of a user interacting via another computer, completely transparently. It even seems that the term "X-Internet" may have been purposely appropriated for just this reason. But it's even worse when they propose to call the technology in general just plain "X", since a technology called "X" already exists.

This book might still be an interesting read, but I think I will wait until I see some more reviews that are more detailed about just where this book delves.

Besides, without in-depth coverage of accessibility (and such an Internet vision as this requires in-depth coverage because it would depend on addressing the severe shortcomings that presently exist), this book could in no way be considered an authoritive or even an influential discussion of "X-Internet".

The book is strongly concerned about providing design guidelines for programmers writing graphics programs, with which users are expected to interact. So there's a lot of advice about best practices for what widgets to use, how to lay them out, and how not to overwhelm the user.

It also describes the authoring of video and audio for the Internet. Plus numerous other programs. There is a good variety and richness of topics, that shows how the Internet is getting well built out.

But it should also be clear that it is not necessarily all about the Internet. Some programs are best meant for running locally on your machine. Ajax is mentioned, for enhancing the client side experience on the browser. But even this cannot match the richness of a (well-designed) locally run program.