Slashdot Mirror

oblivious writes "I got this in e-mail this evening: According to a Reuters report that crossed the wires late today, the speculation is that Microsoft will make bids to buy both Rational and Borland. Shares of both Rational and Borland are up on the news, and so far both IBM and Microsoft have no comment on this report." We recently ran a story about IBMs planned purchase of Rational. Chris didn't make clear in here - it's not that Microsoft might buy both, but that Borland might be a likely target, if a bid to buy Rational out from under IBM fails, which it is likely too. Rational and IBM have signed the substantive portion of the agreement already, so any sort of counter bid would have some fun legal consequences for all involved.

An anonymous reader writes "Rational Software is going to be taken over by IBM. More info on Rational's website. RIP Rational. This is what rational is sending it's customers: To our valued customers: We are delighted to tell you that IBM and Rational Software have announced a definitive agreement for IBM to purchase Rational. This is a very exciting time for both companies and builds on the extensive business relationship IBM and Rational have had for over 20 years. Most importantly, it will provide significant benefits to you." Other readers submit links to the story in InformationWeek and the Mercury News.

BShive writes "Design Patterns is considered a classic for anyone in software development. The beginning third of the book is a solid introduction to patterns, while the last two thirds of the book is devoted to the patterns themselves. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about. The frequency of hearing about this text in discussions piqued my interest enough to buy it for myself. If you are interested in design patterns and are looking to use them, then this should be one of the books on your shelf." Read on for more. Design Patterns author Erich Gamma, et al pages 395 publisher Addison-Wesley rating 8 reviewer Ben Shive ISBN 0201633612 summary Design Patterns is considered a classic for anyone in software development. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about.

Introduction

I found the entire introductory section excellent, and a good read. It covers what design patterns are and explains how they are documented and categorized. Advice on where and how to employ design patterns to achieve reusable and flexible software is also covered to give you an expectation of what you can get out of the rest of the book. The What, Why, and How are covered nicely. Even with little previous exposure to patterns, I was able to understand the presented material easily and begin to see the applications.
Object Modeling Technique (OMT) notation is also introduced to explain the diagrams associated with the patterns and examples. If you have used UML, the diagrams and notations will be familiar to you since UML is influenced by OMT. Jim Rumbaugh, the creator of OMT, collaborated with Grady Booch to create the first version of UML.

As the author notes, having a solid knowledge of OOP is critical to being able to understand and use the information presented. If you don't fully understand OOP, pick up an introductory text first. An Introduction to Object-Oriented Programming by Timothy A. Budd or any similar book will get you up to speed. However, you will get the most out of Design Patterns with hands-on OOP experience.

Case Study

This chapter presents a case study in designing a WYSIWYG document editor to demonstrate how design patterns can be applied. Most of the examples in the book involve the user interface and I would have liked to see less emphasis on UI models. However, it still gives the reader insight into real applications of patterns. Not only do the authors point out how the pattern applies to each case, but they also present the problems associated with the application. The case study is not intended to set up a perfect example of pattern usage, but to explore it. The reader could go further with the design presented and think about how to solve the flaws pointed out along with the ones that have not been discussed. I liked the fact that they do not attempt to state that there is only one way to solve the problems presented, or that their solutions are even the best way. Too many authors fall into this trap.

Presenting: The Patterns

The three chapters on patterns make up the bulk of the book. The patterns are separated out into the three chapters by type: Creational, Structural, and Behavioral. Each chapter begins with an overview of what the patterns of the type can be used for, and how the chapter deals with the patterns as a group. At the end of each chapter there is a discussion section that summarizes the patterns, along with guidance on how to select the right one from the chapter.

Each pattern description contains a number of sections: Intent, Also Known As, Motivation, Applicability, Structure (in OMT), Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns. The breakdown makes it easy to determine if, why, and how you should use the pattern. The authors are justifiably concerned about using the wrong pattern for a given situation. The code snippets are also easy to work through as long as you know an OOP language. C++ is commonly used, with the occasional bit of Smalltalk code.

The three chapters that detail each pattern would be difficult to read right through. However, the opening and closing section of each chapter has valuable information and is worth reading and subsequently referring to some of the patterns discussed. I got the most out of these chapters by picking patterns that might apply to current projects I was working with and then exploring one in depth, branching over into other patterns in a non-linear fashion.

Conclusion

The closing chapter is relatively short, but makes some important points. The authors discuss what to expect from design patterns, some history and other references/influences. Re-factoring is discussed and how patterns will help mitigate this unavoidable process as the software evolves. Other benefits are also brought up briefly. The book closes with an invitation to give the authors feedback and to find patterns that you use. The best designs will use many design patterns that dovetail and intertwine to produce a greater whole.

Book Extras

The whole book has a quality feel to it that is missing from many current texts that cost nearly twice as much. Inside the front cover there is a quick reference to all of the patterns contained in the book with a brief description and page number. The back cover also contains a quick reference for diagram notation and the relationships between the design patters. This is all topped off by two bookmark ribbons attached to the spine.

The Age Issue

Design Patterns was originally published in 1995, and the book mentions that the patterns it contains are little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change. Despite this, since the material is not entirely dependent on a particular language or program it holds up quite well. The examples referred to for each pattern are older software that many will not recognize. An updated version would be nice, but being old does not condemn this book to being useless.

Summary

This is an excellent book even if it is beginning to show its age. The fact that it's still very useful is testimony to the quality of the material. A few readers might find the reading to be a bit dry, but the straightforward style was refreshing compared to some other texts. The authors stay focused on the topic and condense it appropriately without going off onto long tangents. Once I've followed through with applying some patterns to projects it might garner an even higher rating. Just from reading about some of the patterns, I could see how they could have applied to previous projects I've worked on, both large and small. The book was certainly a worthwhile investment. If a second version of this book ever comes out, I'd be sure to pick it up as well.

Chapters:
1. Introduction
2. A Case Study: Designing a Document Editor
3. Creational Patterns
4. Structural Patterns
5. Behavioral Patterns
6. Conclusion

Appendix:
A. Glossary
B. Guide to Notation
C. Foundation Classes

You can purchase Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

BShive writes "Design Patterns is considered a classic for anyone in software development. The beginning third of the book is a solid introduction to patterns, while the last two thirds of the book is devoted to the patterns themselves. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about. The frequency of hearing about this text in discussions piqued my interest enough to buy it for myself. If you are interested in design patterns and are looking to use them, then this should be one of the books on your shelf." Read on for more. Design Patterns author Erich Gamma, et al pages 395 publisher Addison-Wesley rating 8 reviewer Ben Shive ISBN 0201633612 summary Design Patterns is considered a classic for anyone in software development. Many of the professionals out there probably already own a well-used copy of this book, but there are others who are wondering what all the fuss is about.

