Home > Store

Executable UML: A Foundation for Model-Driven Architecture

Register your product to gain access to bonus material or receive a coupon.

Executable UML: A Foundation for Model-Driven Architecture


  • This product currently is not for sale.
Not for Sale


  • Copyright 2002
  • Dimensions: 7-3/8" x 9-1/4"
  • Pages: 416
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-74804-5
  • ISBN-13: 978-0-201-74804-8

Using Executable UML (xUML), developers can build UML models that can not only be unambiguously interpreted by human readers, but can be tested and validated through actual execution, and ultimately translated directly and completely to target code. This technology offers immense potential for accelerating development projects, enhancing reliability, and reducing cost. In this book, two of the field's leading experts introduce every facet of xUML. The authors introduce Executable UML's goals, premises, and features; then drill down to explain its key elements. Along the way, readers will discover exactly how to use xUML to create software systems that can be tested even before they are coded, enabling far greater reliability at significantly lower expense. For all developers, analysts, and project managers seeking to improve software reliability, time-to-market, and value. This book will be especially valuable to real-time programmers, and to thousands of programmers who have used Shlaer-Mellor methodologies.

Sample Content

Online Sample Chapter

Exploring the Role of Executable UML in Model-Driven Architecture

Downloadable Sample Chapter

Click below for Sample Chapter(s) related to this title:
Sample Chapter 1

Table of Contents




1. Introduction.

Raising the Level of Abstraction.

Executable UML.

Making UML Executable.

Model Compilers.

Model-Driven Architecture.


2. Using Executable UML.

The System Model.

Domain Identification.

Use Cases.

Iterating the System Model.

Modeling a Single Domain.


State Machines.


Iterating the Domain Models.

Iterating between System and Domain Modeling.

Verification and Execution.

Model Verification.

Model Compilation.

Iterating Verification and Execution.

The Big Picture.


3. Domains and Bridges.


Domain Missions.

Domain Autonomy.

Domain Replacement.

Domains and Requirements.


Aspects and Join Points.

Domains and Aspects.


4. Use Cases.

Basics of Use Cases.


Use Cases.

External Signals.

Working with Use Cases.

Single-Domain Use Cases.

Levels of Use Cases.

Applying Use Cases.

Activity Diagrams.

Formalizing Use Cases.



Linked Use Cases.

Scenarios and Testing.

System Modeling.


5. Classes and Attributes.


Finding Classes.

Naming Classes.


Finding Attributes.

Attribute Data Types.

Core Data Types.

Domain-Specific Data Types.

Using Types.

Documenting Classes and Attributes.

Diagramming Classes and Attributes.

Class Descriptions.

Attribute Descriptions.

Checking Classes and Attributes.

Subject-Matter Check.

Abstraction Checks.

Attribute Checks.

Rules, Rules, Rules.


6. Relationships and Associations.


Association Names.

Association Meanings.


Association Descriptions.

Checking Associations.


Capturing the Correct Classes and Roles.

Multiple Associations.

Association Classes.

Generalization and Specialization.

The Concept of Generalization and Specialization.

Mutual Exclusion and its Implications.

Repeated Specialization.

Multiple Generalization.

Compound Generalization.

Reflexive Associations.

The Class Model.


7. Class Actions.

Object and Attribute Actions.

Selection Expressions.

Link Actions.

Link Object Actions.

Generalization Hierarchies.

Other Action Languages.



Actions and Syntax.


8. Constraints.

Unique Instance Constraints.

Single Attribute Identifiers.

Multiple Attribute Identifiers.

Multiple Identifiers.

Derived Attributes.

Referential Constraints.

Referential Attributes.

Derived Identifiers.

Association Loops.

Unconstrained Association Loops.

Redundant Associations.

Equal Set Constraints.

Subset Constraints.

Constraints Capture Semantics.


9. Lifecycles.

Concept of a Lifecycle.

State Machine.

Example Class with a State Machine.





State Transition Table.

Basics of the State Transition Table.

Discovering New Transitions.

Discovering New States and Events.

Event Ignored and Can't Happen.

Creating and Deleting Objects.

Initial Pseudostates.

Final Pseudostates.

Forming Lifecycles.

Lifecycles for Classes.


10. Communicating Objects.


Sending Signals.

Event Parameters.

Signals with Parameters.

Signals to Self.

Signals to External Entities.

