Slashdot Mirror
Teach Yourself UML in 24 Hours
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 GoodTeach 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-GoodPart 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.
ConclusionNow, 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.
The problem with UML is that it doesn't really help to be pretty good with UML.
If everyone isn't completely proficient, you're back to square one, ambiguity, miscommunication of ideas, all the stuff that you're trying to avoid by using by UML.
Having said that, be aware that this the view of a computer artist that does some programming, not a dyed-in-wool enginner.
What were you expecting?
psxndc
The emacs religion: to be saved, control excess.
The review mentions a void for beginning UML books. I think the void is filled quite well by UML Distilled by Martin Fowler and Kendall Scott. It provides an excellent, concise explanation of what UML is, how to use each UML artifact, and why you should care. Good for the beginner or those with short attention spans.
She came sliding down the alleyway like butter dripping off of a hot biscuit.
I don't find that class diagrams communicate anything that I can't understand better with a description in text, or other methods.
Yep. UML is a way for poor communicators to pretend to design. UML diagrams are notoriously bad at factoring in real-world requirements, exceptions, usage patterns, and user scenarios. In every case I've seen UML used for modeling, it has created systems which looked clean in the diagrams but which failed to function usefully once implemented due to lack of conceptual underpinnings. It will be nice to see this particular documentation fad slip beneath the waves, and people get back to describing what they want to do in thoughtful paragraphs.
Tim
The last place I worked required us to design in UML first. The only reason for this was because the customers for whom we were writing software required that we impress them with fancy documentation and diagrams.
I am now working on several projects all by myself. When I am working on something complicated enough where diagramming it out helps me visualize the scope, I find myself using my old shorthand instead of UML, since I am the only one who is looking at it. However, I have found it very useful to know UML when working in teams and they aren't getting what I am saying. If everyone understands UML, then we can communicate. The only other use for it is to impress management or give you some extra interview points.
Many years ago, using flow charts was a requirement in many software jobs. (For those of you less than 40, a flow chart was a stylized picture of small-scale flow control: little diamonds for "if", square blocks for computations, other funny shapes for IO, etc. All connected by arrows.) Flow charts were pretty useless, but you had to produce them, so we built tools that parsed Fortran77 and generated nice flow charts. No one actually used them, but they looked nice hanging outside your office, especially if you had access to a color flatbed plotter.
Now, I know that Rational can generate UML from code. Which makes me wonder how often UML is actually used for design and how often it's generated after the fact to make pointy-headed managers happy.
Disclaimer: I'm doing researches in UML.
First of all, it is NOT enough to employ only one diagram of UML. You have to use MULTIPLE diagrams to describe particular traits. So, class diagram must be accompanied by at least one of the behavioral diagrams such as state chart diagrams or collaboration diagrams.
Read the official UML books and you'll discover that there are three dimensions on the diagrams: structural, behavioral, and architectural. Any sufficiently large project should employ at least one of the diagrams that fall into each of the category to capture its holistic aspect.
The valid complaint is that the UML diagrams lack of coherence and details. For example: I found out that the three books (UML User Manual, UML Reference Manual, and the official UML Spec) are NOT consistent. Don't flame me on this. If you want to know, just find out about the event handling in state charts. Scutinize them in details. All three doesn't agree each other.
Lack of details hampers researches in this area. For example in state charts, how would you handle events? They say: Designer should not assume one. How can? The handling could dramatically alter the behavior of the state charts, whether it is buffered, channelled, direct, etc.
Because there is lack of details and coherence, you will find out that virtually ALL researches that claim using UML doesn't really have 100% UML conformance in it. Everyone assume their own form of UML, especially when there are no governing details.
--
Error 500: Internal sig error
Expecting to become an analyst by teaching yourself UML is like expecting to become an author by teaching yourself English.
Learning UML is a necessary, but not sufficient, step. The important thing to understand is object-oriented analysis. UML is just a tool (and a flaky one in some respects).
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
UML is the language, not the essay. If you don't know what you want to say, any language will do - but if you do know what you want to say, at least in Software Design - UML gives you a way of describing it precisely.
In my current organisation, we took a couple of "difficult" projects, where the customer's needs weren't clear, and converted them over to UML. The results were amazing. In one case, we were able to make the customer gain a new appreciation of the complexity, and could re-negotiate the contract. In another scenario, we saved a huge amount of time in "usability" design, where software features were grouped around business workflows.
Where it failed - and consistently failed - was in teams where everyone did not switch over to UML (or converted under duress). We had cases where developers would rewrite the explicit instructions of UML into plain English, and loose the level of detail in the design.
If you want a real example of the power of UML, have a look at Argo UML. The tool really takes UML one step further, allowing you to see the Java code generated, and do full roundtrip in a single editor.
English is an imprecise language, and is very unsuited for expressing program functionality. It's even worse for documenting requirements. Thats where UML fits in, and in MHO, it does work.
UML is a way for poor communicators to pretend to design.
I couldn't disagree with you more. Class diagrams reflect only a static view of a system design. There are a whole slew of other modelling constructs that depict the dynamic nature of a software system, including statecharts, activity and interaction diagrams. These can be used to model the potential interactions between components, and use cases for modelling user interaction.
In every case I've seen UML used for modeling, it has created systems which looked clean in the diagrams but which failed to function usefully once implemented due to lack of conceptual underpinnings.
The only explanation for this is poor design! Don't blame it on UML. One of the biggest failure points of software projects is failing to adequately document functional and non-functional requirements. You can design/document all you want, but if you don't fulfill the requirements, you are doomed to failure.
Very true. I work for a "startup" (been around for a few years, but only a small team of programmers) and we hired a project manager who came from a large company. He used the UML extensively to document the system design. He then made the mistake of using these UML diagrams as a major part of his documentation "deliverables" to the client, assuming that a picture is worth a thousand words. They didn't even look at these diagrams which he had invested so much time in, and insisted on written documentation. He was unable to produce alternate documentation to their satisfaction, spent way too much time trying to do so, went WAY over budget (remember, small company, small budget), and in the end, the client was still very dissatisfied with his work, and the company fired him.
He was a very intelligent, capable project manager (at least at a large company), but the cost of full-blown modelling in a small company with limited resources and limited budget just isn't worth it. Based on my second-hand experience, I'm tempted to say that UML modeling costs MORE on smaller projects / at smaller companies.
If a visual description is necessary, the next best alternative to the UML is a large whiteboard, some colored markers, and your own imagination. If anyone doesn't get what you are describing visually, you will get immediate feedback, and you won't be as likely to alienate your audience with self-evident-by-virtue-of-being-UML jargon.