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.
I wonder are there really that many UML users who actually use it for everyday design and deployment requirements? For some reason, It just feels like a language invented to get Rational its share of market. Microsoft did that with VB and C#, Sun did it with Java, and Rational did that with UML so that they can sell more Roses..
Well, Good for them.
As a software developer I know uml reasonably well, and have tried to use it, but I find that I have big problems with it.
For example I don't find that class diagrams communicate anything that I can't understand better with a description in text, or other methods.
I don't want to get into what other methods I use here as it's not on topic really, but I *really* want to like uml and find it useful, but beyond quick back-of-envelope class diagrams to sketch out a subsystem I so far have not found it useful.
Do other people have this problem too? Does anyone actually *use* it in more than a trivial way? Everywhere I've worked, people want to use it, but never quite manage to. This isn't to say that proper design isn't done, just that uml isn't used much.
Should I just keep at it until it becomes so familiar that I think in UML rather than any oher way?
Sig is taking a break!
XML is more of a Data description language. UML is more of a Design and prototype description language. XML, You can use it right in your sources while doing data exchange and what have you.. UML, is mostly useful in coming up with that design and how to deploy this stuff etc.
On a related note, there is an article in a recent Software development magazine on using UML to design XML applications.(I dont have the URL handy.. Sorry).
One of my personal rules for judging books (admittedly, by the cover) is to avoid books of the "Learn X in 21 days" or "Master Y in 24 hours" variety. I find they break up the content illogically and promote a false concept of what it is to really understand a subject.
"Luck is the residue of design" -- Branch Rickey
In the hands of an experienced programmer it saves a lot of time. In the hands of a junior/mid level developer it tends to foster laziness. CTO's and managers that have good technical skills rarely need an UML diagram. UML is no replacement for good communication skills and tech savy management. A 24hr book is stupid, because you can't teach practicle usage. The only thing it does is put money in the author's pocket. The time spent reading the book would be better spent thinking about why the management doesn't already understand from previous meetings.
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.
Well, of course it does. Remember that everything in RUP starts with a Use Cases - something useful that someone will actually do with your system. There is no point in developing software before you get this down. The usual way this is taught is through machines that are well-defined and familiar to the student, for example an ATM or a drinks machine.
As a UML user, I wish more people in the software industry would think about the what and the who for rather than the how, which is what most programmers are preoccupied with.
Actually, that's a low opinion of it - some things are better represented visually, and object-oriented systems are one of them. Database schemas are another.
/* */'s.
But you run into a problem here, in that, to be really useful, the UML diagram has to be almost as detailed as the code. This is why flowcharts fell out of popularity - they were so intertwined with the code that it took twice as much effort to update the program (one pass for the code, the other for the flowchart.)
So, UML has it's place at the top of the conceptual stack, but once you start getting to the second or third layers, it's time to just break out the
...but it's being eaten...by some...Linux or something...
The problem with UML is that it doesn't really help to be pretty good with UML.
... the other in PowerPoint.
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.
Well said! A couple of year ago, one of my company's customers was on a big UML kick. He decreed that everyone would learn UML and all presentations of software design would occur in UML instead of in PowerPoint slides.
Great for me! After all, I always wanted an excuse to learn UML.
However, in the end, it turned out very poorly. Why? Because, the people reviewing our designs that were not employeed or hired by him didn't understand UML. So, we had to duplicate all of our designs! One copy was in Rose
When UML came out, I thought it was a good idea. After applying it for a while it struck me that I already had a design overview that was showing me the relationships between classes and the like (I started in C++ on OOP): the class definitions!
Pretty much all object oriented programming languages have these, and I have noted that they make the code a lot easier to follow, especially if you produce automatic documentation from them - they're about as good as UML.
In addition, you HAVE to do them anyway for your projects to get off the ground, so you don't even risk wasting time creating notes that won't really help you.
Since I realized that, I started creating every class definition I'm going to use in my code before I wrote out any of the methods, so that I could be sure of all the relationships, just as you are with UML.
Mod me down and I will become more powerful than you can possibly imagine!
I see a lot of talk here questioning how many people actually use UML, and how useful is it really?
Some years ago, my company hired a monkey-nutt of a Systems Architect as he liked to be called. He came in spouting the UML communication hierarchy, half-ass explaining UML as he moved along in the communication of his ideas. We spent about 2 months with the fellow. He accomplished nothing he said he would, and we let him take a hike as he talked the talk but... you know the rest.
HOWEVER, it piqued my curiosity. I was amazed at how easily communicable his ideas were through this UML thing, even though he failed to complete his ideas or do any work. What he did communicate was clear as a bell and the beginings of the model were impressive. I began reading the Addison-Wesley UML set of books in my spare time. Although I do not use Rationals Rose software which some of you suspect as the driving force behind UML, and I probably never will, I have come to use my basic understanding of UML in almost all the aspects of design and implementation I am responsible for. I don't make any of my people study UML, but I use it, use cases, sequence, prototyping, etc, staying away from acronomic adventures and annally retentive symbols. Everyone seems to understand fluidly, and I believe it has really cut our turnaround time. I feel pretty good about the fact that when I need to make something happen, be it build a new software project from the ground up, fix a discombobulated mess, or bring up a decent server box, I, as well as my employees spend less time back tracking, and are usually done quicker than if we just dived in. The modelling, or process planning as we term around here is absolutely essential to rapid quality.
A lot of people insist it's something for Rational to sell more software. I must point out that Booch, Jacobsen and Rumbaugh, the fathers of UML, have put together the ideas they developed over many years in their respective fields, *without* using Rose or Rational based software. Rational is the sponsor obviously, the roof it all comes together under, and yes I'm sure it sells their wares, and yes, I'm sure some how in the fine print they wish to take over the world such as MS did with Visual n, but it is a very effective process used independently. After all, it's something you excercise, not the software.
The problem with the guy who brought it to me was that he was so fascinated with the *idea* of the modeling language, he couldn't get past it, it obfuscated the very purpose of our meetings. The trick is not in the acronyms, how much of a bad ass you are, or how much time you spent learning UML, or how much time you can burn using it. It's simply in using it effectively to reach your goal, which in our case is not the *model*, but the end result.
ok, scoff at will...
Au contraire! I just had a class on UML last semester, and was surprised how useful UML could be. Simple diagrams can be used to show management where you're headed with your ideas. Some of the more complicated diagrams can lay everything out for your code-jockey to do the work. Proper modelling will usually save time and energy on all but the smallest of projects.
An analogy may be drawn from construction. A simple construction project like a shelf may require no modelling. Even I can eyeball a piece of wood and probably craft a pretty decent shelf. (Can you tell I practically failed wood-shop?) However, more complicated projects like a cabinet would require me to write down how I would construct the thing. How complex does a project have to be before one would want to risk NOT modelling?
I've actually used UML since I took the class. I've been playing around with making pinball machines in Visual Pinball lately, and found that UML State Charts are perfect for modelling the states of a pinball table. Not exactly a practical application, but still...
UML can be a very complicated system, but not all of it is necessary all at once. Probably the 20/80 rule applies to it. Learning 20% of UML, will yield about 80% functionality. A little bit of UML can go a long way. Now that I've taken the class, I can't imagine doing OO design without it.
UML is worthy to explore, but I'll agree with the poster on one point: I don't think I trust getting info about it in a "Teach Yourself in 24 Hours" book.
--
Ceci n'est pas une pipe.
I'd advocate UML Distilled by Fowler and Scott
Hear, hear! UML Distilled was what I used to learn UML in 24 hours!
Just junk food for thought...
AW has put out some trash books Java Design Patterns by Cooper.
ORA has put out crap as well, Practical C++ Programming. If you read this and you think you know C++ you are sadly mistaken. Then there's Java and XML and Java Servlet Programming How long did it take ORA to go from first to Second Ed. ?
The publisher that has surprised me is Wrox, it seemed like thay came out of nowhere and started publishing some good books.