Slashdot Mirror

Mazzaroth queries: "Over the last few years, system architects saw many middleware and language eras. RPC, CORBA, .Net, EJB/J2EE (with WebLogic, WebSphere, and the zillion of other apps servers), XML/SOAP, Java, C++, C#, to name a few. More recently, an effort has been initiated to isolate application's architecture from the middleware particularities: Model-Driven Architecture (MDA). The idea is pretty good. This will eventually allow me to model the application, deploy it on .NET, then change my mind and go for WebLogic instead for instance. Even if the number of software engineering tools supporting MDA is quite limited for now, I would like to get feedback from people using an MDA approach to develop their application. What are the drawbacks, difficulties and limitations of MDA? What would be required in UML to better support MDA? What percentage of code can actually be generated? Can you share your experience?"

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.

Wrinkled Shirt writes: "If you want to be able to work either as or with a systems analyst, you're going to have to speak the same language as everyone else in your team, and in the tech industry that language is increasingly becoming the UML. The Unified Modelling Language provides ways of modelling every sort of system that you can imagine, covering everything from the relationships of your different objects to the dynamics of the system in action to the way it'll look when you physically set it up." He's reviewed below the SAMS-published Teach Yourself UML in 24 Hours; read on below for his reactions to the book, both good and bad. Teach Yourself UML in 24 Hours, 2nd Edition author Joseph Schmuller pages 397 publisher SAMS rating 5.5 reviewer WrinkledShirt ISBN 0-672-32238-2 summary Useful enough as an introductory text, but likely needs companion texts for anyone who wants to design complex systems.

Introduction

The UML was adopted by the OMG (Object Management Group) as their official method of visually representing an object-oriented design, and as such is particularly well-suited to working with CORBA (Common Object Request Broker Architecture). Now, the OMG believes in their acronyms the way the Irish believe in their whiskey, and if you're hoping they'll give you introductory material on how to use the UML without broadening the context to all the other standards the OMG is responsible for, well, good luck. Addison Wesley has an entire series dedicated to the UML and different aspects of it, and O'Reilly's got the requisite Nutshell book, but there's definitely a void for good low-cost beginner texts, and it is this void that Schmuller's book attempts to fill.

Does it succeed? Well, sort of.

The Good

Teach Yourself UML in 24 Hours is a very thorough introduction to the language. The first fifteen chapters alone cover practically every structural and behavioural element, all the important relationships, static diagrams and dynamic diagrams, and even a little object-oriented design theory. As far as computer books go, it's not very expensive at its full price, and is even available at some discount stores. It is also loaded with sample diagrams throughout, and has a large seven-chapter case study going through a sample project design process, terminating with a couple of chapters on miscellaneous applications of the UML.

Understanding the subjective element of design, this book tries to help the reader gain their own personal take on the UML by providing lots of sample exercises to perform, and the sum total is a book that gives the reader a good idea of the effectiveness of the UML as a modelling language. In fact, if I were a systems analyst and I needed to give my team a crash course in the UML before getting them to implement my specs, I could do a lot worse than making them all read this book first.

Unfortunately, here's where the accolades stop. A book that teaches people how to read another person's diagrams written in the UML is one thing, but as an effective reference on how to design using the UML, the book comes up short in a few ways.

The Not-So-Good

Part of the power of the UML is that even though the OMG really needed to it to get their CORBA spec to make sense visually, you can basically use the UML to describe any old sort of system you want. Unfortunately, Schmuller takes a little too much advantage of this, and a disproportionate amount of the examples and diagrams involve physical systems instead of software systems. It's as though software design is a bit of an afterthought, which is fine, but the book could have been richer had it focused more on this aspect of UML implementation rather than, for instance, how to use the UML to model a soda machine.

Another shortcoming is that the book tantalizes us with the odd example proving that part of the power of the UML comes from the flexibility to combine elements from multiple diagrams into a single diagram, and yet these examples are used so sparingly and with no substantive explanation to the methodology involved that you're left with a feeling that even though the UML can do a lot of things, you're not quite sure how to make it do all those things for you.

