UML 2 And The Unified Process: Practical Object-Oriented Analysis And Design 2nd Edition

I want to give this 3 stars instead of 4, but that's only because I hate tedious diagramming. Program first and use Doxygen (or dozens of other tools) to produce accurate enough auto-generated diagrams. The diagram method of doing things should be dead if it isn't dead. My professor became vindictive and ruined my otherwise accomplished academic career because I told him about a survey by a leading proponent of the Unified Process and UML that revealed how little the software development industry actually uses the majority of UML and widely regards it as not worth the trouble. With all due respect to object-oriented philosophy and the Unified Process, it tries to get metaphysical and in the process overcomplicate something that is much easier to explain in code and greatly truncated jargon. All the same, I think the authors did a very good job of explaining and covering the material---infinitely better than my former university's curriculum authorities and professor.Objects are everywhere and learning to conceptualize them and the idea that I should send a scouting party ahead through the various phases of the SDLC were not new to the Unified Process, but merely seemed new as a biproduct of practitioners' rigidity to waterfall stages. I think that tedious diagramming languages exist to inflate billable hours. The argument that the stakeholders within the organization demanding software will understand UML naturally is horses***--people understand flow charts without training. UML is poorly executed even by those with formal training in it. The class I took that focused on it had students doing half-assed and yet horribly time-consuming work to produce diagrams that I would find superfluous to an efficient SDLC. Give me a spreadsheet and a seriated list. My preferred method of diagramming is to use Business Process Modeling and an ERD that reflects entity clusters, supertypes, and subtypes. I like to overlap the two. Even if I'm not using a database, this achieves the goal of informing a stakeholder about the translation of their business processes into software in a way that is more intelligible without training. It satisfies them that I know what I'm doing. What the hell good does this do when I'm trying to describe classes and subclasses for something that isn't some type of MIS, DSS, or ES? Well, that's when I just write classes and then maybe borrow a sequence diagram from UML and I do that textually and have PlantUML generate it. When I'm working on defining a user-interface, I just prototype the damned thing--interactively. In the age of numerous ways of interactively prototyping an interface, why in the hell would I want to throw hundreds if not thousands of manhours away on diagrams that obfuscate much and elucidate little. The difficulty of diagramming without expletive-inviting tedium causes people to make diagrammatic shortcuts (omitting much, creating templates that might never be reused where a procedural function might suffice or even perform better, or forcing the concept to fit the abstraction demanded by the philosophy).I apologize that my bitching here is inspired by the way the class I took (this book was 'suggested' reading, but time was not allotted for doing so on the syllabus) presented the material: objectFactory(), objectFacade(), and objectEcetera(). What methods lay within an object? Well, just name the objects and the methods and imagine that there's something inside the damned things and lets make diagrams that are either accurate and require more hours than there are in a week to produce singlehandedly or so barren of detail that they serve no purpose other than to say, "I know UML in a skindeep way, now pay me $100,000 per year like that article said some poor ignorant bastard would." For every person that knows what a use-case diagram is, there are n/1,000,000 that know that a use-case diagram is a best practice that the OMG does not consider true UML and that the use-case diagram is the only 'part of UML' that most people consider worth the time. It features a seriated list. Roughly 13% of respondents to Mr. Wampler's survey thought that metaphysical hieroglyphs over-explaining how to design classes and under-explaining how to implement classes were a good use of their time.For this, my last chance at a sheepskin is dead and the debt weighs heavily upon me. So, I hate UML. Bilingual conversations are not necessarily optimally productive--pick the language to have the exchange in instead of being pretentious. Sure, I can use a CASE tool to specify and program MOST of an application in UML, but that is programming by superstition and I have to trust that my diagrams were accurate and that the CASE tool vendor and I can communicate inerrantly through this tedious-as-hell input abstraction. Meanwhile, I can type and document textually and have whatever code I write be in the same language I'm going to have to trouble-shoot (two languages vs. three). How two languages instead of (at least) three? Writing in C++ plus documenting in English (two languages) vs. specifying in UML and English (and possibly any additional language spoken by my offshore development team), troubleshooting in C++ (or Java), and in-line commenting in English (and what other language that might be used natively by an offshore development team). Which seems more prone to project failure? My native programming language and my native English--generating any human language independent documentation on the back side using Doxygen? Or involving a CASE tool vendor, a delicately nuanced modeling language that seems no more effective than a team-agreed upon Made Up Modeling Bloviation Language Exposition (MUMBLE). If a team does not truly understand UML, then they're only adding expense to the process. I think functional decomposition as described by seriated lists and some means of conveying communication, sequence, and state by using a database and a report (whether visual or not) is faster and the OMG supported a simular tabular approach to documentation in SysML based on a paper published by two Drexel University scholars in 2006 (I forget their names and the title of the paper, sorry). UML seemed forward thinking in the early 90s, but now--like too damned much of my former university's decently-ranked and regarded curriculum it is too old-fashioned for junior-level jobs and shops founded after the dot-com bubble burst. Now I'm stuck in debt with no degree and only the hope that I can strike it rich with software to satisfy an undiscovered (or underexploited) collection of use-cases.UML did not ruin my life single-handedly and it wasn't this book's fault, but demonstrative that this was a 'suggested' book while the school's crib notes and pollyannaish exercises superceded it. UML and object-oriented philosophy makes what might be demonstrated easily pompous through bloviation and meta-bloviation--removing these two I think the Unified Process has many valid points.

