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 personally am not a huge fan of SAM's books. They are more often than not, dry, boring, and difficult to read without taking a nap every 2 or 3 pages. This one could be the exception to the rule, but for some reason, I doubt it. ;)
UML is a Visio-sort of diagramming standard (although now they are formalizing or have formalized a standard file format so different UML formats can actually share diagrams) to convey all manner of software design issues: Usage of a system, sequences, collaboration, etc. Totally and completely different than XML.
This is an excellent choice for beginners who don't need to do "real" UML development work (eg students), for a more indepth look I'd advocate UML Distilled by Fowler and Scott for a more thorough grounding (and "The Unified Modeling Language User Guide" by Booch and Jacobson for the crunchier details of the language.
XML is a way to pass and store data. UML is a way to model systems and interactions.
XML is to UML what a lumber truck is to a blueprint.
UML is a modeling language. In simple terms, it is like creating a flowchart of system processes and then using something like Rational Rose to create actual code. That is a very simple overview.
XML is a markup language. Simply again, it is used to allow the easy communication of information between disparate systems.
XML is used to represent data, while UML is used to represent systems.
XML is typically used in the implementation of a system, while UML is used to communicate the design of the system (during the design and implementation processes as well as afterwards).
It's also slightly misleading to call UML a "language" because it consists primarily of visual diagrams drawn according to several standards for notation.
Those who wish to play around with UML might be interested in Argo UML. It is a free Open Source UML modeling system. It has a few shortcomings but it can give you some hands on experience with a pretty good UML CASE tool.
At my last job as a C++ system engineer, we were told that everything had to be done via use cases, class diagrams and collabration diagrams. It took months to push changes through the system, but the company was willing to take the expense to produce what they thought was better code.
My current job is basically me working on some stuff and building libraries along the way. I don't use UML any more but it's a real handy skill to have when I'm trying to explan things to people outside our company.
UML Distilled by Martin Fowler and Kendall Scott. This very short (185 pages including index) book sums up UML diagrams and the uses of them in the most succinct clear manner I have ever found. It is designed as a reference, but works well as an introduction. It presumes you know object-oriented development, basic Jave/C++ syntax, and whatnot - pretty safe assumptions for someone who needs to learn UML, and a godsend for people tired of having to wade past descriptions of basic concepts in every other book that has been supposedly written for a "Professional" (poke at Wrox is on purpose)
-Frums
UML is taught widely in the academic world, but the industry is abandoning most of this type of work. It simply doesn't translate into better products and shorter delivery times.
For example, apple has just instituted a policy of reducing team size to 14 people or less to eliminate much of the needless overhead associated with formal modeling.
A big problem today is people learning the latest buzzword and perhaps the syntax/semantics behind it, but not knowing when to use it, or more importantly, when *not* to use it.
I had to buy Applying UML and Patterns by Craig Larman for a software engineering class last semester, and it's very good. Not only does he follow a case study through the whole book (a POS system), but he hacks down people for spending too much time on diagramming. He also suggests "UML Distilled" as a pure reference, mentioned several times in comments above.
Most importantly, the UML is just a display medium, not a process. Just saying "lets use the UML" isn't going to help anyone. Larman discusses the Unified Process (UP) in depth, which is all about short, time-boxed iterations which *do not slip*. In the UP you push features out of an iteration rather than have it go over deadline.
If you're considering using the UML at all, get this book. (not to mention it's a great software engineering text in general, teaching many fundamental patterns and principles including many from "Design Patterns" but with Java as an example language)
I've used UML on projects for the last 5 years, and the value increases with team size and system complexity. If you like to do alot of up-front design, refactoring, and use of design patterns before you start coding and debugging, it is very valuable. Especially when you have teams of 50 odd people designing simultaneously - text requirements just aren't as good - you also can't do code generation from text requirements... And Rational is not the only player in town, besides Dia and Argo OSS, TogetherSoft has good products, and so does Tendril (at least for java development).
...begins in wonder
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.
You aren't alone. The always entertaining and often right Bertrand Meyer has this to say about UML.
JP http://www.wearerite.com
Following words may be a bit biased since I work for a UML design tool company. This was a disclaimer.
If you're still here - look at the tutorial [pdf format] of it. This includes several UML examples which may be tried having the tool (this one, or maybe another). Since the tool is
written in Java, it should work on your platform. And, yes, you'll have to register before downloading
full-functional demo. I hope, this is the only inconvenience in this case.
At the bottom end of the food chain when it comes to computer books are anything from Sams, Que, or IDG. These publishers typically rush books out so the books are on the shelf before anything else, and often before the software is even released. They are full of screenshots and typos and often information that is incomplete, leading you to other books if you are looking for answers. Thats not to say they all are like that - I've seen good authors write for Sams, etc., and they do their best to do a good job. Its just the nature of publishing that if you rush your books to the shelf and are long on screenshots and short on editing, well, that comes out in the quality of the book.
If you need to learn UML(or C++, or Java, or VB or
No, Thursday's out. How about never - is never good for you?
One of the executives at my company came from Rational. He said Rational never manages to sell their UML stuff into software startups, the place where software is done most quickly and effectively. He said the majority of sales went to IT groups in large companies where less talented people tend to work. The UML lets these companies document a long-lived project at is evolves, and makes sure all development/QA/deployment personnel understand their contribution in relation to that of others.
For a startup, UML is way too much overhead. If your people can talk, agree on an architecture, and implement a system without all those documents, you're better off.
Mike, the flip side of your last paragraph is somewhat more useful. I've used TogetherControlCenter to create class diagrams visually. The program generates (in my case, Java) code for each of those classes. Admittedly skeleton code, but it allows me to go from package/class design directly into fulfilling the contract laid down by the design. I've only used the "Community" version, so I have not had access to the other UML diagram types, but (according to the readme and help files) the other diagrams take the classes from the class diagram and add more code based on the other diagrams.
Bluntly, it is loads faster for me as an "all-in-one" analyst/designer/developer for me to do the design in such a UML diagrammer/code generation tool, then flesh out the rest of the code afterwards. For people who work in separate roles, if the analysts and designers are worth their paycheck as professional communicators, then they should be able to hand a coder a written specification that allows the coder to work just as quickly.
And, as to your original statement, Rational can indeed generate UML from code -- and then allow the user to manipulate the UML and thus generate new code.
At the base level, some people work well visually, and some don't. Those who work well visually and understand code and know their tools can use "proper" UML tools to make their lives much, much easier.
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.
Hey, I've got friends who make their living programming the microcontrollers for soda machines, etc. And I'm sure there are many more people doing this sort of programming ("embedded") than hacking OS's, so have some respect.
Anyway, modeling the whole system is what UML is about. Forget that flipper that drops one can, and the code will take your money and say thank you, but you aren't getting any soda.
Having taught the UML to my development team, I've found it to be more effective to begin with the class diagram. There are several reasons for this.
The class diagram drives object-orientation home more quickly as you immediately encounter encapsulation and inheritance on this diagram. Class diagrams (interpreted strictly) show what combinations of messages are possible with the current system through dependencies and associations. The OCL enhances the vocabulary of the class diagram to allow business constraints to be modeled as well.
Learning the class diagram first becomes even more effective when you're teaching the UML in the context of a process or method. For example, I taught my team a hybrid of the RUP and ICONIX processes, which we then used immediately (this is also key). In both those processes (although more so in the RUP) you use sequence diagrams to help find the classes, and to help flesh them out (if you can send it a message you've got a dependency at least...).
You make a good point about sequence diagrams being more like code (the UML itself is designed to be executable), but most code generators work from the class diagram (again making it more important in fact if not in theory). To represent code you'd often have to create a myriad of sequence diagrams to express all possible combinations of the interactions between a particular set of classes. Sequence diagrams are more useful within the scope of a use case than within the scope of a single class operation.
Many free software / open source / pseudo-free 'light edition' UML modeling tools sometimes don't even include sequence diagrams, although I'd argue that they are the second most important diagram after the class diagram.
OTOH, sequence diagrams more effectively convey the intended impact of polymorphism to those less experienced in O-O.
As to your business analyst woes, I sympathize. I suggest you buy them (or better, have your company expense a copy) of Alistair Cockburn's Writing Effective Use Cases. Good use cases become critical especially if you base the rest of you SDLC from them, as in Use Case Driven Object Modeling with UML by Doug Rosenberg.
There are a lot of people here that are criticizing UML.
:)
It is important to remember that UML is not a panacea! It won't solve all of your problems. However, when combined with other proper design techniques it can be very valuable.
For example:
Check out my Reptile docs.
When combined with regular documentation, and linked to the Javadoc, these UML class diagrams REALLY help to clarify the system to newbies.
These were generated from source with Jase
The site was generated with Apache Velocity/Anakia and the Jase diagrams are generated with Ant every time I want to rebuild the site.
This allows us to produce a site that has up-to-date UML Class diagrams, javadoc, code snippets, etc and these are always up-to-date with the code that is in CVS.
cool... huh?
This is a good example of how UML can bring a lot to the picture.