Introduction

I found the entire introductory section excellent, and a good read. It covers what design patterns are and explains how they are documented and categorized. Advice on where and how to employ design patterns to achieve reusable and flexible software is also covered to give you an expectation of what you can get out of the rest of the book. The What, Why, and How are covered nicely. Even with little previous exposure to patterns, I was able to understand the presented material easily and begin to see the applications.
Object Modeling Technique (OMT) notation is also introduced to explain the diagrams associated with the patterns and examples. If you have used UML, the diagrams and notations will be familiar to you since UML is influenced by OMT. Jim Rumbaugh, the creator of OMT, collaborated with Grady Booch to create the first version of UML.

As the author notes, having a solid knowledge of OOP is critical to being able to understand and use the information presented. If you don't fully understand OOP, pick up an introductory text first. An Introduction to Object-Oriented Programming by Timothy A. Budd or any similar book will get you up to speed. However, you will get the most out of Design Patterns with hands-on OOP experience.

Case Study

This chapter presents a case study in designing a WYSIWYG document editor to demonstrate how design patterns can be applied. Most of the examples in the book involve the user interface and I would have liked to see less emphasis on UI models. However, it still gives the reader insight into real applications of patterns. Not only do the authors point out how the pattern applies to each case, but they also present the problems associated with the application. The case study is not intended to set up a perfect example of pattern usage, but to explore it. The reader could go further with the design presented and think about how to solve the flaws pointed out along with the ones that have not been discussed. I liked the fact that they do not attempt to state that there is only one way to solve the problems presented, or that their solutions are even the best way. Too many authors fall into this trap.

Presenting: The Patterns

The three chapters on patterns make up the bulk of the book. The patterns are separated out into the three chapters by type: Creational, Structural, and Behavioral. Each chapter begins with an overview of what the patterns of the type can be used for, and how the chapter deals with the patterns as a group. At the end of each chapter there is a discussion section that summarizes the patterns, along with guidance on how to select the right one from the chapter.

Each pattern description contains a number of sections: Intent, Also Known As, Motivation, Applicability, Structure (in OMT), Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns. The breakdown makes it easy to determine if, why, and how you should use the pattern. The authors are justifiably concerned about using the wrong pattern for a given situation. The code snippets are also easy to work through as long as you know an OOP language. C++ is commonly used, with the occasional bit of Smalltalk code.

The three chapters that detail each pattern would be difficult to read right through. However, the opening and closing section of each chapter has valuable information and is worth reading and subsequently referring to some of the patterns discussed. I got the most out of these chapters by picking patterns that might apply to current projects I was working with and then exploring one in depth, branching over into other patterns in a non-linear fashion.

Conclusion

The closing chapter is relatively short, but makes some important points. The authors discuss what to expect from design patterns, some history and other references/influences. Re-factoring is discussed and how patterns will help mitigate this unavoidable process as the software evolves. Other benefits are also brought up briefly. The book closes with an invitation to give the authors feedback and to find patterns that you use. The best designs will use many design patterns that dovetail and intertwine to produce a greater whole.

Book Extras

The whole book has a quality feel to it that is missing from many current texts that cost nearly twice as much. Inside the front cover there is a quick reference to all of the patterns contained in the book with a brief description and page number. The back cover also contains a quick reference for diagram notation and the relationships between the design patters. This is all topped off by two bookmark ribbons attached to the spine.

The Age Issue

Design Patterns was originally published in 1995, and the book mentions that the patterns it contains are little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change. Despite this, since the material is not entirely dependent on a particular language or program it holds up quite well. The examples referred to for each pattern are older software that many will not recognize. An updated version would be nice, but being old does not condemn this book to being useless.

Summary

This is an excellent book even if it is beginning to show its age. The fact that it's still very useful is testimony to the quality of the material. A few readers might find the reading to be a bit dry, but the straightforward style was refreshing compared to some other texts. The authors stay focused on the topic and condense it appropriately without going off onto long tangents. Once I've followed through with applying some patterns to projects it might garner an even higher rating. Just from reading about some of the patterns, I could see how they could have applied to previous projects I've worked on, both large and small. The book was certainly a worthwhile investment. If a second version of this book ever comes out, I'd be sure to pick it up as well.

Chapters:
1. Introduction
2. A Case Study: Designing a Document Editor
3. Creational Patterns
4. Structural Patterns
5. Behavioral Patterns
6. Conclusion

Appendix:
A. Glossary
B. Guide to Notation
C. Foundation Classes

You can purchase Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Mignon writes "Rational has released PurifyPlus for Linux. This could be a big step for commercial Linux development."

Mignon writes "Rational has released PurifyPlus for Linux. This could be a big step for commercial Linux development."

BShive writes "Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process. You do not need to know UML or OO Design, as both new and experienced Java developers will benefit from reading this book. It is highly focused on process, so developers will have to put aside the 'jump in and code' attitude." Read on below for the remainder of his review. Developing Applications with Java and UML author Paul R. Reed, Jr. pages 463 publisher Addison-Wesley rating 9 reviewer Ben Shive ISBN 0201702525 summary Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process.

Each chapter begins with a brief summary and a list of the goals. After reading the book through, both should be useful. Each chapter also closes with a 'checkpoint' that summarizes what has been covered in the chapter and what is to come.

The first chapter sets up the entire book by outlining some of the project problems encountered in software development. Once the author gets into development models, the Unified Process from Rational Software, a huge and detailed software process, is introduced. The book focuses on only using the elements that provide the biggest 'bang for the buck'. The Unified Process is the focal process of the book, but the Synergy Process is a free alternative, only lacking some additional guidelines and how-to's. A short overview of UML is covered, along with its' place is in the software process. He notes that a project that just uses UML in a vacuum without a sound process and plan will fail.

The second chapter briefly discusses the Java language alongside the concept of Object Oriented Programming. Experienced Java programmers could skip this section if they wished. The section is worth skimming as a lead-in to the explanation of how Java and UML are a good fit.

Chapter three, Starting the Project is the first time the book delves into the meat of how to structure a project. The example scenario that is followed through the book is introduced, and throughout the book real-world examples are used that relate to the sample project. Every theory in the book that is translated into some kind of example the reader can pull apart and examine.

Through the next few chapters use-cases and class diagrams are covered, leading up to building a user interface (UI) prototype. Personally, I've never used UML for anything but sculpting class diagrams for export. This is the point in the book where I started to see how the rest of the project is able to use UML and tie it all together. Being able to model the classes and easily export them is very powerful, but even more so when combined with the rest of the ways you can employ UML in your project.