I would have titled this book the other way around, i.e. "The Unified Process and UML2", as it literally maps the UML building blocks to the UP core workflows: Requirements, Analysis, Design, Implementation and Test.The book starts with an introductory Part 1 in which the authors provide short summaries of UML and UP. Then, follow 4 parts of several chapters each, that cover the first four UP core workflows in the order listed above. Last part, Part 6, titled Supplementary Material, includes an introduction to OCL (Object Constraint Language).The coverage of the UP core workflows goes well beyond the simple mapping of building blocks, as the authors provide step-by-step, comprehensive guidance on how the fulfill the workflow's objectives through UML. Options are discussed, pitfalls addressed.UML syntax/notation and OO concepts are reminded in the book as necessary, but this is neither an UML nor an OO tutorial. Basic knowledge of both is a prerequisite. I read this book right after the UML User Guide.What I liked most is the clear, direct, accessible language this book is written in and the comprehensive coverage of UP through UML it provides. I also liked the "What we have learned" section that summarizes each chapter and the introduction to OCL.What I found to be lacking, however, is the coverage of the last UP core flow listed above: Test. Surprisingly, the book stops at Implementation. Knowing the importance of testing as a configuration controlled set of tasks usually divided into Unit, Integration and Validation Tests and taking into account the test software and stubs created for such purpose - not part of the application -, I believe this workflow should have been addressed, at least, with regard to versioning, test case management and test software/stubs interfacing with the components of the actual application.I would also recommend the authors to drop the Book Roadmap and Chapter Roadmaps they provide at the beginning of the book and of each chapter in form of UML Activity Diagrams. This book is not a reference manual. It deserves linear reading, from the beginning to the end, at the reader's own variable pace depending on the comfort he/she experiences going through the various chapters and sections that make it up.Overall, this is a very good book that I can recommend.

I am currently taking a software engineering course and this books as helped a ton in UML. I looked at various of videos but they didn't cover the level of detail this book does. It is also a very easy to read book and easy to follow. Highly recommended for anyone learning UML.

good for for learning about UML. I bought because I had to for a class in the University, but didn't see it all. I had a bad teacher, but with a good one, or even learning by yourself, its a good book to learn the UML ways.

Learned a great deal from this. Most development or development process texts are torture to read, to be sure, but was actually able to glean quite a bit from this text...

I have come across many books so I could learn how to understand UML and UP. But this one book is really giving me the necessary knowledge to begin with UML and a methodology to drive a development process. I just love it.

Topics are well explained.

arrived in new condition

Having recently read Craig Larmen's: Applying UML and Patterns, I wanted a book that could help me better understand how to use UML to accurately model and design systems - in particular object oriented software systems. This book has exceeded my expectations.This book is nearly 600 pages thick, but the contents is densely packed with useful information. It is a comprehensive book that not only explains UML in depth and with clarity, it also explains in detail how these diagrams can be used effectively in the development and design of software systems. Most importantly it tells you how to make UML useful, meaningful, and understandable.The book is well structured. I am reading this book cover to cover, and each chapter is logical and well thought out. It leads you through the Unified Process from requirements gathering to implementation and deployment - and tells you what aspect of UML should be applied through each of these stages. It also provides you with summary tips and notes in the side margins to help highlight important points and ideas.The main focus and topic of this book however is fleshing out the problem domain - finding key candidate classes, operations, relationships etc. As well as how to use the information and elaborating it for the design of the final system i.e. refining the diagrams to include greater detail for implementation, incorporating design issues, outsourcing etc.This book is mainly for those who want a better understanding of how to use UML to design software systems (in a visual manner - diagrams). Or those who look at UML diagrams with confusion and want a better understanding about what they mean - and ultimately how to construct your own.A word of warning, this book does take a while to get through. Set yourself at least a week or two for a thorough reading. But I assure you, the time will be well invested.In the end I am glad I bought this book. If there is one regret I have about this book, it is that I wish I had discovered it sooner!

I've been a business/systems analyst for about 12 years, and read about 2-3 books a year to keep upto date. I went on a UML course, and this book was recommended by the course tutor.I think its one of the best UML books I've ever read (and I've read about 20), and indeed one of the best books on analysis I've ever read. What I really like about it is that there are lots and lots of example models, so you're left in no doubt about what the message is and you get to see lots of ways of modelling scenarios.I will definitely be reading their next book.

I have read a few UML books in the past and found myself occasionally struggling with some of the many model types and syntax when trying to model with UML, however this book shows how the whole thing fits together. A recommended read.

Looked like new. Faultless

I was very impressed with the quality of this book. It was worth the price, better than buying the same book at a higher price just to get a new copy. This looked like a new book.