Home > Store

Multi-Paradigm Design for C++

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

Multi-Paradigm Design for C++

Book

  • Sorry, this book is no longer in print.
Not for Sale

Description

  • Copyright 1999
  • Dimensions: 7-3/8" x 9-1/4"
  • Pages: 304
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-82467-1
  • ISBN-13: 978-0-201-82467-4

C++ is a programming language that supports multiple paradigms: classes, overloaded functions, templates, modules, procedural programming, and more. Despite the language's flexibility and richness, however, there has previously been little effort to create a design method that supports the use of multiple paradigms within a single application.

This book presents a coherent framework for approaching multi-paradigm design, offering an advanced set of design practices that form the foundation for a formal multi-paradigm design method.

Multi-Paradigm Design for C++ offers insight into an analysis and design process that takes advantage of C++'s multiple paradigm capability. It uses understandable notation and readable explanations to help all C++ programmers--not just system architects and designers--combine multiple paradigms in their application development for more effective, efficient, portable, robust, and reusable software.

Readers will gain an understanding of domain engineering methods that support multi-paradigm design. This book reveals how to analyze the application domain, using principles of commonality and variation, to define subdomains according to the most appropriate paradigm for each. Multi-paradigm design digs deeper than any single technology or technique to address fundamental questions of software abstraction and design.

All of the concepts and techniques that form the groundwork for domain engineering are presented. These concepts include an in-depth look at commonality and variability analysis, how domain engineering interacts with commonly used design patterns, how to find abstractions in the application domain, and how the principles of domain engineering can be used as a basis for the abstraction techniques of the object paradigm. Most important, this book discusses how to apply analysis techniques that are the most appropriate paradigm to be implemented during the design phase.



0201824671B04062001

Extras

Web Resources

Click below for Web Resources related to this title:
Author's Web Site

Sample Content

Table of Contents



Preface.


1. Introduction: The Need for Multiple Paradigms.

Domain Engineering and Multiple Paradigms.

Design, Analysis, Domains, and Families: Term Definitions.

Beyond Objects.

Commonality and Variability Analysis.

Software Families.

Multi-Paradigm Design.

Multi-Paradigm Development and Programming Language.

Commonality Analysis: Other Perspectives.

Summary.



2. Commonality Analysis.

Commonality: The Essence of Abstraction.

Priming Analysis: The Domain Vocabulary.

Dimensions of Commonality and Commonality Categories.

Examples of Commonality.

Reviewing the Commonality Analysis.

Commonality and Evolution.

Summary.



3. Variability Analysis.

Variability: The Spice of Life.

The Commonality Base.

Positive and Negative Variability.

The Domain and Range of Variability.

Binding Time.

Defaults.

Variability Tables.

Some Variability Traps.

Reviewing the Variability Analysis.

Variability Dependency Graphs.

Summary.



4. Application Domain Analysis.

Analysis, Domain Analysis, and Beyond.

Subdomains within a Domain Analysis.

The Structure of a Subdomain.

Analysis: The Big Picture.

Summary.



5. Object-Oriented Analysis.

About Paradigms and Objects.

Object-Oriented Commonality Analysis.

Summary.



6. Solution Domain Analysis.

The "Other" Domain.

The C++ Solution Domain: An Overview.

Data.

Overloading.

Class Templates.

Function Templates.

Inheritance.

Virtual Functions.

Commonality Analysis and Polymorphism.

Preprocessor Directives.

Negative Variability.

A Summary of the C++ Solution Domain: A Family Table.



7. Simple Mixing of Paradigms.

Putting It All Together: An Overview of Multi-Paradigm Design.

Activities of Multi-Paradigm Design.

Example: A Simple Language Translator.

Design, Not Analysis.

Another Example: Automatic Differentiation.

Outboard Paradigms.

Management Issues.

Summary.



8. Weaving Paradigms Together.

Method and Design.

Commonality Analysis: What Dimension of Commonality?