The following chapters are much like the first few that began to talk about the sample project. There is no Java code until chapter 9, halfway through the book. This is not the book to get if you are only interested in how to use UML as a base to dump out some code.

Throughout the book the content remained interesting, and relevant. Do not expect to sit down and read it from beginning to end. There is a great deal of material covered and no topic that was inadequately explored. Using the sample project consistently throughout the process was invaluable, along with the samples and source code provided. Alongside the process, the real life anecdotes and comments provided were a welcome addition instead of an intrusion. The author is someone who's seen the mistakes that could be avoided. For example, an application with 70,000 lines of Java code that only contained two classes.

Having talked about the depth and detail of the book, this was also one of the bad points as well simply since it takes so long to get through. People already well experienced in running a project with similar phases will find it much faster reading. The other issue is the expense of the tools and products involved. Rational Rose, the Rational Unified Process and WebLogic are rather expensive products. Thankfully there are alternatives that he mentions in the book, and others as well. Visio, the Synergy Process and Tomcat are all possible alternates. Surprisingly, Tomcat is used in his example setup.

I had left the rating at 8 throughout most of my reading while considering the positives and negatives. However, when I finished the book I bumped the rating up to 9 simply because of the wealth of information I learned. Anyone aspiring to run a team project with Java should read this book. In the corporate arena, most of the battle is not the code, but understanding what the users want and what will be created. Following any kind of process will improve the result, even if only a few key elements are used.

Chapters:
1. The Project Dilemma
2. Java, Object-Oriented Analysis and Design, and UML
3. Starting the Project
4. Use-Cases
5. Classes
6. Building a User Interface Prototype
7. Dynamic Elements of the Application
8. The Technology Landscape
9. Data Persistence: Storing the Objects
10. Infrastructure and Architecture Review
11. Constructing a Solution: Servlets, JSP and JavaBeans
12. Constructing a Solution: Servlets, JSP and Enterprise JavaBeans

Appendix:
A. The Unified Project Plans
B. The Synergy Process Project Plan
C. Estimating Projects on the Basis of Use-Cases
D. Sample Project Output
E. BEA WebLogic Application Server

You can purchase Developing Applications with Java and UML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

BShive writes "Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process. You do not need to know UML or OO Design, as both new and experienced Java developers will benefit from reading this book. It is highly focused on process, so developers will have to put aside the 'jump in and code' attitude." Read on below for the remainder of his review. Developing Applications with Java and UML author Paul R. Reed, Jr. pages 463 publisher Addison-Wesley rating 9 reviewer Ben Shive ISBN 0201702525 summary Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process.

Each chapter begins with a brief summary and a list of the goals. After reading the book through, both should be useful. Each chapter also closes with a 'checkpoint' that summarizes what has been covered in the chapter and what is to come.

The first chapter sets up the entire book by outlining some of the project problems encountered in software development. Once the author gets into development models, the Unified Process from Rational Software, a huge and detailed software process, is introduced. The book focuses on only using the elements that provide the biggest 'bang for the buck'. The Unified Process is the focal process of the book, but the Synergy Process is a free alternative, only lacking some additional guidelines and how-to's. A short overview of UML is covered, along with its' place is in the software process. He notes that a project that just uses UML in a vacuum without a sound process and plan will fail.

The second chapter briefly discusses the Java language alongside the concept of Object Oriented Programming. Experienced Java programmers could skip this section if they wished. The section is worth skimming as a lead-in to the explanation of how Java and UML are a good fit.

Chapter three, Starting the Project is the first time the book delves into the meat of how to structure a project. The example scenario that is followed through the book is introduced, and throughout the book real-world examples are used that relate to the sample project. Every theory in the book that is translated into some kind of example the reader can pull apart and examine.

Through the next few chapters use-cases and class diagrams are covered, leading up to building a user interface (UI) prototype. Personally, I've never used UML for anything but sculpting class diagrams for export. This is the point in the book where I started to see how the rest of the project is able to use UML and tie it all together. Being able to model the classes and easily export them is very powerful, but even more so when combined with the rest of the ways you can employ UML in your project.

The following chapters are much like the first few that began to talk about the sample project. There is no Java code until chapter 9, halfway through the book. This is not the book to get if you are only interested in how to use UML as a base to dump out some code.

Throughout the book the content remained interesting, and relevant. Do not expect to sit down and read it from beginning to end. There is a great deal of material covered and no topic that was inadequately explored. Using the sample project consistently throughout the process was invaluable, along with the samples and source code provided. Alongside the process, the real life anecdotes and comments provided were a welcome addition instead of an intrusion. The author is someone who's seen the mistakes that could be avoided. For example, an application with 70,000 lines of Java code that only contained two classes.

Having talked about the depth and detail of the book, this was also one of the bad points as well simply since it takes so long to get through. People already well experienced in running a project with similar phases will find it much faster reading. The other issue is the expense of the tools and products involved. Rational Rose, the Rational Unified Process and WebLogic are rather expensive products. Thankfully there are alternatives that he mentions in the book, and others as well. Visio, the Synergy Process and Tomcat are all possible alternates. Surprisingly, Tomcat is used in his example setup.

I had left the rating at 8 throughout most of my reading while considering the positives and negatives. However, when I finished the book I bumped the rating up to 9 simply because of the wealth of information I learned. Anyone aspiring to run a team project with Java should read this book. In the corporate arena, most of the battle is not the code, but understanding what the users want and what will be created. Following any kind of process will improve the result, even if only a few key elements are used.

Chapters:
1. The Project Dilemma
2. Java, Object-Oriented Analysis and Design, and UML
3. Starting the Project
4. Use-Cases
5. Classes
6. Building a User Interface Prototype
7. Dynamic Elements of the Application
8. The Technology Landscape
9. Data Persistence: Storing the Objects
10. Infrastructure and Architecture Review
11. Constructing a Solution: Servlets, JSP and JavaBeans
12. Constructing a Solution: Servlets, JSP and Enterprise JavaBeans

Appendix:
A. The Unified Project Plans
B. The Synergy Process Project Plan
C. Estimating Projects on the Basis of Use-Cases
D. Sample Project Output
E. BEA WebLogic Application Server

You can purchase Developing Applications with Java and UML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

BShive writes "Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process. You do not need to know UML or OO Design, as both new and experienced Java developers will benefit from reading this book. It is highly focused on process, so developers will have to put aside the 'jump in and code' attitude." Read on below for the remainder of his review. Developing Applications with Java and UML author Paul R. Reed, Jr. pages 463 publisher Addison-Wesley rating 9 reviewer Ben Shive ISBN 0201702525 summary Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process.