It's admirable that Schmuller devoted so much time to the case study, and made sure that the scope was broad enough that all of the topics explained to that point got an appearance. However, one of the pitfalls of trying to come up with a case study that outlines a fundamentally subjective process is that some of the design decisions are going to seem arbitrary to some people who don't have a psychic connection to the author. It's not something unique to this book, but this book falls victim to it. Schmuller would have done better to have used those seven chapters to describe two different systems to give a broader idea and more than one context to the process of UML design. He also took a little too much creative license with scripting the hypothetical interview process. A reference book on the UML isn't the best place to try out your best David Mamet impression.

And then there are the really minor problems. Some of the diagrams could use a little cleaning up, and sometimes the basic diagram is represented a little differently in the summary section as it is in the chapter dedicated to it. Some of the more complex diagrams are handled first and the simpler ones later. There's no real explanation that makes sense to a newbie about the difference between an aggregation and a composite. And finally, even though one could argue that learning about the UML itself should be kept as a separate and distinct process from learning about how to program off a UML design, I think such a chapter would have been far more beneficial to a neophyte than the chapter on modelling for embedded systems, which is likely to be the domain of people who are far beyond the level of UML familiarity that this book is going to give you anyway.

Conclusion

Now, even though as individual criticisms these might seem minor, as a whole it adds up to a book that's going to need a couple of companion references for the reader to truly feel ready to start diagramming with the UML in a professional environment. However, as said before, it isn't too expensive and is pretty much alone in the world of introductory manuals to the UML, and even if you're hoping to become a full-fledged analyst you have to learn to crawl before you can learn to walk, and this book will help you do just that. Just don't expect to be running marathons by the end.

Table of Contents

( exploded version here)

Introduction.
Hour 1. Introducing the UML.
Hour 2. Understanding Object-Orientation.
Hour 3. Working with Object-Orientation.
Hour 4. Working with Relationships.
Hour 5. Understanding Aggregations, Composites, Interfaces, and Realizations.
Hour 6. Introducing Use Cases.
Hour 7. Working with Use Case Diagrams.
Hour 8. Working with State Diagrams.
Hour 9. Working with Sequence Diagrams.
Hour 10. Working with Collaboration Diagrams.
Hour 11. Working with Activity Diagrams.
Hour 12. Working with Component Diagrams.
Hour 13. Working with Deployment Diagrams.
Hour 14. Understanding the Foundations of the UML.
Hour 15. Fitting the UML into a Development Process.
Hour 16. Introducing the Case Study.
Hour 17. Performing a Domain Analysis.
Hour 18. Gathering System Requirements.
Hour 19. Developing the Use Cases.
Hour 20. Getting into Interactions and State Changes.
Hour 21. Designing Look, Feel, and Deployment.
Hour 22. Understanding Design Patterns.
Hour 23. Modeling Embedded Systems.
Hour 24. Shaping the Future of the UML.
Appendix A. Quiz Answers.
Appendix B. Modeling Tools for the UML.
Appendix C. A Summary in Pictures.
Index.

Related Links SAMS
Object Management Group
OMG's UML Resource Page
Google Search for Case Tools

You can purchase Teach Yourself UML in 24 Hours at Fatbrain. Want to see your own review here? Read the review guidelines first, then use Slashdot's webform.

Wrinkled Shirt writes: "If you want to be able to work either as or with a systems analyst, you're going to have to speak the same language as everyone else in your team, and in the tech industry that language is increasingly becoming the UML. The Unified Modelling Language provides ways of modelling every sort of system that you can imagine, covering everything from the relationships of your different objects to the dynamics of the system in action to the way it'll look when you physically set it up." He's reviewed below the SAMS-published Teach Yourself UML in 24 Hours; read on below for his reactions to the book, both good and bad. Teach Yourself UML in 24 Hours, 2nd Edition author Joseph Schmuller pages 397 publisher SAMS rating 5.5 reviewer WrinkledShirt ISBN 0-672-32238-2 summary Useful enough as an introductory text, but likely needs companion texts for anyone who wants to design complex systems.

Introduction

