I do a lot of work on large software projects. One area I work in a lot is helping to define and organize the requirements. This can be a difficult task for product line architectures.



Mr. Gomaa does an excellent job describing all of the implications of designing software product lines, including the managing of the requirements for such a project. There is also a lot of great information about architecting such a project (another area I frequently work in).



This book is one I keep on my professional bookshelf and refer to often. I have recommended it to many of my colleagues. I think anyone on a project team for software product lines can benefit from reading this book, whether the person is a requirements writer, architect, manager, or designer.

I do a lot of work on large software projects. One area I work in a lot is helping to define and organize the requirements. This can be a difficult task for product line architectures.

Mr. Gomaa does an excellent job describing all of the implications of designing software product lines, including the managing of the requirements for such a project. There is also a lot of great information about architecting such a project (another area I frequently work in).

This book is one I keep on my professional bookshelf and refer to often. I have recommended it to many of my colleagues. I think anyone on a project team for software product lines can benefit from reading this book, whether the person is a requirements writer, architect, manager, or designer.

This book is great for the UML syntax. The author does a great job of putting together a UML profile for Product Line Engineering modeling, and has great examples on how to use it.

But if you decide to read it beware that it excludes many of the Architectural practices that are found in the other resources. It does not use Attribute Driven Design, Cost-Benefit Analysis, or Architectural Tradeoff Analysis.

If you get it, keep that in mind. It is only good for an artifact creation reference, not the process behind arriving at the artifacts.

I would definitely recommend it for the UML profile it has and the examples the author provides.

This book is great for the UML syntax. The author does a great job of putting together a UML profile for Product Line Engineering modeling, and has great examples on how to use it.

But if you decide to read it beware that it excludes many of the Architectural practices that are found in the other resources. It does not use Attribute Driven Design, Cost-Benefit Analysis, or Architectural Tradeoff Analysis.

If you get it, keep that in mind. It is only good for an artifact creation reference, not the process behind arriving at the artifacts.

I would definitely recommend it for the UML profile it has and the examples the author provides.

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.

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.

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.

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.

It's still unclear to me how the software product lines in this book are distinguished simply from the products themselves. There is more emphasis on reuse and this appears to be the key distinguishing characteristic. But even with the book just focusing on a singly product this is a valuable work showing the use of techniques of Object Oriented Analysis and Design using UML. The book is a solid piece of work (both physically and in content), though there is a bias towards illustrations as opposed to explanatory text. Software architects should evaluate the book in person. Front line software engineers probably won't find much they can apply to their work.

It's still unclear to me how the software product lines in this book are distinguished simply from the products themselves. There is more emphasis on reuse and this appears to be the key distinguishing characteristic. But even with the book just focusing on a singly product this is a valuable work showing the use of techniques of Object Oriented Analysis and Design using UML. The book is a solid piece of work (both physically and in content), though there is a bias towards illustrations as opposed to explanatory text. Software architects should evaluate the book in person. Front line software engineers probably won't find much they can apply to their work.

This book brings together a good range of concepts for understanding software product lines and provides an organized method for developing product lines using object-oriented techniques with the UML. The text also includes a good selection of examples and case studies to illustrate the product line approach. I found this book to be well-balanced with respect to the needs of both experienced and novice software engineers.