Each chapter begins with a brief summary and a list of the goals. After reading the book through, both should be useful. Each chapter also closes with a 'checkpoint' that summarizes what has been covered in the chapter and what is to come.

The first chapter sets up the entire book by outlining some of the project problems encountered in software development. Once the author gets into development models, the Unified Process from Rational Software, a huge and detailed software process, is introduced. The book focuses on only using the elements that provide the biggest 'bang for the buck'. The Unified Process is the focal process of the book, but the Synergy Process is a free alternative, only lacking some additional guidelines and how-to's. A short overview of UML is covered, along with its' place is in the software process. He notes that a project that just uses UML in a vacuum without a sound process and plan will fail.

The second chapter briefly discusses the Java language alongside the concept of Object Oriented Programming. Experienced Java programmers could skip this section if they wished. The section is worth skimming as a lead-in to the explanation of how Java and UML are a good fit.

Chapter three, Starting the Project is the first time the book delves into the meat of how to structure a project. The example scenario that is followed through the book is introduced, and throughout the book real-world examples are used that relate to the sample project. Every theory in the book that is translated into some kind of example the reader can pull apart and examine.

Through the next few chapters use-cases and class diagrams are covered, leading up to building a user interface (UI) prototype. Personally, I've never used UML for anything but sculpting class diagrams for export. This is the point in the book where I started to see how the rest of the project is able to use UML and tie it all together. Being able to model the classes and easily export them is very powerful, but even more so when combined with the rest of the ways you can employ UML in your project.

The following chapters are much like the first few that began to talk about the sample project. There is no Java code until chapter 9, halfway through the book. This is not the book to get if you are only interested in how to use UML as a base to dump out some code.

Throughout the book the content remained interesting, and relevant. Do not expect to sit down and read it from beginning to end. There is a great deal of material covered and no topic that was inadequately explored. Using the sample project consistently throughout the process was invaluable, along with the samples and source code provided. Alongside the process, the real life anecdotes and comments provided were a welcome addition instead of an intrusion. The author is someone who's seen the mistakes that could be avoided. For example, an application with 70,000 lines of Java code that only contained two classes.

Having talked about the depth and detail of the book, this was also one of the bad points as well simply since it takes so long to get through. People already well experienced in running a project with similar phases will find it much faster reading. The other issue is the expense of the tools and products involved. Rational Rose, the Rational Unified Process and WebLogic are rather expensive products. Thankfully there are alternatives that he mentions in the book, and others as well. Visio, the Synergy Process and Tomcat are all possible alternates. Surprisingly, Tomcat is used in his example setup.

I had left the rating at 8 throughout most of my reading while considering the positives and negatives. However, when I finished the book I bumped the rating up to 9 simply because of the wealth of information I learned. Anyone aspiring to run a team project with Java should read this book. In the corporate arena, most of the battle is not the code, but understanding what the users want and what will be created. Following any kind of process will improve the result, even if only a few key elements are used.

Chapters:
1. The Project Dilemma
2. Java, Object-Oriented Analysis and Design, and UML
3. Starting the Project
4. Use-Cases
5. Classes
6. Building a User Interface Prototype
7. Dynamic Elements of the Application
8. The Technology Landscape
9. Data Persistence: Storing the Objects
10. Infrastructure and Architecture Review
11. Constructing a Solution: Servlets, JSP and JavaBeans
12. Constructing a Solution: Servlets, JSP and Enterprise JavaBeans

Appendix:
A. The Unified Project Plans
B. The Synergy Process Project Plan
C. Estimating Projects on the Basis of Use-Cases
D. Sample Project Output
E. BEA WebLogic Application Server

You can purchase Developing Applications with Java and UML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

BShive writes "Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process. You do not need to know UML or OO Design, as both new and experienced Java developers will benefit from reading this book. It is highly focused on process, so developers will have to put aside the 'jump in and code' attitude." Read on below for the remainder of his review. Developing Applications with Java and UML author Paul R. Reed, Jr. pages 463 publisher Addison-Wesley rating 9 reviewer Ben Shive ISBN 0201702525 summary Developing Applications with Java and UML focuses on building and modeling industrial-strength Java applications. The book takes you step-by-step through a product lifecycle and software process.

Each chapter begins with a brief summary and a list of the goals. After reading the book through, both should be useful. Each chapter also closes with a 'checkpoint' that summarizes what has been covered in the chapter and what is to come.

The first chapter sets up the entire book by outlining some of the project problems encountered in software development. Once the author gets into development models, the Unified Process from Rational Software, a huge and detailed software process, is introduced. The book focuses on only using the elements that provide the biggest 'bang for the buck'. The Unified Process is the focal process of the book, but the Synergy Process is a free alternative, only lacking some additional guidelines and how-to's. A short overview of UML is covered, along with its' place is in the software process. He notes that a project that just uses UML in a vacuum without a sound process and plan will fail.

The second chapter briefly discusses the Java language alongside the concept of Object Oriented Programming. Experienced Java programmers could skip this section if they wished. The section is worth skimming as a lead-in to the explanation of how Java and UML are a good fit.

Chapter three, Starting the Project is the first time the book delves into the meat of how to structure a project. The example scenario that is followed through the book is introduced, and throughout the book real-world examples are used that relate to the sample project. Every theory in the book that is translated into some kind of example the reader can pull apart and examine.

Through the next few chapters use-cases and class diagrams are covered, leading up to building a user interface (UI) prototype. Personally, I've never used UML for anything but sculpting class diagrams for export. This is the point in the book where I started to see how the rest of the project is able to use UML and tie it all together. Being able to model the classes and easily export them is very powerful, but even more so when combined with the rest of the ways you can employ UML in your project.

The following chapters are much like the first few that began to talk about the sample project. There is no Java code until chapter 9, halfway through the book. This is not the book to get if you are only interested in how to use UML as a base to dump out some code.

Throughout the book the content remained interesting, and relevant. Do not expect to sit down and read it from beginning to end. There is a great deal of material covered and no topic that was inadequately explored. Using the sample project consistently throughout the process was invaluable, along with the samples and source code provided. Alongside the process, the real life anecdotes and comments provided were a welcome addition instead of an intrusion. The author is someone who's seen the mistakes that could be avoided. For example, an application with 70,000 lines of Java code that only contained two classes.

Having talked about the depth and detail of the book, this was also one of the bad points as well simply since it takes so long to get through. People already well experienced in running a project with similar phases will find it much faster reading. The other issue is the expense of the tools and products involved. Rational Rose, the Rational Unified Process and WebLogic are rather expensive products. Thankfully there are alternatives that he mentions in the book, and others as well. Visio, the Synergy Process and Tomcat are all possible alternates. Surprisingly, Tomcat is used in his example setup.