The UML was adopted by the OMG (Object Management Group) as their official method of visually representing an object-oriented design, and as such is particularly well-suited to working with CORBA (Common Object Request Broker Architecture). Now, the OMG believes in their acronyms the way the Irish believe in their whiskey, and if you're hoping they'll give you introductory material on how to use the UML without broadening the context to all the other standards the OMG is responsible for, well, good luck. Addison Wesley has an entire series dedicated to the UML and different aspects of it, and O'Reilly's got the requisite Nutshell book, but there's definitely a void for good low-cost beginner texts, and it is this void that Schmuller's book attempts to fill.

Does it succeed? Well, sort of.

The Good

Teach Yourself UML in 24 Hours is a very thorough introduction to the language. The first fifteen chapters alone cover practically every structural and behavioural element, all the important relationships, static diagrams and dynamic diagrams, and even a little object-oriented design theory. As far as computer books go, it's not very expensive at its full price, and is even available at some discount stores. It is also loaded with sample diagrams throughout, and has a large seven-chapter case study going through a sample project design process, terminating with a couple of chapters on miscellaneous applications of the UML.

Understanding the subjective element of design, this book tries to help the reader gain their own personal take on the UML by providing lots of sample exercises to perform, and the sum total is a book that gives the reader a good idea of the effectiveness of the UML as a modelling language. In fact, if I were a systems analyst and I needed to give my team a crash course in the UML before getting them to implement my specs, I could do a lot worse than making them all read this book first.

Unfortunately, here's where the accolades stop. A book that teaches people how to read another person's diagrams written in the UML is one thing, but as an effective reference on how to design using the UML, the book comes up short in a few ways.

The Not-So-Good

Part of the power of the UML is that even though the OMG really needed to it to get their CORBA spec to make sense visually, you can basically use the UML to describe any old sort of system you want. Unfortunately, Schmuller takes a little too much advantage of this, and a disproportionate amount of the examples and diagrams involve physical systems instead of software systems. It's as though software design is a bit of an afterthought, which is fine, but the book could have been richer had it focused more on this aspect of UML implementation rather than, for instance, how to use the UML to model a soda machine.

Another shortcoming is that the book tantalizes us with the odd example proving that part of the power of the UML comes from the flexibility to combine elements from multiple diagrams into a single diagram, and yet these examples are used so sparingly and with no substantive explanation to the methodology involved that you're left with a feeling that even though the UML can do a lot of things, you're not quite sure how to make it do all those things for you.

It's admirable that Schmuller devoted so much time to the case study, and made sure that the scope was broad enough that all of the topics explained to that point got an appearance. However, one of the pitfalls of trying to come up with a case study that outlines a fundamentally subjective process is that some of the design decisions are going to seem arbitrary to some people who don't have a psychic connection to the author. It's not something unique to this book, but this book falls victim to it. Schmuller would have done better to have used those seven chapters to describe two different systems to give a broader idea and more than one context to the process of UML design. He also took a little too much creative license with scripting the hypothetical interview process. A reference book on the UML isn't the best place to try out your best David Mamet impression.

And then there are the really minor problems. Some of the diagrams could use a little cleaning up, and sometimes the basic diagram is represented a little differently in the summary section as it is in the chapter dedicated to it. Some of the more complex diagrams are handled first and the simpler ones later. There's no real explanation that makes sense to a newbie about the difference between an aggregation and a composite. And finally, even though one could argue that learning about the UML itself should be kept as a separate and distinct process from learning about how to program off a UML design, I think such a chapter would have been far more beneficial to a neophyte than the chapter on modelling for embedded systems, which is likely to be the domain of people who are far beyond the level of UML familiarity that this book is going to give you anyway.

Conclusion

Now, even though as individual criticisms these might seem minor, as a whole it adds up to a book that's going to need a couple of companion references for the reader to truly feel ready to start diagramming with the UML in a professional environment. However, as said before, it isn't too expensive and is pretty much alone in the world of introductory manuals to the UML, and even if you're hoping to become a full-fledged analyst you have to learn to crawl before you can learn to walk, and this book will help you do just that. Just don't expect to be running marathons by the end.

Table of Contents

( exploded version here)