Multiple Paradigms: Multiple Dimensions of Variability in One Set of Commonalities

Codependent Domains.

Design and Structure.

Another Example: A Finite-State Machine.

Pattern-Based Solution Strategies.

Summary.



9. Augmenting the Solution Domain with Patterns.

The Value of Idioms and Patterns.

Commonality and Variability in Common Patterns.

Patterns of Negative Variability.

Multi-Paradigm Tools as a Patterns Adjunct.

Summary.



References.


Index. 0201824671T04062001

Preface

I have rarely invested as much energy in any endeavor as in naming this book. As the manuscript evolved, its title evolved to emphasize one or two concepts at any given time from the set of basic elements Domain, Engineering, Multi-Paradigm, Analysis, Design, Programming, and C++. The publisher was afraid that the unfamiliar term "domain engineering" would fail to engage the target market. One of the reviewers, Tim Budd, was concerned about confusion between his use of "multi-paradigm" and the way the term is used in this book. I was concerned about using terms such as "analysis" because of my desire to put the book into the hands of everyday programmers, whose problems it strives to address. Tim Budd graciously offered that our discipline is diverse enough to accommodate a broad spectrum of definitions for "multi-paradigm," and I insisted on a title that emphasized the role of the programmer and not that of the methodologist. That led to a happy convergence on the current title, Multi-Paradigm Design for C++.

I never considered titles containing the words pattern, object, CORBA, component, or Java. Multi-paradigm design tries to dig deeper than any single technology or technique to address fundamental questions of software abstraction and design. What is a paradigm? What is the relationship between analysis, design, and implementation? These questions go to the foundations of abstraction that underlie the basic paradigms of programming.

One of the most basic questions is, what is abstraction? Abstraction is one of the key tools of software design; it is necessary for managing the immense and ever-growing complexity of computer systems. The common answer to this question usually has something to do with objects, thereby reflecting the large body of literature and tools that have emerged over the past decade or two to support object-oriented techniques. But this response ignores common design structures that programmers use every day and that are not object-oriented: templates, families of overloaded functions, modules, generic functions, and others. Such use is particularly common in the C++ community, though it is by no means unique to that community.

There are principles of abstraction common to all of these techniques. Each technique is a different way of grouping abstractions according to properties they share, including regularities in the way individual entities vary from each other. To some, commonality captures the recurring external properties of a system that are germane to its domain. To others, commonality helps regularize implicit structure that analysis uncovers in the recurring solutions for a domain. Multi-paradigm design honors both perspectives. For example, the technique called object-oriented design groups objects into classes that characterize the common structure and behaviors of those objects. It groups classes into hierarchies or graphs that reflect commonality in structure and behavior, while at the same time allowing for regular variations in structure and in the algorithms that implement a given behavior. One can describe templates using a different characterization of commonality and variation. Commonality and variation provide a broad, simple model of abstraction, broader than objects and classes and broad enough to handle most design and programming techniques.

Commonality and variation aren't new to software design models. Parnas's concept of software families Parnas1976 goes back at least two decades. Families are collections of software elements related by their commonalities, with individual family members differentiated by their variations. The design ideas that have emerged from software families have often found expression in widely accepted programming languages; good examples are modules, classes and objects, and generic constructs. The work of Lai and Weiss on environments for application-specific languages takes this idea to its limits Weiss1999. The so-called analysis activities that focus on the discovery of software families and the so-called coding activities that focus on how to express these abstractions have always been closely intertwined. Multi-paradigm design explicitly recognizes the close tie between language, design, and domain structure and the way they express commonality and variation.