I had left the rating at 8 throughout most of my reading while considering the positives and negatives. However, when I finished the book I bumped the rating up to 9 simply because of the wealth of information I learned. Anyone aspiring to run a team project with Java should read this book. In the corporate arena, most of the battle is not the code, but understanding what the users want and what will be created. Following any kind of process will improve the result, even if only a few key elements are used.

Chapters:
1. The Project Dilemma
2. Java, Object-Oriented Analysis and Design, and UML
3. Starting the Project
4. Use-Cases
5. Classes
6. Building a User Interface Prototype
7. Dynamic Elements of the Application
8. The Technology Landscape
9. Data Persistence: Storing the Objects
10. Infrastructure and Architecture Review
11. Constructing a Solution: Servlets, JSP and JavaBeans
12. Constructing a Solution: Servlets, JSP and Enterprise JavaBeans

Appendix:
A. The Unified Project Plans
B. The Synergy Process Project Plan
C. Estimating Projects on the Basis of Use-Cases
D. Sample Project Output
E. BEA WebLogic Application Server

You can purchase Developing Applications with Java and UML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

testYourGUIS asks: "I work with a company that tests consumer and business software for various venues. One of the programs we rely on heavily is called Rational Visual Test, which is a VB-like compiled programming language that works directly with Windows API to simulate mouse clicks, text entry, menu pulldowns, and so on. We use them to stress-test various applications, collect the results, and then send the vendors a spreadsheet showing what we found. Recently, pressure has started to produce the same results on Mac OS X and possibly Linux applications. I was wondering if anyone knew of such software that works on Mac OS X, and how to go about doing this for Linux?"

"For example, a vendor has a database interface, and wants to know how many times we can access a series of records, what the results show (are the right, blank, time out?), and how long it took for the search to take place during various times of the day, and so on. So we emulate one of their data entry people by logging onto the system, putting in some search parameter from a script, and then record what the text (or error message) was when it came back. Yes, we could connect directly to the SQL database without their front end, but it's the combination of their front end and the database we usually test. We have found many examples where were can connect raw, for instance, but the front end displays a timeout. We also test things like 'What happens if the user enters a colon or asterisk?' or 'What if the text entered in the box is over 256k?' Then we tell the vendor the results, and they hopefully fix them based on the data we gave them."

roarl asks: "Is anyone working on an Open Source bounds checking system? (A system that checks a program at runtime for array out of bounds access, reading uninitialized memory, memory leaks and so on). I've been using BoundsChecker for some time and believe me, there are situations where you know you are going to spend hours debugging unless you let BoundsChecker sort it out for you. But it annoys me that I have to transfer (and sometimes port) the buggy program to Windows each time. I'd much rather stay in Linux. Insure works on Linux. I haven't tried Insure for some time, but last time I tried I wasn't especially impressed. Purify seems still not to support Linux, but on other Unix platforms it works great. The problem with all of these products is that they are so da*n expensive. So it makes me wonder, are all Open Source programmers doing without them? If so, what can we expect of the quality of Open Source developed programs? If not, is there a free alternative?"

An Anonymous Coward queries: "I work on a fairly large-sized project with at least a dozen developers. Advanced tools like CVS and ClearCase allow concurrent development, and provide merging tools to merge in different changes to the same file. This can be a significant productivity gain, particularly with files that are unavoidably common to several developers (C header files, most notoriously). During crunch times, such as before delivery deadlines, we often find that we are checking in changes to the same file several times a day, often hourly. The problem does not seem to be with conflicting changes to the same lines of code, but rather with developers knowing the sequence in which concurrent changes will be checked in. It is not possible to always be aware of who is checking in what and when, so programmers submitting patches to the baseline often have to redo those patches multiple times in a day in order to have them applied. Have other programming projects developed solutions for dealing with this problem?" The submitter proposes another solution, below, how well would it work?

"Take, for example, the extreme case of something like Linux (not only concurrent development, but geographically distributed development), how is this managed? One solution we were contemplating was to try to do an 'air traffic control' type of sequencing and conflict resolution. As early as possible in the development stage, we try to identify what will be finished when, and assign a one-up sequence number to each patch. Developers then know that they will be patching against the baseline that was patched by the patch with the previous sequence number. It is hoped that this prevents a lot of rework of patches. A potential problem with this approach is the need for a responsive central authority to assign sequence numbers. Also, such sequence numbers may have to be rearranged in the face of last minute advances and setbacks in developer progress. Despite careful scheduling and detailed design, it may be impossible to know the exact check-in sequence of patches more than a week or two in advance.

Will such an idea be successful, or is it fatally flawed? Are there better solutions to the problem with less effort? Are we treating symptoms and not the disease (i.e., should we be planning better so that we know patch sequences and dependencies early on)? Management likes to keep staff productively occupied and working up until deadlines, so this usually means a lot of checkins within a short period of time, rather than staged checkins. Can checkins be spread out over time while keeping developers productively occupied?"

rotifer asks: "A while ago I saw Kent Beck talk at the Java user's group meeting here in Seattle. Someone asked him about UML. He made a derisive noise and sneered that he had come up with a better version called GML, Galactic Modeling Language. He said (and I am paraphrasing here) that GML had three components "Boxes, Arrows and Arrows Pointing to Boxes". I thought this was right on. That seemed to be all the object modeling a person would need, especially when compared to the 808 pages of obtuse documentation that make up UML. But am I missing something here. Do people find UML useful. Or is it just overblown hype? Do you need this fully featured language to design an O-O system? Or are you better off with just boxes and arrows? Also, if you were to teach programming to beginning Java and C++ developers, is it a good idea to start with a course in UML so that new programmers can become familiar with O-O methodology before they start to cut code?"

PimpBot writes: "I'm taking a class in software engineering. To model our project, we're using UML, but I'm running into a problem - the software we're using, TogetherJ, is written in Java. The program has obscene memory requirements (128MB RAM min, 512 recommended), and being a poor college student, my box isn't close to supporting that. Are there any UML modeling clients out there that are dirt cheap, and don't use Java?"

briany asks: "I have been asked to evaluate Clearcase vs. CVS. I am wondering what kind of experiences people have had (good and bad) with either product, or if there are other products that should be considered. The projects that will be stored are rather large (10+ GB) and need to be accessible from Solaris, Linux, and NT/Win2k." Of course, it should be mentioned that Clearcase is available for Linux, as well as other unix clones.