Introduction.
Hour 1. Introducing the UML.
Hour 2. Understanding Object-Orientation.
Hour 3. Working with Object-Orientation.
Hour 4. Working with Relationships.
Hour 5. Understanding Aggregations, Composites, Interfaces, and Realizations.
Hour 6. Introducing Use Cases.
Hour 7. Working with Use Case Diagrams.
Hour 8. Working with State Diagrams.
Hour 9. Working with Sequence Diagrams.
Hour 10. Working with Collaboration Diagrams.
Hour 11. Working with Activity Diagrams.
Hour 12. Working with Component Diagrams.
Hour 13. Working with Deployment Diagrams.
Hour 14. Understanding the Foundations of the UML.
Hour 15. Fitting the UML into a Development Process.
Hour 16. Introducing the Case Study.
Hour 17. Performing a Domain Analysis.
Hour 18. Gathering System Requirements.
Hour 19. Developing the Use Cases.
Hour 20. Getting into Interactions and State Changes.
Hour 21. Designing Look, Feel, and Deployment.
Hour 22. Understanding Design Patterns.
Hour 23. Modeling Embedded Systems.
Hour 24. Shaping the Future of the UML.
Appendix A. Quiz Answers.
Appendix B. Modeling Tools for the UML.
Appendix C. A Summary in Pictures.
Index.

Related Links SAMS
Object Management Group
OMG's UML Resource Page
Google Search for Case Tools

You can purchase Teach Yourself UML in 24 Hours at Fatbrain. Want to see your own review here? Read the review guidelines first, then use Slashdot's webform.

Wrinkled Shirt writes: "If you want to be able to work either as or with a systems analyst, you're going to have to speak the same language as everyone else in your team, and in the tech industry that language is increasingly becoming the UML. The Unified Modelling Language provides ways of modelling every sort of system that you can imagine, covering everything from the relationships of your different objects to the dynamics of the system in action to the way it'll look when you physically set it up." He's reviewed below the SAMS-published Teach Yourself UML in 24 Hours; read on below for his reactions to the book, both good and bad. Teach Yourself UML in 24 Hours, 2nd Edition author Joseph Schmuller pages 397 publisher SAMS rating 5.5 reviewer WrinkledShirt ISBN 0-672-32238-2 summary Useful enough as an introductory text, but likely needs companion texts for anyone who wants to design complex systems.

Introduction

The UML was adopted by the OMG (Object Management Group) as their official method of visually representing an object-oriented design, and as such is particularly well-suited to working with CORBA (Common Object Request Broker Architecture). Now, the OMG believes in their acronyms the way the Irish believe in their whiskey, and if you're hoping they'll give you introductory material on how to use the UML without broadening the context to all the other standards the OMG is responsible for, well, good luck. Addison Wesley has an entire series dedicated to the UML and different aspects of it, and O'Reilly's got the requisite Nutshell book, but there's definitely a void for good low-cost beginner texts, and it is this void that Schmuller's book attempts to fill.

Does it succeed? Well, sort of.

The Good

Teach Yourself UML in 24 Hours is a very thorough introduction to the language. The first fifteen chapters alone cover practically every structural and behavioural element, all the important relationships, static diagrams and dynamic diagrams, and even a little object-oriented design theory. As far as computer books go, it's not very expensive at its full price, and is even available at some discount stores. It is also loaded with sample diagrams throughout, and has a large seven-chapter case study going through a sample project design process, terminating with a couple of chapters on miscellaneous applications of the UML.

Understanding the subjective element of design, this book tries to help the reader gain their own personal take on the UML by providing lots of sample exercises to perform, and the sum total is a book that gives the reader a good idea of the effectiveness of the UML as a modelling language. In fact, if I were a systems analyst and I needed to give my team a crash course in the UML before getting them to implement my specs, I could do a lot worse than making them all read this book first.

Unfortunately, here's where the accolades stop. A book that teaches people how to read another person's diagrams written in the UML is one thing, but as an effective reference on how to design using the UML, the book comes up short in a few ways.

The Not-So-Good

Part of the power of the UML is that even though the OMG really needed to it to get their CORBA spec to make sense visually, you can basically use the UML to describe any old sort of system you want. Unfortunately, Schmuller takes a little too much advantage of this, and a disproportionate amount of the examples and diagrams involve physical systems instead of software systems. It's as though software design is a bit of an afterthought, which is fine, but the book could have been richer had it focused more on this aspect of UML implementation rather than, for instance, how to use the UML to model a soda machine.