We discover software families in an activity called domain analysis, which is another field with a long history Neighbors1980. Software reuse was the original goal of domain analysis, and this goal fits nicely with software families. Multi-paradigm design explicitly focuses on issues that are important for reuse. To help the designer think about adapting software to a spectrum of anticipated markets, multi-paradigm design explicitly separates commonalities--assumptions that don't change--from variabilities--assumptions that do change. We strive for domain analysis, not just analysis. We design families of abstractions, not just abstractions. Done well, this approach to design leads in the long term to easier maintenance (if we predict the variabilities well) and to a more resilient architecture (we don't have to dig up the foundations every time we make a change). Of course, multi-paradigm development is just one tool that helps support the technical end of reuse. Effective reuse can happen only in the larger context of organizational issues, marketing issues, and software economics.

We use these foundations of commonality and variation to formalize the concept of paradigm. A paradigm, as the term is popularly used in contemporary software design, is a way of organizing system abstractions around properties of commonality and variation. The object paradigm organizes systems around abstractions based on commonality in structure and behavior and variation in structure and algorithm. The template paradigm is based on structural commonality across family members, with variations explicitly factored out into template parameters. Overloaded functions form families whose members share the same name and semantics, and in which each family member is differentiated by its formal parameter types.

C++ is a programming language that supports multiple paradigms: classes, overloaded functions, templates, modules, ordinary procedural programming, and others. Bjarne Stroustrup, the creator of C++, intended it that way. Most programmers use the C++ features that go beyond objects (though some abuse them to excess and others force designs into an object-oriented mold when they should be using more natural expressions of design provided by other language features). The powerful template code of John Barton and Lee Nackman Barton1994 is perhaps the height of tasteful multi-paradigm design.

Even though Stroustrup designated C++ as a multi-paradigm language, there have been no serious attempts to create a design method suited to the richness of C++ features. And though C++ provides a particularly rich and crisp example of multi-paradigm programming, the opportunity for multi-paradigm development generalizes to other programming languages. There is a gap between the current design literature and the intended use of C++ features that is reflected in current practice. This book bridges that gap, using simple notations and vocabulary to help developers combine multiple paradigms instructively.

During a lecture I gave at DePaul University in September 1995, the department chair, Dr. Helmut Epp, suggested the term meta-design for this work because its first concern is to identify design techniques suitable to the domain for which software is being developed. That is a useful perspective on the approach taken in this book and in fact describes how most developers approach design. One must first decide what paradigms to use; then one can apply the rules and tools of each paradigm for the system partitions well-suited to their use. This concern is the domain not only of the system architect and designer, but also of the everyday programmer.

Deciding what paradigm to use is one matter; having tools to express the abstractions of a given paradigm is another. We can analyze the application domain using principles of commonality and variation to divide it into subdomains, each of which may be suitable for design under a specific paradigm. This partitioning occurs during a development phase commonly called analysis. However, it is better thought of as an early phase of design because it tries to create abstractions that the implementation technology can express. Not all implementation tools (programming languages and other tools such as application generators) can express all paradigms. For this reason, it's important to do a domain analysis not only of the application domain, but also of the solution domain. Multi-paradigm design makes this an explicit activity. Solution domain analysis is another facet of the "meta-design" nature of multi-paradigm design.

There are many things this book is not. It is not a comprehensive design method, software development life cycle model, or turn-the-crank approach to design. Most good new designs are variants of old designs that have worked; it's rare that we face completely new or unique software problems. It would be inappropriate and a waste of time to apply the notations and techniques of this book to every module in a new system. But we should be armed to face new problems when they arise so that we can discover the structure in them and carry that understanding into design and implementation. Furthermore, the notations and techniques of multi-paradigm design provide a uniform way to document designs that augment object-oriented techniques with other paradigms.

Multi-paradigm design is a craft that is neither fully an art nor fully a rigorous discipline. This book presents notations, diagrams, and design models to support the developer's thought process. As is true with all such formalisms, there is always the temptation to get caught up in them for their own sake. Multi-paradigm design is a collection of activities that produce an architecture, and architecture is about relationships between pieces. But architecture is also about utility and aesthetics--properties of good software that elude most methods. Good taste has a key place here, and I don't intend the techniques to fuel automated design or coding. Good taste comes in part from experience and in part from good insight. For that reason, this isn't an entry-level book, either. Readers should have a year or two of experience using C++ doing object-oriented (at least) programming in a substantial system.