SEGV has returned and is continuing his excellent set of reviews. This time around, we're looking at Martin Fowler's (with Kent Beck, John Brant, William Opdyke, and Don Roberts) Refactoring: Improving the Design of Existing Code. Click below for more details. Refactoring: Improving the Design of Existing Code author Martin Fowler with Kent Beck, John Brant, William Opdyke, pages 431 publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN summary Just what the working programmer ordered: a catalogue of practical refactorings with solid advice on when and how to apply them.

Overview

This book could very well do for refactoring what the "Gang of Four" book did for design patterns. In fact, with the number of contributing authors, this might well become known as the "Gang of Five" book. (They contributed content to chapters 3 and 12 through 15.)

Organization

Refactoring leaps in feet first with an extended example. I found this to be a surprisingly effective opener: it didn't overwhelm me, and left me hungry for more. The first chapter follows a sample program through several incremental refactorings, and the reader gets the idea via osmosis.

To illustrate the technique of refactoring, the first chapter presents the original code on the left page, and the resulting code on the right, with changes in bold. This presentation, coupled with explanatory text, makes it easy to see what's going on and focus on what's happening. It's as if you're looking over the author's shoulder as he edits, compiles, and tests code in his development environment.

What is Refactoring?

Now that you've done a refactoring, you might be curious to know more about what refactoring is. The next few chapters provide the relevant background.

Refactoring is what the book's subtitle suggests: changing code in in ways that preserve behaviour, but improve the way that behaviour is generated. This could be as trivial as renaming a method, or as tricky as separating domain and presentation classes.

Why go through this trouble? In the end, the code is different but it acts the same; there has been no new functionality added. Why? You do this to place yourself in a better position to add new functionality to the software. If you don't, you eventually end up with spaghetti code that is unmaintainable and will not support new functionality at all.

I think anyone who has worked on real code can appreciate the need for refactoring. In fact, most good programmers already do it, although perhaps only on a subconscious level. What this book aims to do is to raise that ad-hoc activity to a higher level of applied technique. Just as there are principles and practices in GUI design (as opposed to merely throwing widgets together randomly), there are principles and practices in refactoring activity: this book catalogues them.

Catalogue

Sandwiched between introductory and summary chapters is the meat of the book: a catalogue of over seventy refactorings. This catalogue follows in the footsteps of the highly successful Design Patterns format: Pattern Name and Classification, Intent, Also Known As, Motivation, Applicability, Structure, Participants, Collaborations, Implementation, Sample Code, Known Uses, and Related Patterns. Since the individual refactorings are less complex than patterns, this catalogue uses the format: Name, Summary, Motivation, Mechanics, and Examples.

The idea is the same. The name and summary provide a definitive vocabulary and a reference-card example. The motivation explains the relevance of the refactoring. The mechanics cover the step-by-step details of how the refactoring is executed. Then a series of examples demonstrate the variations.

Applicability

I like the catalogue. Although some refactorings seem deceptively trivial, it is useful to have them laid out in step-by-step detail. You never know when you will make a mistake, and when you absolutely positively must fix a bug or add a feature by the next day, and need to refactor to do it, slow and steady wins the race.

Further, other refactorings are not so trivial and familiar, and it is certainly useful to have their traps and pitfalls exposed. Frequently, they rely on the smaller refactorings themselves.

I can see this book becoming well-used in a shop with plenty of production code.

Supplementary Material

The non-catalogue chapters are informative as well. I especially appreciate the metaphor of bad smells in the code: the "if it stinks, change it" philosophy is the perfect counter-point to the oft-cited "if it ain't broke, don't fix it" mentality.

The chapter on refactoring tools discusses the possibility of automating much of the mechanical work of refactoring. Although there is a Refactoring Browser for Smalltalk, I suspect that Java and C++ versions are a little ways off. I'd wager that, as with the UML, tool support will lag industry practice for some time.

Style

As always, the author's writing style is down-to-earth and easy to read. Martin tells you straight up what he's found useful and what he hasn't. He tells you where he's made mistakes, and where the risk is less pronounced.

I like the way he goes through an example, then goes through it again under different conditions, thereby revealing the many-splendoured variations. Frequently he continues examples that were left off from other refactorings.

Plenty of further reading is suggested; I always like that.

Flaws

The book has a Java focus, and that is the language used for the examples. There is some mention of Smalltalk and C++, but not much; far less than Design Patterns, for example. Still, the book is quite understandable to anyone with object-oriented development experience.

The book references design patterns; some refactorings even apply and manipulate patterns. However, I wish there were more direct references to the Design Patterns book. That would especially help those new to both refactorings and design patterns.

There are a few minor typos (nothing major), so check the author's web site for errata and try to get a recent printing if you can.

Recommendation

It's no secret that I think this is a book whose time has come. I'm hoping it will codify my approach to refactoring, to help me be more efficient in my development.

I recommend this book as both a practical catalogue, and as a general work on the theory and practice of refactoring. I think that the refactoring community will grow much as the patterns community before it, and that we will see more published on the subject.

Until then, this book is a good start.

Purchase this at Amazon.

TABLE OF CONTENTS

Foreword
Preface
1. Refactoring, a First Example
2. Principles in Refactoring
3. Bad Smells in Code
4. Building Tests
5. Toward a Catalog of Refactorings
6. Composing Methods
7. Moving Features Between Objects
8. Organizing Data
9. Simplifying Conditional Expressions
10. Making Method Calls Simpler
11. Dealing with Generalization
12. Big Refactorings
13. Refactoring, Reuse, and Reality
14. Refactoring Tools
15. Putting It All Together
References
List of Soundbites
Index

Thanks to SEGV for the this review of Jacobson, Booch, Rumbaugh's latest effort The Unified Software Development Process. A book designed for those of you who love process (or want to learn development process), click below for more information. The Unified Software Development Process author Ivar Jacobson, Grady Booch, and James Rumbaugh pages 512 publisher Addison-Wesley Publishing Co. rating 8/10 reviewer SEGV ISBN summary A textbook treatment on process in software development. Covers the Unified Process from product launch to architectural baseline, through initial operational capability, ultimately to product release. Information rich but occasionally dry.

The Unified Process

This book is the third by the Three Amigos this past year (the other two being the UML user and reference guides). Although recently known for their work on the UML at Rational, the Unified Process is an outgrowth of Jacobson's original work at Ericsson on the Objectory Process.

So what is the Unified Process? I'll quote from the book's glossary:

A sofware development process based on the unified modeling language that is iterative, architecture-centric, use-case driven, and risk-driven. A process that is organized around the four phases: inception, elaboration, construction, and transition, and that is further organized around the five core workflows: requirements capture, analysis, design, implementation, and test. A process that is described in terms of a business model, which in turn is structured in terms of three primitive building blocks: workers, activities, and artifacts.

