UML is still as much an art as a science, and as proof I'd offer the fact that UML - despite industry-wide agreement of it being a Very Good Idea - still has very few native "speakers" who can offer the formula for how to do it successfully. Witness the effort of the two authors with decades of previous success in applying UML (and, as members of the Rational team, much future success tied to the successful application of UML) as they dispense the following:



Rule 1: "Use cases should not describe how the scenario will be implemented." - p.67 (this is the traditional design dogma, that it is even possible to describe a problem in a meaningful way that produces value without first acknowledging some aspect of the solution - see Kovitz's "Practical Software Requirements" for more on this)



Example: The authors offer an example where an actor (Driver) will perform a scenario (Take Trip) which will always include another use case (Fuel Vehicle).



Inconsistency:

* By specifying Driver, haven't we already made some assumptions about the particular implementation - that we are describing a car as the vehicle, and that a vehicle is even necessary to take a trip? Can't the individual just walk?

* Does every occurence require a vehicle to be fueled? What about a trip across town?

* Could this be a bike rather than a motorized vehicle?



Assessment: The point of this use case would be that the value proposition to the "driver" is to take a trip, not the act of driving a vehicle, so therefore it would make more sense to abstract the vehicle out of the equation and therefore break the inclusion of the Fuel Vehicle case.



Rule 2: "[U]se cases should be defined from the viewpoint of the actor that would use them, not from the system's viewpoint" - p.68



Example: A written use case for retrieving records from an archive, where the first step is that the record is locked against update.



Inconsistenency:

* How exactly is a database lock occurring from the Actor's viewpoint? How is this not acknowledging the the eventual system implementation?



Other miscellaneous nonsense:



Statement: "[The use case has ] post-conditions that must be true after the use case is run" - p.80



Example: The use case's post-condition is stated as 'The Records Closure Schedule and Records Destruction Schedule may be updated', ie. some tables may or may not be updated during the use case. What value is there is stating that? Is there ever a case where this "condition" isn't true? (Don't bother with any of this garbage - check out Cockburn's "Writing Effective Use Cases" for the definitive guide).



Later, we drink the Kool-Aid and are introduced to the miracles of Model-Driven Architecture and Application Appliances Of The Future that "can help organizations that do not have extensive technical knowledge but that need to generate applications using the latest technology". Now everyone can develop an application: just punch in the time, hit Start, and wait. I wonder who sells these wonderous tools... Rational perhaps? This is all wasted space. No mention of real issues, such as changing requirements and how to introduce traceability of original business requirements to the application's design details. At this point, I skimmed ahead and finally quit reading the book.



While I am not suggesting that the authors have not been successful in applying the UML in their lives, I would argue that their instruction is logically inconsistent. In fact, my argument here is not with the examples - that's largely the way it works when it does work - but instead with the rules as defined. If the authors cannot be expected to put together a book that holds true between theory and practice, how can the reader be expected to do so? Are we to say that the authors took liberty and broke the rules in applying their theory to the examples? If so, why? At the end of that question lies a book, because that is where there is real knowledge to be gained by the audience. This is the larger difficulty that most people have in applying the UML: when to follow the rules and when to break them. Experience plays a large part in making sound judgements regarding the UML. This book will celebrate a hollow victory with the reader, a self-help pamphlet where the parameters are tightly constrained and the chance of success is 100%. Basically it is UML T-Ball, and the reader will feel victorious until later attempting to apply these techniques in non-sequential reality, where the only true map of the world looks something like those convoluted UML collaboration diagrams that everyone shuns (and these are shunned for good reason as they provide no use to anyone but the modeller).



Perhaps the underlying problem is that no language is fully descriptive, and that no language ever has hard and fast rules that are true 100% of the time - but if that is the case, the authors should still be able to develop theoretical examples that consistently follow their internal logic and give some underlying reasons why they think those rules are valid, then leave it to the reader to determine when something is appropriate.

UML is still as much an art as a science, and as proof I'd offer the fact that UML - despite industry-wide agreement of it being a Very Good Idea - still has very few native "speakers" who can offer the formula for how to do it successfully. Witness the effort of the two authors with decades of previous success in applying UML (and, as members of the Rational team, much future success tied to the successful application of UML) as they dispense the following:

Rule 1: "Use cases should not describe how the scenario will be implemented." - p.67 (this is the traditional design dogma, that it is even possible to describe a problem in a meaningful way that produces value without first acknowledging some aspect of the solution - see Kovitz's "Practical Software Requirements" for more on this)

Example: The authors offer an example where an actor (Driver) will perform a scenario (Take Trip) which will always include another use case (Fuel Vehicle).

Inconsistency:
* By specifying Driver, haven't we already made some assumptions about the particular implementation - that we are describing a car as the vehicle, and that a vehicle is even necessary to take a trip? Can't the individual just walk?
* Does every occurence require a vehicle to be fueled? What about a trip across town?
* Could this be a bike rather than a motorized vehicle?

Assessment: The point of this use case would be that the value proposition to the "driver" is to take a trip, not the act of driving a vehicle, so therefore it would make more sense to abstract the vehicle out of the equation and therefore break the inclusion of the Fuel Vehicle case.

Rule 2: "[U]se cases should be defined from the viewpoint of the actor that would use them, not from the system's viewpoint" - p.68

Example: A written use case for retrieving records from an archive, where the first step is that the record is locked against update.

Inconsistenency:
* How exactly is a database lock occurring from the Actor's viewpoint? How is this not acknowledging the the eventual system implementation?

Other miscellaneous nonsense:

Statement: "[The use case has ] post-conditions that must be true after the use case is run" - p.80

Example: The use case's post-condition is stated as 'The Records Closure Schedule and Records Destruction Schedule may be updated', ie. some tables may or may not be updated during the use case. What value is there is stating that? Is there ever a case where this "condition" isn't true? (Don't bother with any of this garbage - check out Cockburn's "Writing Effective Use Cases" for the definitive guide).

Later, we drink the Kool-Aid and are introduced to the miracles of Model-Driven Architecture and Application Appliances Of The Future that "can help organizations that do not have extensive technical knowledge but that need to generate applications using the latest technology". Now everyone can develop an application: just punch in the time, hit Start, and wait. I wonder who sells these wonderous tools... Rational perhaps? This is all wasted space. No mention of real issues, such as changing requirements and how to introduce traceability of original business requirements to the application's design details. At this point, I skimmed ahead and finally quit reading the book.

While I am not suggesting that the authors have not been successful in applying the UML in their lives, I would argue that their instruction is logically inconsistent. In fact, my argument here is not with the examples - that's largely the way it works when it does work - but instead with the rules as defined. If the authors cannot be expected to put together a book that holds true between theory and practice, how can the reader be expected to do so? Are we to say that the authors took liberty and broke the rules in applying their theory to the examples? If so, why? At the end of that question lies a book, because that is where there is real knowledge to be gained by the audience. This is the larger difficulty that most people have in applying the UML: when to follow the rules and when to break them. Experience plays a large part in making sound judgements regarding the UML. This book will celebrate a hollow victory with the reader, a self-help pamphlet where the parameters are tightly constrained and the chance of success is 100%. Basically it is UML T-Ball, and the reader will feel victorious until later attempting to apply these techniques in non-sequential reality, where the only true map of the world looks something like those convoluted UML collaboration diagrams that everyone shuns (and these are shunned for good reason as they provide no use to anyone but the modeller).

Perhaps the underlying problem is that no language is fully descriptive, and that no language ever has hard and fast rules that are true 100% of the time - but if that is the case, the authors should still be able to develop theoretical examples that consistently follow their internal logic and give some underlying reasons why they think those rules are valid, then leave it to the reader to determine when something is appropriate.

UML is still as much an art as a science, and as proof I'd offer the fact that UML - despite industry-wide agreement of it being a Very Good Idea - still has very few native "speakers" who can offer the formula for how to do it successfully. Witness the effort of the two authors with decades of previous success in applying UML (and, as members of the Rational team, much future success tied to the successful application of UML) as they dispense the following:

Rule 1: "Use cases should not describe how the scenario will be implemented." - p.67 (this is the traditional design dogma, that it is even possible to describe a problem in a meaningful way that produces value without first acknowledging some aspect of the solution - see Kovitz's "Practical Software Requirements" for more on this)

Example: The authors offer an example where an actor (Driver) will perform a scenario (Take Trip) which will always include another use case (Fuel Vehicle).

Inconsistency:
* By specifying Driver, haven't we already made some assumptions about the particular implementation - that we are describing a car as the vehicle, and that a vehicle is even necessary to take a trip? Can't the individual just walk?
* Does every occurence require a vehicle to be fueled? What about a trip across town?
* Could this be a bike rather than a motorized vehicle?

Assessment: The point of this use case would be that the value proposition to the "driver" is to take a trip, not the act of driving a vehicle, so therefore it would make more sense to abstract the vehicle out of the equation and therefore break the inclusion of the Fuel Vehicle case.

Rule 2: "[U]se cases should be defined from the viewpoint of the actor that would use them, not from the system's viewpoint" - p.68

Example: A written use case for retrieving records from an archive, where the first step is that the record is locked against update.

Inconsistenency:
* How exactly is a database lock occurring from the Actor's viewpoint? How is this not acknowledging the the eventual system implementation?

Other miscellaneous nonsense:

Statement: "[The use case has ] post-conditions that must be true after the use case is run" - p.80

Example: The use case's post-condition is stated as 'The Records Closure Schedule and Records Destruction Schedule may be updated', ie. some tables may or may not be updated during the use case. What value is there is stating that? Is there ever a case where this "condition" isn't true? (Don't bother with any of this garbage - check out Cockburn's "Writing Effective Use Cases" for the definitive guide).

Later, we drink the Kool-Aid and are introduced to the miracles of Model-Driven Architecture and Application Appliances Of The Future that "can help organizations that do not have extensive technical knowledge but that need to generate applications using the latest technology". Now everyone can develop an application: just punch in the time, hit Start, and wait. I wonder who sells these wonderous tools... Rational perhaps? This is all wasted space. No mention of real issues, such as changing requirements and how to introduce traceability of original business requirements to the application's design details. At this point, I skimmed ahead and finally quit reading the book.

While I am not suggesting that the authors have not been successful in applying the UML in their lives, I would argue that their instruction is logically inconsistent. In fact, my argument here is not with the examples - that's largely the way it works when it does work - but instead with the rules as defined. If the authors cannot be expected to put together a book that holds true between theory and practice, how can the reader be expected to do so? Are we to say that the authors took liberty and broke the rules in applying their theory to the examples? If so, why? At the end of that question lies a book, because that is where there is real knowledge to be gained by the audience. This is the larger difficulty that most people have in applying the UML: when to follow the rules and when to break them. Experience plays a large part in making sound judgements regarding the UML. This book will celebrate a hollow victory with the reader, a self-help pamphlet where the parameters are tightly constrained and the chance of success is 100%. Basically it is UML T-Ball, and the reader will feel victorious until later attempting to apply these techniques in non-sequential reality, where the only true map of the world looks something like those convoluted UML collaboration diagrams that everyone shuns (and these are shunned for good reason as they provide no use to anyone but the modeller).

Perhaps the underlying problem is that no language is fully descriptive, and that no language ever has hard and fast rules that are true 100% of the time - but if that is the case, the authors should still be able to develop theoretical examples that consistently follow their internal logic and give some underlying reasons why they think those rules are valid, then leave it to the reader to determine when something is appropriate.

I don't care what the experts say... UML isn't intuitive nor is it "easy" to read. Learning to use it can be intimidating. UML For Mere Mortals by Robert A. Maksimchuk and Eric J. Naiburg is a very nice way to get your feet wet on the subject...

Chapter List: Introduction to the UML; Business Models; Requirements Modeling; Architectural Modeling; Application Modeling; Database Modeling; Testing; Is That All There Is?; How Do I Get Started Using The UML?; Where Can I Learn More?; Glossary; Answers To Review Questions; UML Diagrams and Elements; Index

I've read a few books on UML, and it's pretty easy to get bogged down in all the rules and minutiae. UML is one of those things that can have the experts arguing about fine distinctions that you'll never experience in your working career. In this book, you can forget all that. The authors don't try to teach you absolutely everything there is to know. The goal is to focus on practical usage and cover those things that you'll most likely run up against in real life. And in my opinion, they nail that goal. Most of the subtopics within each chapter have a topic heading that is a question. The questions are ones that you'd encounter as an actual student of UML (like how do I model my business using the UML?), and that tends to make sure the subject matter stays practical and useful. There are also a number of very good sidebars that cover lessons learned, real world experience, things to watch out for, and "deep dive" items that cover things in a bit more depth. There are even review questions you can use to see how much you've retained. All in all, a good format and packaging of the material.

This is the first "Mere Mortals" title I've read, and I don't think it will be my last. I see this as being a book that you'd use to get up to speed quickly on a subject. It could also be used to learn what you don't know. If I knew nothing about UML, this book, read straight through, would give me the context for everything else I need to learn. Books like that are really valuable, and this one would be a great addition to your UML bookshelf if you need to go in that direction...

The book is an excellent introductory for business and project managers who are working on projects with architects, analysts, and developers using the Unified Modeling Language for software architecture and design. The book although good for developers and architects as an introduction to the UML, those readers will need a followup resource for in depth hands-on use of UML for system and application architecture and design.

"UML for mere mortals" is a very creative book, with great examples, that makes UML easy and fun to learn!
This is a must read book for all those who are being introduced to UML or are looking for UML 2.0 updates!

Really easy to read... I enjoyed the way they link UML 1.X to UML 2.0!
All the modeling essencials for software intensive systems are covered in this book... And it also presents a wide approach for UML modeling, from Business Modeling through Testing!

"UML for mere mortals" is a very creative book, with great examples, that makes UML easy and fun to learn!
This is a must read book for all those who are being introduced to UML or are looking for UML 2.0 updates!

Really easy to read... I enjoyed the way they link UML 1.X to UML 2.0!
All the modeling essencials for software intensive systems are covered in this book... And it also presents a wide approach for UML modeling, from Business Modeling through Testing!

The sheer number of books on UML is simply amazing, and it seems like finding a right one for you is a task all into itself. No matter whom you want to become, a hardcore UML modeler or a weekend reader feeding one's curiosity, the book "UML for Mere Mortals" is a great way to start. The main and important topics are covered, and the details are left untold. That's perfectly ok, since even the UML professionals don't refer to all aspects of UML due to its complexity. Simple UML diagrams are easy to grasp, but UML for large projects get very complicated, making the users of UML stick to common diagrams in order to get the point across more easily to readers. What is the point of a complex and intertwined diagram if you are the only one that can read it?

It is crucial to keep in mind that the goal is to model your enterprise in order to have a common language across all aspects of business via which everyone can communicate. What is the point of accomplishing this task if no one else in your enterprise can understand what you are trying to say? You have accomplished nothing, and only wasted away hours of work. The authors of the book have this mentality in mind when they are talking about UML. They start with basic stuff such as Business Modeling and Business Use Cases: a top-down approach if you will. The fact of the matter is that UML can readily model all aspects of an enterprise from what is called Business Use Cases all the way down to how each executable piece of software is deployed.

After Business Modeling has been accomplished, it is onto requirements modeling with Use Cases. A Use Case driven process, where your capture your requirement solely using Use Cases has shown to be the best way to start a new project. The concept of "separation of concerns" fits perfectly into this methodology, and there are a number of books that talk in detail about it. After capturing your requirements, it is now time to get working on the Architectural designs using Class Diagrams, and think a bit about deployment and component diagrams. A more difficult task is to model your application, and not only pieces of it. After wrapping up with Class Diagrams, the authors show you how to go about modeling your entire application. It is a difficult task, but the authors break it down to easy to chew off pieces for the reader.

Database Modeling and Testing are probably my two favorite chapters in this book. These are topics that one would normally not think about when thinking about UML, but the authors show that it is not the case. In fact, modeling your database with UML will enable all your team members to have a common language (that phrase again!), and maybe even reuse components from each others design. The same goes with testing. Authors suggest that the QA team should take the Use Case and Architectural Models and start working on test cases while the development is taking place. This is a great idea as you catch bugs early in the process and the cost of fixing them is very small comparatively.

UML for Mere Mortals is an easy and quick read. If you want a book to refresh your UML skills over the weekend, or you are new to UML and need to know the essentials fast, this is the book to read.

The sheer number of books on UML is simply amazing, and it seems like finding a right one for you is a task all into itself. No matter whom you want to become, a hardcore UML modeler or a weekend reader feeding one's curiosity, the book "UML for Mere Mortals" is a great way to start. The main and important topics are covered, and the details are left untold. That's perfectly ok, since even the UML professionals don't refer to all aspects of UML due to its complexity. Simple UML diagrams are easy to grasp, but UML for large projects get very complicated, making the users of UML stick to common diagrams in order to get the point across more easily to readers. What is the point of a complex and intertwined diagram if you are the only one that can read it?

It is crucial to keep in mind that the goal is to model your enterprise in order to have a common language across all aspects of business via which everyone can communicate. What is the point of accomplishing this task if no one else in your enterprise can understand what you are trying to say? You have accomplished nothing, and only wasted away hours of work. The authors of the book have this mentality in mind when they are talking about UML. They start with basic stuff such as Business Modeling and Business Use Cases: a top-down approach if you will. The fact of the matter is that UML can readily model all aspects of an enterprise from what is called Business Use Cases all the way down to how each executable piece of software is deployed.

After Business Modeling has been accomplished, it is onto requirements modeling with Use Cases. A Use Case driven process, where your capture your requirement solely using Use Cases has shown to be the best way to start a new project. The concept of "separation of concerns" fits perfectly into this methodology, and there are a number of books that talk in detail about it. After capturing your requirements, it is now time to get working on the Architectural designs using Class Diagrams, and think a bit about deployment and component diagrams. A more difficult task is to model your application, and not only pieces of it. After wrapping up with Class Diagrams, the authors show you how to go about modeling your entire application. It is a difficult task, but the authors break it down to easy to chew off pieces for the reader.

Database Modeling and Testing are probably my two favorite chapters in this book. These are topics that one would normally not think about when thinking about UML, but the authors show that it is not the case. In fact, modeling your database with UML will enable all your team members to have a common language (that phrase again!), and maybe even reuse components from each others design. The same goes with testing. Authors suggest that the QA team should take the Use Case and Architectural Models and start working on test cases while the development is taking place. This is a great idea as you catch bugs early in the process and the cost of fixing them is very small comparatively.

UML for Mere Mortals is an easy and quick read. If you want a book to refresh your UML skills over the weekend, or you are new to UML and need to know the essentials fast, this is the book to read.

This book was written for managers in need of knowledge concerning the return on investment (ROI) of using the UML in their software development projects. It is not a compact, diagram-laden book of detailed descriptions of how the UML is used to represent the actions of software. Most of the explanations are in text; drawings are used more as an emphasis tool rather than as an initial descriptor. The explanations are very readable, much more common-sensical than technical.
How the UML is used throughout the entire product lifecycle is covered, from describing business models to modeling the testing process before release. At the end of each chapter, there is a list of key terms, a summary and a short list of review questions. Most are T/F or multiple choice and the solutions are included in an appendix.
As long as you use it for the purpose for which it was designed, this is a very good book. You can't use it to learn how to use the UML to precisely model your projects, but you can use it to quickly understand the value you can obtain from using it. I strongly recommend it for all stakeholders in a project where they do not have to actually build the software. I included it as one of the best books of the year 2004 in my yearly column in the online Journal of Object Technology.

This book was written for managers in need of knowledge concerning the return on investment (ROI) of using the UML in their software development projects. It is not a compact, diagram-laden book of detailed descriptions of how the UML is used to represent the actions of software. Most of the explanations are in text; drawings are used more as an emphasis tool rather than as an initial descriptor. The explanations are very readable, much more common-sensical than technical.
How the UML is used throughout the entire product lifecycle is covered, from describing business models to modeling the testing process before release. At the end of each chapter, there is a list of key terms, a summary and a short list of review questions. Most are T/F or multiple choice and the solutions are included in an appendix.
As long as you use it for the purpose for which it was designed, this is a very good book. You can't use it to learn how to use the UML to precisely model your projects, but you can use it to quickly understand the value you can obtain from using it. I strongly recommend it for all stakeholders in a project where they do not have to actually build the software. I included it as one of the best books of the year 2004 in my yearly column in the online Journal of Object Technology.

This is an interesting book in that it looks at modelling from a fairly high level. It is intended for business people who are responsible for improving their business's market position and are using software development as a key component in addressing the business goals, analysts who are responsible for creating system requirements to address the needs of the business, managers who need an understanding of what modelling can do for their projects, primarily software, but also in other areas such as database utilization, programmers who don't know UML but who must implrement the systems that are specified in UML. It is specifically not for the UML programmer who will need a more complete text to do the actual UML work.

I would add that this is also a suitable book for the beginning UML programmer who can use this book as a good introduction to what UML can do. This kind of thing is often left out of the beginning of the more serious texts.

This is part of the For Mere Mortals series. The intent of this series is to present information on important technology topics in an easily accessible, common-sense manner. This book meets this intent in every way. The writing style, the content, the tone is ideal. The positioning of the book in the middle of the manager and the tekkie is what is truly outstanding.

Even though software engineering has been around for about half a century, not many people still appreciate the value of 'visual modeling' in software systems development. Something even more surprising is the lack or awareness about UML, the industry-standard notation for modeling since 1997.
The authors have done a marvelous job in attacking these two issues directly. UML for MM covers the essentials of UML in a simple style while enlightening the reader about the importance of visual modeling.
Starting with business modeling they take you right across the software life cycle covering requirements modeling, architecture modeling, application modeling and database modeling. Chapter on testing explains how UML models can be used for effective testing. Moreover, the book gives a very broad view of the state of the art covering UML 2.0 and MDA. The many sidebars present the authors' vast experiences nicely.
I would give 5 starts for this book because the authors have successfully achieved their purpose of introducing UML to stakeholders who are NOT hard-core modelers. Readers will also get an appreciation of how valuable 'modeling' is for complex systems.