Creating and Deleting Objects.

Asynchronous Creation and Deletion.

Synchronous Creation and Deletion.

Visualizing Domain Dynamics.

Collaboration Diagrams.

Concept of a Execution Trace.

Sequencing Signals on a Collaboration Diagram.

Sequence Diagram.


Domain Dynamics.

11. Synchronizing Objects.

How to Think about Time.

Rules about Signals.

Rules about Procedures.

Rules about Data Access.

Delayed Signals and Time Events.

Rules, Rules, Rules.


12. Using Lifecycles.

Statechart Diagram Construction Techniques.

Modeling Intention.

Modeling Progression.

Simultaneous Signals.

Distinct Signals.

Reworking the Class Diagram.

Refactoring Behavior.

Saving Signals in Data.


13. Relationship Dynamics.

Dynamically Simple Associations.

Associations without Explicit Lifecycles.

Dynamic Associations with Association Classes.

Associations Involving Competition.

Competition in the Domain.

Competition in the Models.

An Example.

Multi-Instance Contention.

Object Selection and Selection Policies.

Dynamics in Generalization Hierarchies.

Superclass State Machines.

Subclass State Machines.

Polymorphic Events and Polymorphic Signals.


Superclass State Machine.

Subclass State Machines with Reclassification.


14. Domain Dynamics.

Partitioning Control.

Control Strategies.

Push and Pull Control.

The Pivot Point

Finding the Pivot.

Delegation of Control.

Hierarchical Delegation.

Networked Delegation.

Distributing Control in Associations.

Input Conditioning.

Input Sequencing.

Distributing the Inputs.

Distributed Dynamics.


15. Domain Verification.

Finding Unit Tests for a Single Use Case.

Test Execution.

System Tests.

Finding Test Cases from the Models.

The Verification Gap.


16. Model Management.

Dividing Large Domains.

Subsystems and the Class Diagram.

Collaborations between Subsystems.

Adjusting Subsystem Partitioning.

Model Management.

17. Joining Multiple Domains.

Kinds of Domains.

Application User Interface.

Generic Service Domains.

Realized Domains.

Anonymous Explicit Bridges.

External Entities.

Signals from External Entities.

Signals to External Entities.

Bridge Operations.

Synchronous or Asynchronous Bridging?

Implicit Bridging with Join Points.

Rationale for Join Points.

Class-Class Joins.

Class-Instance Joins.

Bridging to the Model Compiler.

18. Model Compilers.

Compiling the Models: The Bookstore.



Archetype Language.

Model Compilers and the Software Platform.


Buying, Modifying, and Building a Model Compiler.

Modeling the Model Compiler as a Domain.


Appendix A. Glossary.

Appendix B. Case Study.

Subsystem ProductSpecification.

Subsystem Ordering.

Subsystem Shipping.

Domain Data Types.

Object Collaboration Diagram.

Index. 0201748045T05022002


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 fully buzzword-compliant, nor is it as descriptive 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 sufficient 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 Questions

Is 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 is not the only possible one.

Is Executable UML a Standard?

Yes and No. The notational elements you'll 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 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 the underlying semantics quite closely to what is 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 nothing 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 definitions we use and the chapters that show how to build and execute models. Skip the notational stuff. Be prepared to unlearn some UML (and some habits of mind induced by UML) that is required to model software structure, but not required to specify an executable model.

What happened to model 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?

Executable UML and Shlaer-Mellor share common roots. Both focus on execution and specification of an abstract solution, not on specifying software structure. Executable UML uses UML notation, which makes execution concepts 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 language that conforms to the UML is a major step forward. We hope the action language, and the very concept of an executable and translatable UML may one day be seen as a significant contribution of the Shlaer-Mellor community.

And finally, progress in tools makes certain conventions, such as event numbering, less critical to model understanding, though they are still helpful in keeping our minds clear.

A complete list of correspondences and differences appears in Appendix E.

How can I get an Executable UML tool?

All of the examples in this book were developed using Project Technology's tool, BridgePoint. A copy of BridgePoint can be downloaded from our book's website, http://www.projtech.com/.

How is this differnt from the old "draw the pictures, get some code" CASE tools?

There are two main differences. First, compiling models produces the whole system, not just interfaces or frameworks. Secondly, 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 four million lines of C++, and as small as hand-held 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 attention 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.



Click below to download the Index file related to this title:


Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020