UML Distilled: A Brief Guide to the Standard Object Modeling Language (Anglais) Broché – 15 septembre 2003
|Neuf à partir de||Occasion à partir de|
Les clients ayant acheté cet article ont également acheté
Descriptions du produit
Présentation de l'éditeur
Pressured with tight deadlines, application developers do not have the luxury of keeping completely up-to-date with all of the latest innovations in software engineering. Once in a great while, a tremendous resource comes along that helps these professionals become more efficient. The first two editions of UML Distilled have been perennial best-sellers because of their concise, yet thorough, nature. This eagerly-anticipated third edition allows you to get acquainted with some of the best thinking about efficient object-oriented software design using the latest version of the industry-standard for modeling software: UML 2.0. The author has retained the book's convenient format that has made it an essential resource for anyone who designs software for a living. The book describes all the major UML 2.0 diagram types, what they are intended to do, and the basic notation involved in creating and deciphering them. A true treasure for the software engineering community.
Quatrième de couverture
- Would you like to understand the most important elements of Class diagrams? (See page 35.)
- Do you want to see the new UML 2.0 interaction frame notation for adding control flow to sequence diagrams (see page 58) and the unofficial notation that many prefer? (See page 60.)
- Do you want to know what changes have been made to all versions of the UML? (See page 151.)
- Do you want a quick reference to the most useful parts of the UML notation? (See the inside covers.)
- Do you want to find out what diagram types were added to the UML 2.0 without wading through the spec? (See page 11.)
More than 300,000 developers have benefited from past editions of UML Distilled. This third edition is the best resource for quick, no-nonsense insights into understanding and using UML 2.0 and prior versions of the UML.
Some readers will want to quickly get up to speed with the UML 2.0 and learn the essentials of the UML. Others will use this book as a handy, quick reference to the most common parts of the UML. The author delivers on both of these promises in a short, concise, and focused presentation.
This book describes all the major UML diagram types, what they're used for, and the basic notation involved in creating and deciphering them. These diagrams include class, sequence, object, package, deployment, use case, state machine, activity, communication, composite structure, component, interaction overview, and timing diagrams. The examples are clear and the explanations cut to the fundamental design logic.
If you are like most developers, you don't have time to keep up with all the new innovations in software engineering. This new edition of Fowler's classic work gets you acquainted with some of the best thinking about efficient object-oriented software design using the UML--in a convenient format that will be essential to anyone who designs software professionally.
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre adresse e-mail ou numéro de téléphone mobile.
Détails sur le produit
En savoir plus sur les auteursDécouvrez des livres, informez-vous sur les écrivains, lisez des blogs d'auteurs et bien plus encore.
Commentaires en ligne
Meilleurs commentaires des clients
C'est ausi sa faiblesse, si l'on cherche une information très détaillée.
Commentaires client les plus utiles sur Amazon.com (beta)
The biggest issue is that the author has too many non-standard diagrams. These are helpfully labelled "non-normative", and are an odd mix of UML 1, UML 2 and some other bits and pieces that the author likes. Now what is the point of this? These diagrams won't be supported by UML 1 tools, or by UML 2 tools, so how is one to draw them? Also, the non-normative diagrams do not have a metamodel or any well-defined semantics, so even if one were to build a tool to support their syntax, their semantics would still be open to debate.
The next issue is that many of the UML 2 diagrams are syntactically incorrect (e.g. the use of dependencies rather than connectors in composite structures). Perhaps this is because the author was writing the book while the UML 2 specification was still being developed. Personally, I would rather he had waited a bit rather than give us something only partially baked.
The discussion of UML syntax implies that UML as a visual language is much less powerful and complete than it actually is. For example the very brief discussion of sequence diagrams misses out most of their important new features. You don't learn about combined fragments, references, gates or parameters (although some of these are mentioned in passing). Yet these are the things that make UML 2 sequence diagrams so much more powerful and useable than they were in UML 1. In fact, the sequence diagrams in this book look like they have been translated directly from UML 1 sequence diagrams without applying any of the new features.
The discussion of UML semantics is generally disappointing. UML 2 has tied UML semantics down very tightly - it has had to do this because of MDA. However, in this book you get the impression that much of it is still quite vague and open to interpretation - hence the "non-normative" diagrams.
On the whole, the level of detail is, in many cases, too low to be useful even in a "distilled presentation". For example, you get 2 pages on interaction overview diagrams, and in this you lean that the author hasn't really worked out how to use them effectively and doesn't really care for them anyway. Yet these diagrams are important. They give us, for the first time, the ability to string together isolated interactions into workflows in a precise way.
On the whole, I can't recommend this book. Try "UML 2 for Dummies" instead.
For example, Martin tells readers that you should focus more on text description other than UML use case. Also, for the other example, in Chapter 14 Component Diagrams, it is full of Martin's opinion about how to use Component Diagrams without telling readers what is the definion of Component Diagrams.
If you are a new beginner of UML, go back to buy 2nd edition. If you are the readers of 2nd edition and would like to know Martin's experience, then 3rd edition can be a better choice.
Fowler, in this book, reminds me of a good instructor who starts a course very well, but at the end of the semester he just wants to finish all the topics carelessly.
The first eleven chapters are great and very well done, but the problem starts at chapter twelve, specifically when he tries to explain the "Composite Structure Diagram" and the usage of Ball-and-Socket notation in Component Diagram. He fails to do the job, however later on in his blog he tries to justify some of his mistakes. you can find the discussion under Ball-And-Socket post.
Another minor mistake is on page 89, when he confuses the concept of the namespace in .Net. I have seen that most of the people with Java background are confusing the "namespace" concept in .Net with "package" in java. Namespaces in .Net have nothing to do with access modifiers. I believe the more equivalent of packages in java are assemblies in .Net and for the Package diagram in UML one should consider an assembly as an equivalent to a package in the diagram.
The first two editions of the book were very successful, and after releasing the UML 2.0 a new edition, which covers the new elements in UML 2.0, was needed, but it seems Fowler was very busy at the time and he just wanted to upgrade the book in two or three days.
I have been working in the OOAD+J2EE+UML space for the last 3 years in the capacity of an Architect. Before this, though I have read few books on OOAD and Patterns, I hadn't read any book written exclusively on UML. In the large project I was part of, we used Use case diagrams, Sequence diagrams, Class diagrams and on certain rare occasions Activity diagrams.
You repeatedly come across comments such as concise, a very brief introduction, quick reference, compressed, direct in the reviews of this book. Frankly, it is all that. Let me give you chapter-wise impressions book before presenting my summary.
Chapter1: This chapter gives a decent introduction to UML, a reasonable tracing of its history and places UML in right perspective.
Chapter2: My favorite. Gives a classic snapshot of RUP. I infact used some of the lines for a presentation I had to do on RUP to my managers!!
Chapter 3: You get a very brief overview on Use Cases. It was nice to know certain esoteric features related to Use Case relationships. Watch out for the short 'n sweet synopsis on the differences between BUCs and SUCs.
Chapter 4: The author introduces you to the three perspectives while drawing class diagrams: Conceptual, Specification and Implementation. I seriously doubt whether we can engage our users into drawing conceptual diagrams!! Specification Modeling is what we do during the design phase. The sub-sections on Associations, Attributes, Operations, Generalization and Constraint rules are extremely well written. Though the side-bar on Design by Contract comes out a little sketchy.
Chapter 5: I doubt whether I'll ever use collaboration diagrams given the bias I have for sequence diagrams. The wealth of information that comes out of analyzing the sequence diagrams produced by designers is simply amazing.
Chapter 6: I found the sub-sections on Stereotypes, Object diagram, derived association and attribute, interface and abstract class, qualified association, association class, parameterized class, visibility to be too brief. But I found the sub-sections on reference and value object, Multiple and Dynamic Classification, aggregation and composition to be immensely useful and it brought out the wealth of experience the author possesses in no uncertain terms. I might have to re-read these sub-sections many times to get the essence.
Chapter 7: This chapter totally disappointed me. My personal opinion is, Robert C. Martin's papers on packaging are far more superior to what Martin Fowler has dished out on packaging in this chapter.
Chapter 8: The usage of state diagrams is very limited given that it traces the behavior of a single object across multiple use cases and should be used only with objects showing very interesting behavior. The author's treatment of State diagrams is competent.
Chapter 9: This chapter on Activity diagram is brilliantly handled by the author. Though the author confines the usage of activity diagrams to the construction phase, I find them increasingly getting used during the elaboration phase as well.
Chapter 10: I have a very low estimate of Physical diagrams and wouldn't want to comment upon this chapter.
Chapter 11: This chapter left me with mixed feelings. I found it to be good in that it takes you through different class diagram perspectives using the patient observation system. It is bad in that the solution is way too twisted that it leaves in you splits.
Let me summarize in parts:
What I liked: It delivers what it proclaims and I don't have any qualms against it being short, concise and compressed. I liked the informal+ direct + to-the-point style of the author and his 'me-myself' tone.
What I didn't like: It can easily give one a false notion of having mastered the subject when the reality might be far from that. It is not a book reading upon which you can set about your UML related tasks with ease. At best, it is a good reference book. It glosses over too many important subjects. At places, I find him not making a definitive statement when one is actually expecting one from him. Discussion on topics such as Design by Contract, CRC, Refactoring on which exclusive books are written come out thin and a trifle out of place.
This is, by intent, a very brief book about a very large topic. Part of its value is in giving the quick tour without dragging the reader through the thousands of pages of OMG specifications. That means a lack of rigor, reinforced by the informal writing style - all very approriate to an introduction.
The UML can be intimidating in its mass and in the level of detail it prescribes. Fowler cuts through all that very well. Best of all, he keeps a slightly skeptical tone. The UML is a tool, meant to serve the developer. It is not intended to take over the development process, so don't let it.
There are just two things I wish this book decribed better. First is the unification problem. The UML offers dozen or so different representations of different aspects of a program's structure and behavior. The question is, how do I get all those representations to relate to each other so it's clear that they describe the same thing? The complete answer may be too long for this book, but this isn't a book about complete answers. A few more clues would have strengthened the discussion.
Second is the discussion of state diagrams. It's a concept that beginners seem to stumble over: what do states really model? The best answer I know is that it describes situations where one input elicits different responses at different times, in different operating modes. The number keys on an ATM keypad are an example: first they represent the PIN, then they choose the banking operation to perform, then they may represent the numeric dollar amount of a transaction. Fowler just says to use state diagrams for "interesting behavior."
It's a good intro to UML with a good (though aging) bibliography. It should not be your only book on UML, but never meant to be. Beginners get a gentle start to a tough topic. Seasoned users can jog their memories on fine points of notations they haven't used in a while. This book really is for everyone.