Another shortcoming is that the book tantalizes us with the odd example proving that part of the power of the UML comes from the flexibility to combine elements from multiple diagrams into a single diagram, and yet these examples are used so sparingly and with no substantive explanation to the methodology involved that you're left with a feeling that even though the UML can do a lot of things, you're not quite sure how to make it do all those things for you.

It's admirable that Schmuller devoted so much time to the case study, and made sure that the scope was broad enough that all of the topics explained to that point got an appearance. However, one of the pitfalls of trying to come up with a case study that outlines a fundamentally subjective process is that some of the design decisions are going to seem arbitrary to some people who don't have a psychic connection to the author. It's not something unique to this book, but this book falls victim to it. Schmuller would have done better to have used those seven chapters to describe two different systems to give a broader idea and more than one context to the process of UML design. He also took a little too much creative license with scripting the hypothetical interview process. A reference book on the UML isn't the best place to try out your best David Mamet impression.

And then there are the really minor problems. Some of the diagrams could use a little cleaning up, and sometimes the basic diagram is represented a little differently in the summary section as it is in the chapter dedicated to it. Some of the more complex diagrams are handled first and the simpler ones later. There's no real explanation that makes sense to a newbie about the difference between an aggregation and a composite. And finally, even though one could argue that learning about the UML itself should be kept as a separate and distinct process from learning about how to program off a UML design, I think such a chapter would have been far more beneficial to a neophyte than the chapter on modelling for embedded systems, which is likely to be the domain of people who are far beyond the level of UML familiarity that this book is going to give you anyway.

Conclusion

Now, even though as individual criticisms these might seem minor, as a whole it adds up to a book that's going to need a couple of companion references for the reader to truly feel ready to start diagramming with the UML in a professional environment. However, as said before, it isn't too expensive and is pretty much alone in the world of introductory manuals to the UML, and even if you're hoping to become a full-fledged analyst you have to learn to crawl before you can learn to walk, and this book will help you do just that. Just don't expect to be running marathons by the end.

Table of Contents

( exploded version here)

Introduction.
Hour 1. Introducing the UML.
Hour 2. Understanding Object-Orientation.
Hour 3. Working with Object-Orientation.
Hour 4. Working with Relationships.
Hour 5. Understanding Aggregations, Composites, Interfaces, and Realizations.
Hour 6. Introducing Use Cases.
Hour 7. Working with Use Case Diagrams.
Hour 8. Working with State Diagrams.
Hour 9. Working with Sequence Diagrams.
Hour 10. Working with Collaboration Diagrams.
Hour 11. Working with Activity Diagrams.
Hour 12. Working with Component Diagrams.
Hour 13. Working with Deployment Diagrams.
Hour 14. Understanding the Foundations of the UML.
Hour 15. Fitting the UML into a Development Process.
Hour 16. Introducing the Case Study.
Hour 17. Performing a Domain Analysis.
Hour 18. Gathering System Requirements.
Hour 19. Developing the Use Cases.
Hour 20. Getting into Interactions and State Changes.
Hour 21. Designing Look, Feel, and Deployment.
Hour 22. Understanding Design Patterns.
Hour 23. Modeling Embedded Systems.
Hour 24. Shaping the Future of the UML.
Appendix A. Quiz Answers.
Appendix B. Modeling Tools for the UML.
Appendix C. A Summary in Pictures.
Index.

Related Links SAMS
Object Management Group
OMG's UML Resource Page
Google Search for Case Tools

You can purchase Teach Yourself UML in 24 Hours at Fatbrain. Want to see your own review here? Read the review guidelines first, then use Slashdot's webform.

Wrinkled Shirt writes: "If you want to be able to work either as or with a systems analyst, you're going to have to speak the same language as everyone else in your team, and in the tech industry that language is increasingly becoming the UML. The Unified Modelling Language provides ways of modelling every sort of system that you can imagine, covering everything from the relationships of your different objects to the dynamics of the system in action to the way it'll look when you physically set it up." He's reviewed below the SAMS-published Teach Yourself UML in 24 Hours; read on below for his reactions to the book, both good and bad. Teach Yourself UML in 24 Hours, 2nd Edition author Joseph Schmuller pages 397 publisher SAMS rating 5.5 reviewer WrinkledShirt ISBN 0-672-32238-2 summary Useful enough as an introductory text, but likely needs companion texts for anyone who wants to design complex systems.