Essentially, this is the 463 page textbook elaborating on what was briefly described in the second chapter of Martin Fowler's UML Distilled [related review].

Organization

The book itself is well organized. Chapters are broken into logical sections and bite-sized subsections. For example, most chapters in Part II follow this structure: introduction, role, artifacts, workers, workflow, summary, and references. That consistency is a boon to the reader (and not an albatross, as it is deviated from where necessary).

Figures help the reader to maintain a frame of reference (e.g., traveling through the phases and workflows). This is important as the Unified Process can occasionally be confusing, with its repeated iterations and workflows.

The authors provide examples where illustrative and references where beneficial. The appendices are handy, especially the 13 page overview of the UML (which is very well done).

Impartiality

One of my concerns reading this book was the degree of impartiality of the authors. Naturally, being Rational employees they have a vested interest in promoting their Unified Process and UML tools. Happily, I didn't notice an overt conflict of interest. Rational is mentioned a few times, but not obtrusively. And although they mention tool support as being an imperative, that's probably true.

Another area of impartiality is in their references. The authors don't reference their own works exclusively, but instead point the reader in other fruitful directions, including the design patterns literature and even Peter Drucker's writings on management theory.

Impressions

I found that the authors often had useful things to say. Whenever I open to a random page, I find a useful tidbit or two, and I appreciate that. There's nothing radical here, but the structured presentation benefits the content a lot.

This is a book on software process, and a fairly textbook-ish one at that, so I wasn't surprised to find the writing a little dry. In particular, I found the chapters in Part II to be particularly soporific on first read, but then I realize that the internal mechanics of software development don't necessarily make for the most thrilling read. Returning to those chapters to read in measured dosage really does them well.

Minor Drawbacks

I'd like to have seen a little more variation in the examples. I remember quite a few dealing with bank machines, and although that leads itself to a certain stability, it can be hard to get excited over such applications.

Although the index is fairly complete, I recall one omission in particular. The authors discuss three ways the Unified Process addresses the issue of "good enough" software, yet no mention is made in the index. That piqued me when I wanted to look it up.

Finally, although the authors use C++ and Java for the occasional lower level example, they use a directory as a packaging mechanism in the former. I feel a namespace is more applicable.

Applicability

While I was reading this book, I was preparing documents and presentations on software process for my employer. I did find this book to be helpful, and definitely feel that it was a worthwhile read.

This is not a recipe book. It won't lay down everything for you. But it will get you started thinking in the right direction, and aware of the issues involved in an industrial strength software development process.

However, it's important to remember that the Unified Process is not the answer to all process questions. Although it scales well, I believe it can be overkill for small teams, and I assume inadequate for some larger organizations as well.

Recommendation

If process is your thing, then you'll probably want this book. If you lead a team in a medium sized software development organization, and are interested in introducing a more formal process, then this book is a recommended read. Even if you don't end up applying the Unified Process, it simply addresses too many relevant details to be ignored.

I don't recommend this book for casual reading, unless you have an interest in process. A good example might be a developer in a medium sized organization who feels they need a more formal process. A good guideline might be whether you're still interested after reading the glossary quote in the introduction.

You will find the book web page in Addison-Wesley's Object Technology Series.

Purchase this book at Amazon.

TABLE OF CONTENTS

Preface
Part I: The Unified Software Development Process
1. The Unified Process: Use-Case Driven, Architecture-Centric, Iterative, and Incremental
2. The Four Ps: People, Project, Product, and Process in Software Development
3. A Use-Case-Driven Process
4. An Architecture-Centric Process
5. An Iterative and Incremental Process
Part II: The Core Workflows
6. Requirements Capture: From Vision to Requirements
7. Capturing the Requirements as Use Cases
8. Analysis
9. Design
10. Implementation
11. Test
Part III: Iterative and Incremental Development
12. The Generic Iteration Workflow
13. Inception Launches the Project
14. The Elaboration Phase Makes the Architecural Baseline
15. Construction Leads to Initial Operational Capability
16. Transition Completes the Product Release
17. Making the Unified Process Work
Appendix A: Overview of the UML
Appendix B: The Unified Process-Specific Extensions of the UML
Appendix C: Glossary
Index

SEGV has submitted a review of UML Distilled: Applying the Standard Object Modeling Language, the first book by Addison-Wesley that is UML Specific in their Object Technology Series. If you're interested in knowing more about the Uniform Modeling Language, click below. UML Distilled: Applying the Standard Object Modeling Language author Martin Fowler with Kendall Scott pages publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN 0-201-32563-2 summary A short and to the point introduction to the standard object modeling language.

UML Distilled: Applying the Standard Object Modeling Language,
by Martin Fowler with Kendall Scott
[Addison-Wesley, ISBN 0-201-32563-2]

reviewed by SEGV

Nutshell
Review:

A short and to the point introduction to the standard object modeling language.

Rating: 9/10

What is the UML?

A modeling language is a (mainly graphical) notation for expressing software designs. Over the last decade, many object-oriented analysis and design gurus developed their own modeling languages and techniques for using them. The two most successful were the Booch method and OMT (Object Modeling Technique). Over the last few years, three of the top gurus (Grady Booch, Jim Rumbaugh, and Ivar Jacobson, now known as the "three amigos") joined forces and unified their methods; hence, the Unified Modeling Language.

The result of that union was the company Rational Software, which developed UML versions 1.0 and 1.1. Now, the OMG (Object Management Group, purveyors of CORBA) is in the process of adopting the UML as standard. Be warned: the OMG adopted version 1.1 as their version 1.0, so there is a lamentable discrepancy in the version numbers.

About the Book

UML Distilled is the first UML-specific book in Addison-Wesley's Object Technology Series (the three amigos are the series editors). The book's online site contains some sample chapters and supplementary information. Martin Fowler's home page also contains useful information.

I have the sixth printing, which is updated to cover UML version 1.0 (per OMG). If you get this book, be sure to get this printing or later.

100% Distilled

UML Distilled is one of the shortest computer books I own: the chapters themselves comprise only 166 pages. It is really only an introduction and overview of the UML and its application; three forthcoming books by the three amigos will go into greater depth. However, the book's brevity is its strength: it is very easily read, and can be consumed in a good afternoon.

Applying the UML

Fowler cuts straight to the chase. In the second chapter he outlines a bare bones development process suitable for use with the UML. In subsequent chapters he covers different parts of the UML, explaining notation, semantics, tips, and techniques. The final chapter is the piece de resistance: an extended example taking the reader from a UML design to Java code.

Throughout UML Distilled, Fowler is not afraid to tell you how he uses the modeling language himself. He will tell you which parts of it he finds extremely useful, and which parts he doesn't bother with. He'll even tell you where he is inclined to bend the rules slightly and do something that strictly speaking doesn't conform to the standard. That's okay, since the desired result is to have the modeling language be of use to you.