Used with common sense, these techniques complement good human judgment and experience. If you find that by applying these techniques, you arrive at a design you neither like nor understand, then don't use the design. The techniques are a tool, not a mandate. But all readers should take one thing away from this book: The object paradigm, or any other paradigm, is just one set of useful paradigms, and design must express structures more broadly than any single paradigm can.

The Book's Organization

Each chapter builds on the ones before it to build new concepts and increase the reader's understanding of domain engineering and multi-paradigm techniques. Most readers will read chapters sequentially and return to specific chapters as reference material.

Chapter 1 through 7 are the foundational chapters that lay the groundwork for domain engineering.

  • Chapter 1 introduces vocabulary, motivates the need for multi-paradigm design, and lays high-level foundations for domain engineering.
  • Chapter 2 and Chapter 3 cover commonality and variability analysis, respectively. The two concepts are used together in application, but each is presented in its own right both for simplicity of presentation and to emphasize its language subtleties. Chapter 3 introduces the central concepts of positive and negative variability, themes that are important to clean designs and to understanding how domain engineering interacts with commonly used design patterns.
  • Chapter 4 explains how to use domain analysis to find abstractions in the application domain; it builds on the techniques of the preceding chapters.
  • Chapter 5 demonstrates how the principles of domain engineering can be used as a basis for the abstraction techniques of the object paradigm.
  • Chapter 6 is an important chapter, both because it applies "analysis" techniques in an unconventional way--to characterize the solution domain--and because it places C++ constructs in a formal framework that form the basis of commonality and variability analysis.
  • Chapter 7 ties together all of the preceding chapters into a coherent framework for thinking about design. It introduces a taxonomy of design problems that have varying degrees of structural complexity. It also presents a high-level set of activities that guide good design and that could be the basis for a method based on domain engineering and multi-paradigm design techniques. The chapter deals with the simple case in which each domain can be developed largely independently of others in a single paradigm.
  • Chapter 8 goes a step further, investigating structurally complex designs in which simple divide-and-conquer techniques don't prevail. It presents examples of such recursive, structurally complex designs and presents heuristics for "breaking the recursion."
  • Chapter 9 is an addendum that shows the relationship between popular design patterns and domain engineering. The parallels will surprise many readers, and provide new insights into both patterns and domain engineering, as well as the relationship between them. Though the chapter isn't central to understanding domain engineering, it is crucial to understanding contemporary design practices that incorporate patterns together with objects and other paradigms, with or without domain engineering.

Class diagrams in the book follow the Unified Modeling Language (UML) notation Fowler+1997.

Acknowledgments

Many thanks to all of those who, through their dialogues, comments, and feedback, improved the quality of the manuscript. Just van den Broecke, Frank Buschmann, Paul Chisholm, Russell Corfman, David Cuka, Cay Horstman, Andrew Klein, Andrew Koenig, Stan Lippman, Tom Lyons, Lee Nackman, Brett Schuchert, Larry Schutte, Herb Sutter, Steve Vinoski, and David Weiss all provided review comments at many levels, from the highest level of conceptual murkiness to the smallest C++ detail. I appreciate them very much for their efforts. I also want to thank my tireless and patient editor, Debbie Lafferty, who also worked with me on my first book. She has been a true joy to work with. Special thanks also go to Jacquelyn Young, my production editor; to Laura Michaels, the book's copy editor; and to Kim Arney, the book's compositor. Discussions with Lalita Jagadeesan inspired me to create useful examples. A special thanks to Tom Stone, the acquisition editor, for his early advice to me and his early enthusiasm about this book inside Addison-Wesley. A special thanks to Andrew Klein for help with the UML diagrams. And last, a special thanks to my Bell Labs management and colleagues, especially to David Weiss, for sharing their work with me and providing support and encouragement.



0201824671P04062001

Updates

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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