Executable UML : a foundation for model-driven architecture /

Saved in:
Bibliographic Details
Author / Creator:Mellor, Stephen J.
Imprint:Boston : Addison-Wesley, c2002.
Description:xxxiv, 368 p. : ill. ; 25 cm.
Language:English
Series:The Addison-Wesley object technology series
Addison-Wesley object technology series.
Subject:
Format: Print Book
URL for this record:http://pi.lib.uchicago.edu/1001/cat/bib/4704445
Hidden Bibliographic Details
Other authors / contributors:Balcer, Marc.
ISBN:0201748045
Notes:Includes bibliographical references and index.
committed to retain 20170930 20421213 HathiTrust

At one time, the title for this book wasExecutable 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 onExecutable 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 b Excerpted from Executable UML: A Foundation for Model-Driven Architecture by Marc J. Balcer, Stephen J. Mellor All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.