Diagrams

As the table of contents shows, most of the chapters cover a particular type of diagram in the UML. If you've never object modeling diagrams, you should check out the book's inside covers, which give a feel for their various elements (and serve as an excellent reference).

I find the class diagrams, interaction diagrams, and activity diagrams to be of most use to me. The first kind is absolutely essential for documenting the structure of your classes. The second kind is useful for documenting how the various classes interact with each other. The third kind is useful for documenting the steps in a task. The latter two kinds even allow for concurrency! And of course, they are all meant to be used during the design phase, and not merely for documentation after the implementation phase (often a sad reality).

Software

I typically do object modeling with a stack of large sheets of blank paper, or a whiteboard. But software tools do exist, whether they are more of a drawing tool or actually generate code. Rational Rose is one of the better known and most advanced tools. However, the software is typically quite expensive. I'm not aware of any freely available alternatives.

Design Patterns

It is worth noting that Fowler is also the author of Analysis Patterns (online site), a book of design patterns for business domain modeling. If you're a patterns fan, you'll be happy to note that there are several examples of their usage in UML Distilled.

Summary

UML Distilled is suitable for all levels. It is short and to the point, and offers an excellent introduction to the field of object modeling. Fowler offers good advice where he is qualified, and points the reader elsewhere (other books or web sites) where his knowledge or experience is lacking, or where further information is available. I recommend this book, at least until the "canon" UML books are available!

Buy this book over at Amazon.

TABLE OF CONTENTS

1. Introduction
2. An Outline Development Process
3. Use Cases
4. Class Diagrams: The Essentials
5. Class Diagrams: Advanced Concepts
6. Interaction Diagrams
7. Package Diagrams
8. State Diagrams
9. Activity Diagrams
10. Deployment Diagrams
11. UML and Programming

• Techniques and Their Uses
• Changes From UML 1.0 to 1.1
• Bibliography
• Index

SEGV has submitted a review of UML Distilled: Applying the Standard Object Modeling Language, the first book by Addison-Wesley that is UML Specific in their Object Technology Series. If you're interested in knowing more about the Uniform Modeling Language, click below. UML Distilled: Applying the Standard Object Modeling Language author Martin Fowler with Kendall Scott pages publisher Addison-Wesley rating 9/10 reviewer SEGV ISBN 0-201-32563-2 summary A short and to the point introduction to the standard object modeling language.

UML Distilled: Applying the Standard Object Modeling Language,
by Martin Fowler with Kendall Scott
[Addison-Wesley, ISBN 0-201-32563-2]

reviewed by SEGV

Nutshell
Review:

A short and to the point introduction to the standard object modeling language.

Rating: 9/10

What is the UML?

A modeling language is a (mainly graphical) notation for expressing software designs. Over the last decade, many object-oriented analysis and design gurus developed their own modeling languages and techniques for using them. The two most successful were the Booch method and OMT (Object Modeling Technique). Over the last few years, three of the top gurus (Grady Booch, Jim Rumbaugh, and Ivar Jacobson, now known as the "three amigos") joined forces and unified their methods; hence, the Unified Modeling Language.

The result of that union was the company Rational Software, which developed UML versions 1.0 and 1.1. Now, the OMG (Object Management Group, purveyors of CORBA) is in the process of adopting the UML as standard. Be warned: the OMG adopted version 1.1 as their version 1.0, so there is a lamentable discrepancy in the version numbers.

About the Book

UML Distilled is the first UML-specific book in Addison-Wesley's Object Technology Series (the three amigos are the series editors). The book's online site contains some sample chapters and supplementary information. Martin Fowler's home page also contains useful information.

I have the sixth printing, which is updated to cover UML version 1.0 (per OMG). If you get this book, be sure to get this printing or later.

100% Distilled

UML Distilled is one of the shortest computer books I own: the chapters themselves comprise only 166 pages. It is really only an introduction and overview of the UML and its application; three forthcoming books by the three amigos will go into greater depth. However, the book's brevity is its strength: it is very easily read, and can be consumed in a good afternoon.

Applying the UML

Fowler cuts straight to the chase. In the second chapter he outlines a bare bones development process suitable for use with the UML. In subsequent chapters he covers different parts of the UML, explaining notation, semantics, tips, and techniques. The final chapter is the piece de resistance: an extended example taking the reader from a UML design to Java code.

Throughout UML Distilled, Fowler is not afraid to tell you how he uses the modeling language himself. He will tell you which parts of it he finds extremely useful, and which parts he doesn't bother with. He'll even tell you where he is inclined to bend the rules slightly and do something that strictly speaking doesn't conform to the standard. That's okay, since the desired result is to have the modeling language be of use to you.

Diagrams

As the table of contents shows, most of the chapters cover a particular type of diagram in the UML. If you've never object modeling diagrams, you should check out the book's inside covers, which give a feel for their various elements (and serve as an excellent reference).

I find the class diagrams, interaction diagrams, and activity diagrams to be of most use to me. The first kind is absolutely essential for documenting the structure of your classes. The second kind is useful for documenting how the various classes interact with each other. The third kind is useful for documenting the steps in a task. The latter two kinds even allow for concurrency! And of course, they are all meant to be used during the design phase, and not merely for documentation after the implementation phase (often a sad reality).

Software

I typically do object modeling with a stack of large sheets of blank paper, or a whiteboard. But software tools do exist, whether they are more of a drawing tool or actually generate code. Rational Rose is one of the better known and most advanced tools. However, the software is typically quite expensive. I'm not aware of any freely available alternatives.

Design Patterns

It is worth noting that Fowler is also the author of Analysis Patterns (online site), a book of design patterns for business domain modeling. If you're a patterns fan, you'll be happy to note that there are several examples of their usage in UML Distilled.

Summary

UML Distilled is suitable for all levels. It is short and to the point, and offers an excellent introduction to the field of object modeling. Fowler offers good advice where he is qualified, and points the reader elsewhere (other books or web sites) where his knowledge or experience is lacking, or where further information is available. I recommend this book, at least until the "canon" UML books are available!

Buy this book over at Amazon.

TABLE OF CONTENTS

1. Introduction
2. An Outline Development Process
3. Use Cases
4. Class Diagrams: The Essentials
5. Class Diagrams: Advanced Concepts
6. Interaction Diagrams
7. Package Diagrams
8. State Diagrams
9. Activity Diagrams
10. Deployment Diagrams
11. UML and Programming

• Techniques and Their Uses
• Changes From UML 1.0 to 1.1
• Bibliography
• Index