Introduction

The UML was adopted by the OMG (Object Management Group) as their official method of visually representing an object-oriented design, and as such is particularly well-suited to working with CORBA (Common Object Request Broker Architecture). Now, the OMG believes in their acronyms the way the Irish believe in their whiskey, and if you're hoping they'll give you introductory material on how to use the UML without broadening the context to all the other standards the OMG is responsible for, well, good luck. Addison Wesley has an entire series dedicated to the UML and different aspects of it, and O'Reilly's got the requisite Nutshell book, but there's definitely a void for good low-cost beginner texts, and it is this void that Schmuller's book attempts to fill.

Does it succeed? Well, sort of.

The Good

Teach Yourself UML in 24 Hours is a very thorough introduction to the language. The first fifteen chapters alone cover practically every structural and behavioural element, all the important relationships, static diagrams and dynamic diagrams, and even a little object-oriented design theory. As far as computer books go, it's not very expensive at its full price, and is even available at some discount stores. It is also loaded with sample diagrams throughout, and has a large seven-chapter case study going through a sample project design process, terminating with a couple of chapters on miscellaneous applications of the UML.

Understanding the subjective element of design, this book tries to help the reader gain their own personal take on the UML by providing lots of sample exercises to perform, and the sum total is a book that gives the reader a good idea of the effectiveness of the UML as a modelling language. In fact, if I were a systems analyst and I needed to give my team a crash course in the UML before getting them to implement my specs, I could do a lot worse than making them all read this book first.

Unfortunately, here's where the accolades stop. A book that teaches people how to read another person's diagrams written in the UML is one thing, but as an effective reference on how to design using the UML, the book comes up short in a few ways.

The Not-So-Good

Part of the power of the UML is that even though the OMG really needed to it to get their CORBA spec to make sense visually, you can basically use the UML to describe any old sort of system you want. Unfortunately, Schmuller takes a little too much advantage of this, and a disproportionate amount of the examples and diagrams involve physical systems instead of software systems. It's as though software design is a bit of an afterthought, which is fine, but the book could have been richer had it focused more on this aspect of UML implementation rather than, for instance, how to use the UML to model a soda machine.

Another shortcoming is that the book tantalizes us with the odd example proving that part of the power of the UML comes from the flexibility to combine elements from multiple diagrams into a single diagram, and yet these examples are used so sparingly and with no substantive explanation to the methodology involved that you're left with a feeling that even though the UML can do a lot of things, you're not quite sure how to make it do all those things for you.

It's admirable that Schmuller devoted so much time to the case study, and made sure that the scope was broad enough that all of the topics explained to that point got an appearance. However, one of the pitfalls of trying to come up with a case study that outlines a fundamentally subjective process is that some of the design decisions are going to seem arbitrary to some people who don't have a psychic connection to the author. It's not something unique to this book, but this book falls victim to it. Schmuller would have done better to have used those seven chapters to describe two different systems to give a broader idea and more than one context to the process of UML design. He also took a little too much creative license with scripting the hypothetical interview process. A reference book on the UML isn't the best place to try out your best David Mamet impression.

And then there are the really minor problems. Some of the diagrams could use a little cleaning up, and sometimes the basic diagram is represented a little differently in the summary section as it is in the chapter dedicated to it. Some of the more complex diagrams are handled first and the simpler ones later. There's no real explanation that makes sense to a newbie about the difference between an aggregation and a composite. And finally, even though one could argue that learning about the UML itself should be kept as a separate and distinct process from learning about how to program off a UML design, I think such a chapter would have been far more beneficial to a neophyte than the chapter on modelling for embedded systems, which is likely to be the domain of people who are far beyond the level of UML familiarity that this book is going to give you anyway.

Conclusion

Now, even though as individual criticisms these might seem minor, as a whole it adds up to a book that's going to need a couple of companion references for the reader to truly feel ready to start diagramming with the UML in a professional environment. However, as said before, it isn't too expensive and is pretty much alone in the world of introductory manuals to the UML, and even if you're hoping to become a full-fledged analyst you have to learn to crawl before you can learn to walk, and this book will help you do just that. Just don't expect to be running marathons by the end.

