Rating: 
Summary: An must read for serious software developers!
Review: Before clarifying who I think will benefit from this book, I must contradict the review that claims this book is just for Bridgepoint users. I have been building executable models since 1984 using a variety of tools, on numerous real-time/embedded projects. I used Illogix on a recent project for example. In the olden days we used AutoCAD to enter the models and AutoLISP to extract the model content and generate partial code. Regardless of toolset, my colleagues and I have successfully implemented the critical concepts described in Steve and Marc's book. Experienced engineers know that you start with an engineering process and THEN figure out what tools you need to get the job done. Not the other way around (as today's most popular tool vendors would have you believe!)NOTE: If you meet the criteria I've listed under "Who should buy this book", Chapter 14: Control Strategies alone is worth the price of this book, no matter what object oriented methodology or tool set you use. In addition to the handful of tools that fully support the engineering approach defined in Steve and Marc's book, there are many tools out there that partially support this approach. Combinations of mainstream tools and increasingly available Opensource utilities can also help you get the job done. Okay, enough about the tools, let's focus on what is really important. You should NOT buy this book if:
-------------------------------------
All you do is slap quick and dirty scripts and utilities together. You really love coding in C++ or Java and can't imagine why you would ever want to do anything differently. Your only interest in UML is to display your C++ in pretty rectangles with happy stickmen. The development time required to build a complete product in your organization is on the order of 1-3 months max. You SHOULD buy this book if:
--------------------------------
You have attempted to use UML on a real project and been seriously disillusioned. You want to focus effort at a higher level of abstraction than that afforded by implementation dependent languages like C, C++ or Java. You develop large real-time distributed or embedded applications with complex requirements. You know that there must be some way to disentangle the fundamental application rules from the implementation, yet each time your company creates a new product version or a spinoff, the application has to be re-specified and re-coded to a large extent. You routinely tackle extreme complexity, but don't want to end up with obnoxiously complex statecharts (See my note on Chapter 14 at the end of this review). Some things that make this book DIFFERENT
---------------------------------------------------------
There are over a hundred UML books that you can buy on Amazon. But even those books that try to address real-time systems fail miserably to address many PRACTICAL issues critical to building complex real-time systems. Steve and Marc define a complete development language. This language uses the UML notation, but is a LOT more than just notation. In addition to the UML notation, they:
Define an explicit model of synchronization (how time works when you don't know what processor, operating system or even hardware partitioning into which your software is ultimately packaged). Provide complete executable semantics for an implementation independent interpretation of how models execute on any arbitrary implementation. Explain a process whereby the specification can be fully separated from the implementation and various layers of middle ware can be separated from both of these layers. Raise the level of abstraction (way above C++ and Java) for solving complicated application problems while at the same time providing a language that can be (and has been) translated into non-object oriented (VHDL, C or Assembler) as well as object-oriented language implementations. In particular, Chapter 14: Control Strategies (Domain Dynamics) is one of my favorite chapters. I haven't seen anything like this in ANY other UML book. This chapter, if you have the experience and patience to work through the example and really understand what is going on (I predict most people will just skim through and completely miss the point) will change the way you think about organizing class collaborations (communicating state machines). It shows you an excellent process for decreasing the complexity of your collaborations. This is just one of the many concepts presented in this book that transcends your model editor/development tools.
----------
Everything in this book is practical. There isn't a thing in here that I and my colleagues haven't applied to solve real problems on a real project. This stuff works! Read this book and the world of software development as you know it will change forever. Welcome to the next level.
Rating:
Summary: An must read for serious software developers!
Review: Before clarifying who I think will benefit from this book, I must contradict the review that claims this book is just for Bridgepoint users. I have been building executable models since 1984 using a variety of tools, on numerous real-time/embedded projects. I used Illogix on a recent project for example. In the olden days we used AutoCAD to enter the models and AutoLISP to extract the model content and generate partial code. Regardless of toolset, my colleagues and I have successfully implemented the critical concepts described in Steve and Marc's book. Experienced engineers know that you start with an engineering process and THEN figure out what tools you need to get the job done. Not the other way around (as today's most popular tool vendors would have you believe!) NOTE: If you meet the criteria I've listed under "Who should buy this book", Chapter 14: Control Strategies alone is worth the price of this book, no matter what object oriented methodology or tool set you use. In addition to the handful of tools that fully support the engineering approach defined in Steve and Marc's book, there are many tools out there that partially support this approach. Combinations of mainstream tools and increasingly available Opensource utilities can also help you get the job done. Okay, enough about the tools, let's focus on what is really important. You should NOT buy this book if:
-------------------------------------
All you do is slap quick and dirty scripts and utilities together. You really love coding in C++ or Java and can't imagine why you would ever want to do anything differently. Your only interest in UML is to display your C++ in pretty rectangles with happy stickmen. The development time required to build a complete product in your organization is on the order of 1-3 months max. You SHOULD buy this book if:
--------------------------------
You have attempted to use UML on a real project and been seriously disillusioned. You want to focus effort at a higher level of abstraction than that afforded by implementation dependent languages like C, C++ or Java. You develop large real-time distributed or embedded applications with complex requirements. You know that there must be some way to disentangle the fundamental application rules from the implementation, yet each time your company creates a new product version or a spinoff, the application has to be re-specified and re-coded to a large extent. You routinely tackle extreme complexity, but don't want to end up with obnoxiously complex statecharts (See my note on Chapter 14 at the end of this review). Some things that make this book DIFFERENT
---------------------------------------------------------
There are over a hundred UML books that you can buy on Amazon. But even those books that try to address real-time systems fail miserably to address many PRACTICAL issues critical to building complex real-time systems. Steve and Marc define a complete development language. This language uses the UML notation, but is a LOT more than just notation. In addition to the UML notation, they:
Define an explicit model of synchronization (how time works when you don't know what processor, operating system or even hardware partitioning into which your software is ultimately packaged). Provide complete executable semantics for an implementation independent interpretation of how models execute on any arbitrary implementation. Explain a process whereby the specification can be fully separated from the implementation and various layers of middle ware can be separated from both of these layers. Raise the level of abstraction (way above C++ and Java) for solving complicated application problems while at the same time providing a language that can be (and has been) translated into non-object oriented (VHDL, C or Assembler) as well as object-oriented language implementations. In particular, Chapter 14: Control Strategies (Domain Dynamics) is one of my favorite chapters. I haven't seen anything like this in ANY other UML book. This chapter, if you have the experience and patience to work through the example and really understand what is going on (I predict most people will just skim through and completely miss the point) will change the way you think about organizing class collaborations (communicating state machines). It shows you an excellent process for decreasing the complexity of your collaborations. This is just one of the many concepts presented in this book that transcends your model editor/development tools.
----------
Everything in this book is practical. There isn't a thing in here that I and my colleagues haven't applied to solve real problems on a real project. This stuff works! Read this book and the world of software development as you know it will change forever. Welcome to the next level.
Rating:
Summary: Comprehensive and well-written
Review: 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.
Rating:
Summary: A UML profile for serious system development
Review: 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.
Rating: 
Summary: Shame!
Review: Leon Brooks works for the company pushing the product described in this book. It's poor form to give it a five-star review without mentioning this interest, which appears like bias.
Rating: 
Summary: New Notation, Old Failures
Review: The book recasts Shlaer-Mellor OOA into UML notation while preserving all advantages and failures of the first.
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.
Rating:
Summary: Author correction
Review: 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!)
Rating:
Summary: Author correction
Review: 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!)
Rating:
Summary: Author correction
Review: 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!)
Rating:
Summary: For BridgePoint Suite users or evaluators!
Review: This book heavily uses the BridgePoint tool suite from Project Technology as its basis. Knowing that up front is important because the content is specific to that set of tools. You can get eval copies of the tool suite from the vendor, and should be able to get them from the book's supporting web site, which was not fully operational at the time of this review. 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.
| 
