Designing Software Product Lines With UML

Designing Software Product Lines with UML ? From Use Cases to Pattern-Based Software Architectures Hassan Gomaa. 2005. Addison- Wesley (http://www.awprofessional.com). 701 pages. ISBN 0-201-77595- 6

CSQE Body of Knowledge areas: Software Engineering Processes

With 701 pages, Hassan Gomaa’s book Designing Software Product Lines with UML certainly deserves the term tome. Since I had just finished reading two books about agile methods, plowing through a UML-based book that focuses on software engineering with an emphasis on engineering was a major readjustment.

Gomaa opens the focus from the traditional development of single systems to the wide focus development of software product lines (SPLs). An SPL is a family of software systems that have aspects of both common and variable functionality. The emphasis across the product line is on software reuse, reusing architectures and not just components.

This is a sprawling book of 15 chapters. It is divided into three parts that combine many current methodologies, including: objectoriented programming, patterns applied to architecture, design components and idioms, many variations on modeling, and the support for these methods incorporated in UML.

The overall focus is what Gomaa calls product line UML-based software engineering (PLUS). PLUS is seen as implemented using the evolutionary software product line engineering process (ESPLEP)-a waterfall-like, evolutionary spiral development model integrated with a repository. After decoding, the whole thing reduces to something that could be handled in a shorter and perhaps clearer framework. The book reflects a tendency to try to synthesize things into a one-size-fits-all integrated development process using the many variants on computer-aided software engineering, which glommed together became the Unified Modeling Language (UML). Despite that it succeeds fairly well.

Part 1 presents an overview that sets the context of the book as a whole. The focus is on reuse and SPLs. The concept of SPLs is contrasted with that of single-system development. This larger venue presents a view that combines features that are common to the entire product line with optional features and alternatives that are mutually exclusive. Gomaa applies this view in a way I coined as the KOV analysis: Kernel that captures the common elements; options that describe extensions; and variants that capture alternatives that are generally mutually exclusive. These same three categories keep coming up in various guises, as use cases, features, architectures, components, and interfaces.

Part 2 is called "Requirements, Analysis, and Design Modeling for Software Product Lines." A shorter and more descriptive title, at least less unwieldy, might have just been "Modeling." It constitutes the main body of the book, chapters 4 through 12, and covers all the basic methodologies that jointly go into the PLUS approach. The modeling approaches are distributed across the requirements, analysis, design, and elaboration spectrum and each is compactly described.

Part 3 brings the earlier parts together in three case studies. Chapter 13 studies a microwave oven product line, chapter 14 studies an electronic commerce software product line, and chapter 15 presents a study of a factory automation software product line.

UML is used throughout. Those not familiar with UML will find a brief overview in appendix A and a nice catalog of software architectural patterns in appendix B. A glossary, a bibliography, and an index round out the book.

The people who would benefit most from reading this book are probably those who are the least likely to read it. There continues to be a war for the hearts and minds of software developers between those advocating lightweight agile models and those refining large- scale software methodologies on an engineering discipline-based conceptual framework. The two groups are both right and both wrong. Discipline is essential and largely neglected in agile frameworks despite the rhetoric to the contrary. Conversely, the software engineering methodologies seek to achieve what may be an unrealistic level of a priori rigor. Designing Software Product Lines with UML leaves out a lot of the human dimension, but presents a good snapshot of current models of software engineering. I think it is a reference book worth having, especially if one is committed to rigor in software engineering. Agile developers might want to adapt these ideas to their own frame of reference.

Reviewed by Ray Schneider

rschneid@bridgewater.edu

Copyright American Society for Quality Sep 2005