Table of Contents

( exploded version here)

Introduction.
Hour 1. Introducing the UML.
Hour 2. Understanding Object-Orientation.
Hour 3. Working with Object-Orientation.
Hour 4. Working with Relationships.
Hour 5. Understanding Aggregations, Composites, Interfaces, and Realizations.
Hour 6. Introducing Use Cases.
Hour 7. Working with Use Case Diagrams.
Hour 8. Working with State Diagrams.
Hour 9. Working with Sequence Diagrams.
Hour 10. Working with Collaboration Diagrams.
Hour 11. Working with Activity Diagrams.
Hour 12. Working with Component Diagrams.
Hour 13. Working with Deployment Diagrams.
Hour 14. Understanding the Foundations of the UML.
Hour 15. Fitting the UML into a Development Process.
Hour 16. Introducing the Case Study.
Hour 17. Performing a Domain Analysis.
Hour 18. Gathering System Requirements.
Hour 19. Developing the Use Cases.
Hour 20. Getting into Interactions and State Changes.
Hour 21. Designing Look, Feel, and Deployment.
Hour 22. Understanding Design Patterns.
Hour 23. Modeling Embedded Systems.
Hour 24. Shaping the Future of the UML.
Appendix A. Quiz Answers.
Appendix B. Modeling Tools for the UML.
Appendix C. A Summary in Pictures.
Index.

Related Links SAMS
Object Management Group
OMG's UML Resource Page
Google Search for Case Tools

You can purchase Teach Yourself UML in 24 Hours at Fatbrain. Want to see your own review here? Read the review guidelines first, then use Slashdot's webform.

Wiggly asks: "I would like to program distributed systems using the same code base on multiple platforms and multiple languages therefore I am asking around..." And he's asking Slashdot. You've only read the tip of the iceberg, however. There's much more to digest if you decide to click on thru.

"I will firstly say though that none of this is meant as flamebait, or to detract from what any of the projects/products mentioned here have achieved. I just have a wishlist and I am looking for answers and opinions, not a holy war. I am sure that people use many of the things mentioned here on a regular basis for heavy duty apps quite happily and with great results.

There are a whole bunch of distributed programming frameworks around. RPC, ILU, CORBA, DCE, Java RMI and DCOM to name but the most common. Many of these are available on multiple platforms and there are a whole slew of interoperability tools to get them to talk to each other with varying degrees of success. Right now I will focus on CORBA as it is getting much more press than any other recently, and because it is the system that I personally know more about than the others..

Commercially there are a few good ORBs but they are terribly expensive. Developer kits for 'a well known brand' with good CORBA compliance start around 1500 - 1900 UK Pounds, for developer kits. Redistribution costs are around 1700 UK Pounds per processor. These kinds of costs don't really let people play with systems before buying although I know that most comercial ORB vendors will give you trials if they think you are a good bet to buy. Additionally most of the commercial ORBS support as few platforms as they possibly can.

On the Open Source side of things there are many, many implementations of CORBA to choose from, with their own special focus. CORBA compliance, speed, interoperability or whatever else that project's maintainers view as the most important goal(s). There is some great code out there, and a load of people spending every waking hour making it better.

What I cannot find at the moment is a system that targets multiple platforms and multiple languages. Want to use Perl to talk to C++ back ends? Well MICO/COPE is coming along. Want to use the same code on Windows NT as well? Too bad, NT support is very flaky (I have spent too many hours trying to get it working). Want to use Java Applets to talk to C? You have problems. Pick your favourite front/back end language combination and platform then try to find a solution. Problematic at best, and probably not possible at the moment.

Are these very strange requirements/wishes or would other people be willing to sacrifice ratified standards compliance and possibly performance for orthogonality of language/platform availability? I would like to be able to write code for Linux/Unices/Windows in my languages of choice (for me this would be Perl, Java and C++) without having to use multiple implementations on the different platforms.

The way things are shaping up I am thinking hard about rolling my own, because right now I have a need that I cannot fulfill from outside sources. Yes, not Invented Here strikes again, but I can't find a solution. Am I alone in this? What do you think? Do you have any solutions?"

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