ISBN:0201775956Book Description
Overview This book describes an evolutionary software engineering process for the development of software product lines, which uses the Unified Modeling Language (UML) notation. A software product line (or product family) consists of a family of software systems that have some common functionality and some variable functionality. The interest in software product lines emerged from the field of software reuse when developers and managers realized that they could obtain much greater reuse benefits by reusing software architectures instead of reusing individual software components. The field of software product lines is increasingly recognized in industry and government as being of great strategic importance for software development. Studies indicate that if three or more systems with a degree of common functionality are to be developed, then developing a product line is significantly more cost-effective than developing each system from scratch. The traditional mode of software development is to develop single systems-;that is, to develop each system individually. For software product lines, the development approach is broadened to consider a family of software systems. This approach involves analyzing what features (functional requirements) of the software family are common, what features are optional, and what features are alternatives. After the feature analysis, the goal is to design a software architecture for the product line, which has common components (required by all members of the family), optional components (required by only some members of the family), and variant components (different versions of which are required by different members of the family). Instead of starting from square one, the developer derives applications by adapting and tailoring the product line architecture. To model and design families of systems, the analysis and design concepts for single product systems need to be extended to support software product lines. This book is intended to appeal to readers who are familiar with modeling and designing single systems but who wish to extend their knowledge to modeling and designing software product lines. It is also intended to appeal to readers who are familiar with applying UML to the modeling and design of single systems but not with developing software product lines. What This Book Provides Several textbooks on the market describe object-oriented concepts and methods, which are intended for single systems. Very few books address software families or product lines; and of those that do, even fewer use UML. This book provides a comprehensive treatment of the application of UML-based object-oriented concepts to the analysis and design of software product lines. In particular, it does the following: Describes fundamental concepts and technologies in the design of software product lines. Describes, in considerable detail, a UML-based object-oriented analysis and design method for software product lines. It examines how each of the UML modeling views-;use case modeling, static modeling, dynamic state machine modeling, and dynamic interaction modeling-;is extended to address software product lines. Each UML modeling view is extended to reflect the commonality and variability of the product line. A new view, the feature modeling view, is added to explicitly model the commonality and variability of software requirements. Uses the Object Management Group (OMG) concept of model-driven architecture to develop a component-based software architecture for a product line. The product line architecture is expressed as a UML platform-independent model, which can then be mapped to a platform-specific model. Describes how architectures for software product lines are developed through the consideration of software architectural patterns in relation to the characteristics of the product line. The product line architecture is component-based and explicitly models the commonality and variability of the product line. Presents three case studies illustrating how a software product line architecture is developed, starting with use cases and feature modeling in the requirements modeling phase, static and dynamic modeling in the analysis modeling phase, and the development of the component-based software architecture in the design modeling phase. The case studies focus on a microwave oven product line, an electronic commerce product line, and a factory automation product line. Includes a glossary, a bibliography, and two appendices, which provide (1) an overview of UML 2 notation and (2) a catalog of software architectural patterns for product lines. The PLUS Advantage The UML-based software design method for software product lines described in this book is called PLUS ( P roduct L ine U ML-Based S oftware Engineering). The PLUS method extends the UML-based modeling methods that are used for single systems to address software product lines. With PLUS, the objective is to explicitly model the commonality and variability in a software product line. PLUS provides a set of concepts and techniques to extend UML-based design methods and processes for single systems to handle software product lines. In particular, for modeling software product lines, PLUS provides the following additions to the process of modeling single systems: Software Product Line Requirements Modeling Use case modeling. Model commonality and variability in the use case model. For this purpose, PLUS provides an approach to modeling kernel, optional, and alternative use cases, as well as an approach to modeling variation points in use cases. Feature modeling. Model product line features. Feature modeling is a key concept in software product lines. PLUS provides an approach for modeling common, optional, and alternative features, an approach for deriving the feature model from the use case model, and an approach for representing features with the UML notation. Software Product Line Analysis Modeling Static modeling. Develop a product line context model for the product line boundary. Determine kernel, optional, and alternative external classes. Develop a product line information (entity class) model: determine kernel, optional, and alternative entity classes. Dynamic interaction modeling. Develop interaction diagrams to realize kernel, optional, and alternative use cases. Use evolutionary development: the kernel first approach is applied to determine product line commonality, followed by product line evolution to determine variability. Dynamic state machine modeling. Develop kernel, optional, and alternative statecharts. Manage state machine variability through inheritance and parameterization. Feature/class dependency modeling. Determine how the common, optional, and alternative features of the product lines depend on the kernel, optional, and variant classes. Software Product Line Design Modeling Software architectural patterns. Determine the software architectural structure and communication patterns that are most appropriate for the product line given the catalog of architectural patterns. Component-based software design. Develop a component-based software design for the product line, which models kernel, optional, and variant components, as well as their ports and provided and required interfaces. Design the component-based architecture that explicitly models the components and their interconnections. Software Application Engineering Develop a software application that is a member of the product line by using the feature model to derive the application from the product line architecture and components. Intended Audience This book is intended for both professional and academic audiences. The professional audience includes analysts, software architects, software designers, programmers, project leaders, technical managers, program managers, and quality assurance specialists who are involved in the design and development of large-scale software product lines in industry and government. The academic audience includes senior undergraduate- and graduate-level students in computer science and software engineering, as well as researchers in the field. Ways to Read This Book This book may be read in various ways. It can be read in the order it is presented, in which case Chapters 1 and 2 provide introductory concepts, Chapter 3 provides an overview of product line engineering and the PLUS process, Chapters 4 through 12 provide an in-depth treatment of designing software product lines with PLUS, and Chapters 13, 14, and 15 provide detailed case studies. Alternatively, some readers may wish to skip some chapters depending on their level of familiarity with the topics discussed. Chapters 1 and 2 are introductory and may be skipped by experienced readers. Readers familiar with software design concepts may skip Chapter 2. Readers particularly interested in product line development can proceed directly to the description of PLUS, starting in Chapter 3. Readers who are not familiar with UML, or who are interested in finding out about the changes introduced by UML 2.0, can read the appropriate sections in Appendix A in conjunction with reading Chapters 4 through 12. Experienced product line designers may also use this book as a reference, referring to various chapters as their projects reach a particular stage of the requirements, analysis, or design process. Each chapter is relatively self-contained. For example, at different times you might refer to Chapter 4 for a description of use cases, Chapter 5 for developing the feature model, Chapter 7 for dynamic interaction modeling, Chapter 8 when designing statecharts (skip for non-state dependent product lines), Chapter 10 and Appendix B when referring to software architectural patterns, Chapter 11 for distributed component-based software design, and Chapter 12 for application engineering. You can also increase your understanding of how to use the PLUS method by reading the case studies, because each case study explains the decisions made at each step of the requirements, analysis, and design modeling processes. Annotated Table .../p>
Reviews From AMAZON.COM
An interesting contribution but does not solve the Problems
All,
There are many sources that if you are reading this you are probably aware of. UML is in my opinion a robust enough modeling environment to do pattern based software architectures at a macro level but this post is about taking UML a step farther to Domain Specific Software Factory type concepts, which this book dances around and I believe crosses over into territority that is quite dangerous for UML (and I am a huge fan of UML. I use it for Agile Modeling as well as early stage iteration design, but the UML is superceeded by Test Driven Development at development time).
As long as you stay at a rather low level of abstraction, UML is fine. However it semantically falls apart as the level of abstraction rises and you try to build very specific domain solutions (and abstraction we know will rise in the bext few months/years dramatically with the MDA initiative and Microsoft's Software Factories).
If you want to understand why UML runs out of gas as you move up in abstraction and get more specific in your domain, rather then rehash other's arguments, read the book "Software Factories" - Appendix B, by Steve Cook and Stuart Kent. It explains in detail why UML is a dead end for large scale, mass market software factories and model driven development. Alternatively, in my opinion, as long as you keep things technical and close to the 'classes, patterns, general purpose frameworks like logging, ORM, etc.' you are fine I believe.
The last paragraph says it all:
"In its role as the standard notation for documenting and communicating Object-Oriented concepts, UML 2 represents a useful incremental extension to UML 1. However, it remains poor at representing specific programming languages and platform technologies"....
There is much, much more. The above is copyright Wiley Publishing, Inc., Indianapolis, Indiana. 2004, ISBN: 0-471-20284-3 All Rights Reserved.
I strongly recommend you read the software factories book above to get an understanding and perhaps arrive at a different perspective then trying to 'make the UML shoe fit'.. Many seem to just do anything to go against Microsoft in a very unscientific way. Some people let emotions and false assumptions lead them astray from what is scientifically the right answer. I am asking you all now to think like a scientist and have an open mind to what is the best solution for a given problem. I'm not even saying this is wrong. Just far less correct and appropriate. Let your own investigation lead you to the answer, not marketing or what I have to say.
Good Text for Reusable Software Architecture
This book is a good text for software product lines. The approach to PLUS is well described with reasonable examples represented using UML notation, which make readers understand clearly the theoretical background of PLUS. This book can be used for a graduate course developing Reusable Software Architecture in terms of software product lines. In particular, it illustrates very well how reusable software architecture is specified from product line multiple-view models.