MDA Distilled Principles of Model-Driven Architecture | Date: 19 January 2011, 08:21
|
In 2000, the Object Management Group (OMG) published "Model Driven Architecture" (OMG 2000), a white paper that described a vision for software development that relied on linking object models together to build complete systems. This model-driven architecture (MDA) approach would employ existing technologies that support existing and future OMG standards, and thereby support model-driven development so that object models would become assets instead of expenses. Today, however, models are precisely that: They're expenses. Once a model has been built, it must be transformed into code, and this is a tedious, error-prone, and above all, expensive process. Furthermore, once the interesting abstraction work has been done, only the transformation from code to an executable is automated. Once again, we find that the cobblers' children have no shoes. MDA is the result of the recognition that interoperability is a Good Thing and that modeling is a Good Thing, too. MDA allows developers to build models without knowledge of other models in the system and then combine those models only at the last minute to create the system. This prevents design decisions from becoming intertwined with the application; it also renders the application independent of its implementation so the application can be recombined with other technologies, as well as other application subject matters, at some later time. This is a kind of design-time interoperability of models; the result is that models become assets. Does this sound too good to be true? Possibly. However, MDA doesn't require a one-step leap from a code-driven process to one driven by modeling. Instead, it offers features that allow the progressive adoption of the technology. You'll likely find that some of the technologies are in place in your organization already--MDA simply fits them together and organizes them into a coherent whole. This book describes the current state of the art in MDA. It's targeted to developers and their managers who want to understand more fully what MDA is, and how it might affect their development activities and their organization. It's not intended to describe all of the nitty-gritty detail of MDA. Organization of This Book Chapter 1, Introduction, provides a high-level overview of MDA in terms of how it's aimed at raising the levels of abstraction and reuse. It also discusses design-time interoperability, which ties these ideas together into a greater whole, and the concept of models as assets. Chapter 2, MDA Terms and Concepts, offers introductory definitions of the various acronyms and terms at the heart of MDA. It also provides a road map for the rest of the book. Chapter 3, Building Models, explains why modeling systems is important, describes the key aspects of good models, and discusses the important concepts of abstraction, classification, and generalization. This chapter also introduces a banking system example that will run throughout the book and provides initial definitions of the terms platform-independent model (PIM) and platform-specific model (PSM). Chapter 4, Building Metamodels, focuses on the core concepts of metamodels, which are models of modeling languages. This chapter explores the Meta-Object Facility (MOF), which is the OMG's adopted standard for metamodeling. This chapter also expands the discussion of the banking system to show the relationship between elements of the basic model and the elements of the Unified Modeling Language (UML) metamodel. Chapter 5, Building Mappings, describes the need for mappings between models and describes some mapping functions that might apply in connection with transforming an "analysis" model to a "design" model. It also discusses various types of "horizontal" and "vertical" mappings and issues associated with merging mappings. Chapter 6, Building Marking Models, discusses marks, which are nonintrusive extensions to models and metamodels that capture necessary information without polluting them. In particular, the focus is on what marks are good for and how to find them for a given mapping function. This chapter also defines the concept of marking models, which serve as adapters between metamodels. Chapter 7, Building Languages, describes how to use a metamodel to define a language for the purposes of improving communication among team members and with machines. This discussion includes an exploration of two different approaches to building languages, one of which involves the MOF and the other of which involves UML profiles. Chapter 8, Elaborating Models, addresses the idea that a model can be modified after it has been generated. This includes three topics that support MDA's open-minded attitude: managing manual changes to target models, reversibility of mappings, and, most important of all, legacy code. Chapter 9, Building Executable Models, describes the principles behind models that have everything required to produce the desired functionality of a single domain. These models confer independence from the software platform, which makes them portable across multiple development environments. The chapter also discusses Executable UML, a profile of UML that defines an execution semantics for a carefully selected streamlined subset of UML. Chapter 10, Agile MDA, discusses an approach to MDA that involves linking models together rather than transforming them, and then mapping all of these models to a single combined model that is subsequently translated into code according to a single system architecture. This approach relies on the Executable UML profile discussed in Chapter 9. Chapter 11, Building an MDA Process, describes how to select models, mapping functions, and marking models so they fit together into a process suitable for MDA development. Topics include charting the MDA process, identifying models, identifying metamodels and marking models, and constraint propagation. Chapter 12, Executing an MDA Process, discusses how a model-driven development process works in terms of the key activities and their interdependencies. The discussion includes descriptions of the high-level activities required for conducting any model-driven process, the issues involved in defining a specific process for a project in the presence of multiple platforms and then how to go about it, and how to implement the process and test the resulting system. Chapter 13, The Future of MDA, describes the authors' views of the most likely directions in which the OMG will take MDA. The book also includes a glossary, which contains definitions for all of the terms introduced in the body of the text; a bibliography; and an index. Frequently Asked Questions What is MDA? MDA is actually three things: An OMG initiative to develop standards based on the idea that modeling is a better foundation for developing and maintaining systems A brand for standards and products that adhere to those standards A set of technologies and techniques associated with those standards What are these technologies and techniques? There are many. The most well-known is probably the UML, which people use to capture abstract semantics models as well as the software structure of object systems. Others include the following: The MOF, a metamodel and modeling language for describing metamodels (don't panic--we'll explain each of these terms later in the book) Mapping functions Marking models Executable models It's the job of this book to explain each of these concepts and--most importantly--how they relate to one another. Is that all? No. At present, MDA is still in development, and some of the technologies need to be developed further and standardized, while others need further definition. If they're not defined, what good are they? The ideas behind MDA have been around for years; they're only just now in the process of formalization and standardization. For example, people have been building executable models, generating code, and refining and transforming models for some years now, and gaining significant benefits from doing so. It takes a long time to build standards. Should I wait? No. Much of the technology has been around for a while, and you may even have been using it. It also takes time to bring a new technology into an organization, and in any case, you can do so progressively. What is the purpose of this book? As the title indicates, it's a "distilled" discussion of MDA. We think it's the book you have to have to help you understand MDA and not be caught out by your colleagues. What does the book do? It explains what MDA is, what makes it up, what each of the relevant technologies and tools is, and what their importance is in the larger context of MDA. In so doing, we also explain the benefits. Who are the people that should read this book? Developers who are trying to get ahead of the crashing MDA wave. I'm a manager. Should I read this book? If you need to understand how the benefits of MDA derive from the associated technologies and tools, this is the book for you. We explain technologies and tools so you can understand the benefit, but we don't just tell you why something is important--we also explain the technology. What do I need to know to read this book? Nothing, except an acquaintance with UML. I know all about MOF and UML. Do I need this book? Yes, if you want to know how UML and the rest fit into the larger picture. MDA relies on these technologies and takes them forward a step. We also identify those parts of these technologies that don't apply to MDA. I'm in real-time. Does this book apply to me? The principles behind MDA apply to software development in general; they aren't specific to a certain kind of software. The ideas described here apply equally to real-time and regular IT systems; some of them, such as Executable and Translatable UML, were developed first for real-time systems.
|
DISCLAIMER:
This site does not store MDA Distilled Principles of Model-Driven Architecture on its server. We only index and link to MDA Distilled Principles of Model-Driven Architecture provided by other sites. Please contact the content providers to delete MDA Distilled Principles of Model-Driven Architecture if any and email us, we'll remove relevant links or contents immediately.
|
 |
|
Comments (0)
All
