Teach Yourself UML in 24 Hours 262
| Teach Yourself UML in 24 Hours, 2nd Edition | |
| author | Joseph Schmuller |
| pages | 397 |
| publisher | SAMS |
| rating | 5.5 |
| reviewer | WrinkledShirt |
| ISBN | 0-672-32238-2 |
| summary | Useful enough as an introductory text, but likely needs companion texts for anyone who wants to design complex systems. |
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 Good
Teach 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-Good
Part 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.
Conclusion
Now, 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
SAMSObject 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.
What about XML ? (Score:3, Funny)
The Unified Modelling Language provides ways of modelling every sort of system that you can imagine...
Isn't this the reason why XML was designed for ? If someone would care explain the difference between the two...
Re:What about XML ? (Score:3, Informative)
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.
Re:What about XML ? (Score:2, Interesting)
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).
Re:What about XML ? (Score:3, Informative)
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.
Re:What about XML ? (Score:2, Troll)
But they are both highly over-rated, so they have something in common.
TWW
Re:What about XML ? (Score:3, Informative)
XML is a markup language. Simply again, it is used to allow the easy communication of information between disparate systems.
Re:What about XML ? (Score:3, Informative)
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.
Re:What about XML ? (Score:1)
Re:What about XML ? (Score:1)
Okay -- if I wasn't all psyched about my first-ever Slashdot post, I might have noticed that I needed some HTML tags.
Here's the readable version: (Feel free to moderate the original down -- is there a "clueless" category?
XML = Extensible _Markup_ Language. Based on SGML (Standard General Markup Language), it is used for marking up data in a way that clearly indicates the structure of the information.
UML is a _Modelling_ Language. Its purpose, essentially, is to describe and specify systems. It provides a way for various participants in a project -- coders, managers, users, etc. -- to be able to communicate about a system being designed.
(It's a bit simplistic, but that's the basic idea...)
UML vs XML (Score:2)
XML is designed to allow systems to share data, and is textual.
Re:What about XML ? (Score:1)
XML is a metalanguage; UML is a language (Score:2)
So while you can take your UML diagrams, feed them to a program like Dia, and have it spit out XML representations of the semantic information in them, you will probably experience much less success feeding the resultant XML code directly to someone familiar with UML in their designing process.
More seriously, there are lots of languages derived from Latin. By your logic, we should all learn Latin. I did that. I still had to learn Spanish, German, and Italian in order to converse with speakers of those languages. And in fact, XML isn't even as useful as Latin
If you are planning to represent state machines, object interactions, and other design idioms in a standardized form, UML is the current lingua franca. XML is a useful tool for communicating the semantics of (say) a UML diagram, an interlinked graph of information resources, or purchase orders. Is it a substitute for UML? Well, you try ordering a burrito in Latin in East LA and tell me how far you get.
Re:What about XML ? (Score:2, Funny)
dude#2: While you were playing rtcw, dude, I was inspired to drink 17 cans of jolt and totally learn this question's ass. The answer is "XML and UML are so totally fucking different, it's like untrue".
dude#1: whoah, so it was like a trick question, dude?
dude#3: No, dumb-ass dudes, the answer was "Microsoft invented XML".
dude#4: No way! I put: "Like UML is all boxen and lines and XML is text"
dude#1: Actually, dude, you could be right there.
graspee
UML users, Are there many? (Score:2, Interesting)
Well, Good for them.
Re:UML users, Are there many? (Score:2, Informative)
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.
Re:UML users, Are there many? (Score:2, Insightful)
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.
Re:UML users, Are there many? (Score:5, Informative)
Re:UML users, Are there many? (Score:5, Informative)
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.
Re:UML users, Are there many? (Score:2)
When I joined a web startup a couple years ago, the Perl website was way behind schedule. To hedge its bets, which at the time, seemed reasonable, management tried to outsource our website to another development company that had been using Rational, UML and coding in Java for a year or so. Parallel competing teams, essentially. They promised the site'd be done in 6 weeks with 5 people working on it. While I don't think all 5 worked on it solid over that timeframe, it ended up taking them 4 months and two of us slinging perl were in comparable shape in under 2 months, adding marketing's latest feature requests as we went. (The perl team did use flow diagrams; nothing fancy though.) One may debate quality, but the key criteria clear to all involved for success at the time was 'time to market', and the team using Rational ended up late to market, and their work was abandoned as too little too late. It was a learning experience for all involved.
--LP
Not a Big Fan of Sams (Score:1, Informative)
Book based on a dare (Score:1)
Re:Book based on a dare (Score:2)
I will let you know in 5 weeks when I need to han my UML stuff in for uni project!
Re:Not a Big Fan of Sams (Score:2)
Personally, I like reading books like Sams to get an overview of something new, then I at least have an idea of what it's all about. I can then pick up a real brick and learn in-depth. And, since I have a decent idea of what I can do with it I feel it's easier to learn how and why to do it.
The problem with UML (Score:5, Insightful)
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.
Re:The problem with UML (Score:2, Insightful)
Re:Start with... (Score:2, Informative)
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.
Re:The problem with UML (Score:3, Interesting)
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
Re:The problem with UML (Score:2)
Re:The problem with UML (Score:2)
Extreme Programming is a methodology that is competitive to the Rational Unified Process BUT unlike Rational folks doesn't advise you to purchase their $10,000 modeling package or a $50,000 training course. It's a down to earth system of how to plan, design and implement a system with maximum predictability and on budget. And all this without the almighty Big Design accompanied by a zillion useless diagrams.
Go figure who I'm inclined to suspect of trying to sell me snake oil instead of helping coordinate my development process.
Good for beginners (Score:4, Informative)
Re:Good for beginners (Score:2)
I have both books as well and think they are excellent. Great reccomendations.
Re:Good for beginners (Score:2, Interesting)
Hear, hear! UML Distilled was what I used to learn UML in 24 hours!
Who uses UML? (Score:4, Interesting)
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?
Re:Who uses UML? (Score:5, Insightful)
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 major tools use UML (Score:3, Funny)
Re:The major tools use UML (Score:3, Funny)
Do the customers ever look at those diagrams and then come back and ask for changes? For instance, suppose a certain design team 8 years ago had shown UML diagrams to an outsider, and explained, following along it: "Now, to shut down, the user moves the mouse to the Start button..." "Wait a minute, you hit START to STOP???" Think they might have changed that?
Out where contracts may actually require programmers to produce software to the customer's satisfaction, one thing like this caught early enough to be easily fixed is worth a hell of a lot of diagrams. Imagine a soda machine where you have to press "SELL" to buy...
Re:Who uses WORDS? (Score:2, Funny)
Yep. WORDS [are] a way for poor communicators to pretend to design. WORDS are notoriously bad at factoring in real-world requirements, exceptions, usage patterns, and user scenarios. In every case I've seen WORDS used for modeling, [they have] created systems which [sound] clean
sarcasm OFF
Re:Who uses UML? (Score:2)
That is generic rubbish.
UML diagrams are notoriously bad at factoring in real-world requirements, exceptions, usage patterns, and user scenarios.
Are you telling me that doing UML diagrams for a particular system really has those problems?
There is a big difference between UML and the entire Rational Unified process. I have used UML (class diagrams) to design an OO system and then provided sequence diagrams to show someone how to use my API. How is that any better or worse that providing a textual description, from a point of view of real-world requirements, execptions and user scenarios?
I have news for you. If people can't use UML to do a good description of a system, they can't do it using words or some other technique either. They are simply bad designers.
Re:Who uses UML? (Score:2)
It is my strong impression from seeing projects specified with UML that diagrammatic specification has an inherent tendency to be less thoughtful about aspects of a software system for which there is no built-in diagrammatic representation, and that these "semantic" parts of the design of a software system overwhelm in practice the more constrained parts of a system which can be modeled using such formalisms as sequence diagrams.
To take one example, in the creation of a music engine at one company, extensive sequence diagrams were created to show the flow of musical data between various processing components. However, the scenarios for building and installing the engine in a variety of contexts, including web plug-ins and embedded device firmware, were nowhere to be found in the specification. Attempts to get the engineers to focus on these broader usage issues got nowhere, because the incredible specificity of the sequence diagrams seemed to imply that all important questions had already been answered. The questions about installation scenario, while critical to the design of the product, seemed fuzzier and less important because there was no way of expressing them in the specificity of UML diagrams -- they involved more free-form issues and text description. UML created a false sense of concreteness that led to neglect of important issues which could only have been adequately addressed in text.
In another case, a complex nested data structure was to be saved on top of a SQL database. Intricate class diagrams and sequence diagrams for the save procedure were drawn up, but each time a save API was delivered based on these heavily reviewed UML designs, it failed to cover major cases of nesting relationships and had to be reworked from scratch. UML diagrams turned out not to describe the solution at an adequate level of abstraction to deal with the general case of nested saving -- instead, all it could do was break down the problem into some six dozen special cases, rather than proposing general rules. The conceptual questions about what it meant to save a snapshot of a complex data structure in a shared system were never asked and could not be answered at the low level of abstraction provided by UML, and so the design effort for this critical portion of the internal API never succeeded through multiple development cycles.
Thought is a thing that happens primarily in words. Where it can be formalized into diagrams, it is if often worthwhile to do so. However, given the enormous complexity of software engineering problems, this level of formalism is rarely either attainable or useful. Even if we look at highly formal domains such as science and mathematics, published papers tend to be structured as natural-language essays with inserts of formulas and tables, rather than primarily as mathematics with a smattering of natural language. Software engineering is less formal than science or mathematics, not more. Specification should remain primarily a matter of writing in natural language, with diagrams at key points where they are applicable. The labor-intensiveness and false specificity of UML leads to an approach that is the reverse of this, in which what few words remain are subordinated to elaborate diagrams of marginal value. This creates inferior system designs.
Tim
Re:Who uses UML? (Score:2)
If you look at the Rational Unified Process, they include textual descriptions as part of a system description, not just UML. But, leaving that aside, who is proposing using UML exclusively here? Any proper specification is going to include textual description as well as diagrams.
I see 2 arguments going on in these threads:
1. You can't replace textual descriptions with UML.
No shit. Nobody sane is advocating this. UML is another tool in your repetoire for communicating a design.
2. I have seen poor UML designs.
Again, I have news for you. A designer who produces poor UML designs is also going to produce a poor design when provided a text editor. UML is a tool - it won't magically transform a poor designer into a good one.
Re:Who uses UML? (Score:2)
And yet it is what is being practiced in the field. There are intrinsic forces involved in UML that lead in this unpleasant direction. You haven't dealt with those factors or with the way that UML-based specification activity tends to drive out text-based specification in practice. I believe I was sufficiently specific in describing some of these factors.
Tim
Re:Who uses UML? (Score:2)
In your experience. The way design is practiced in my company doesn't bear this out, and the experience of other friends in the industry doesn't either. I guess we must be immune to these mysterious "intrinsic forces".
Just becuase you have bad experiences with designers generating UML diagrams in place of a full-featured specification doesn't mean UML is useless. It means you work with designers who are either incompetent or lazy.
The UML is simply a tool - a way to draw diagrams so everyone can understand them. Go back 15 years, and structured design had a similar set of notations. Heck - look at databases with entity relationship diagrams, which have been around for decades. If your entire database design is an ERD, and this is insufficient, does that mean that ERDs are inherently bad? No - it just means you have an incomplete design.
Re:Who uses UML? (Score:2)
Tim
Re:Who uses UML? (Score:2)
Your message deals solely with the issue of premature design decisions., You did not engage other equally significant issues: that there is no place for design specialists in the Rational Unified Process, that the notoriously bad design of the Rational tools serves as a (negative) case study in the results of the Rational Unified Process, and that the way that use cases are specified creates user interfaces with a modal order of execution, an approach that violates standards of software design since 1984.
Tim
Re:Who uses UML? (Score:2)
Basically, if you think in an OO way when you're programming, UML makes sense and can help to give very quick 'summaries' of software systems.
That being said, I don't think that UMLs role in design and prototyping is as critical as some people make it out to be. I think it's more useful to give a top down view to a guest engineer or someone who did not participate in the design process to start getting an idea of where to muck about in a project when changes or fixes are needed.
To that end (and I develop CORBA apps), I don't feel I need to be an expert in UML, but I certainly don't have any quams with having to have a casual familiarity with it. That is, I can understand the language, but I don't really feel career-related pressure to speak it.
Envelopes are the right medium! (Score:2)
People are much more likely to understand something when you communicate it via multiple modes, so description plus diagram is much better than either one on its own. And using UML rather than some home-grown notation makes it easier to communicate, as you don't have the questions of "What does that arrow mean again?"
.
Sure, this is "back-of-envelope" stuff, but just because you erase the diagrams doesn't mean they aren't valuable! The hard part about building software isn't the coding; it's the thinking about what to code.
Re:Who uses UML? (Score:4, Informative)
You aren't alone. The always entertaining and often right Bertrand Meyer has this [eiffel.com] to say about UML.
Class diagrams are the worst part of UML (Score:2)
The Squence diagrams are my favorites, but I find both the State and Activity diagrams more useful than the class diagrams. I think class diagrams get all the emphasis because you can autogenerate source code from them. Which is a shame since the data layout of a system is seldom the trickiest part.
Use MULTIPLE Diagrams (Score:3, Insightful)
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.
Re:Who uses UML? (Score:2)
We'll also use UML largely to represent the workflow or flow of information as we understand it from our analysis. Thinks like "customer enters store, makes order, sales takes money, gives receipt" can be represented pretty easily and clearly.
We still haven't used UML for anything detailed. Our class documentation is formated more like the class definitions in O'Reilly's "Java In A Nutshell" (I really like that format), and the workflow is detailed more through use case scenarios and more specific flowchart diagrams (i.e. a complete diagram of what happens in that "sales takes money" part of the process).
In general, we find UML useful for higher-level abstract diagrams. Even our customers, who are usually very non-technical people, understand those diagrams quite easily. For our internal understanding, we use more detailed documentation.
Re:Who uses UML? (Score:4, Interesting)
There is a ton of documentation there , but they make heavy use of UML which really helps.
As well as Class Diagrams they have a lot of Sequence Diagrams & State Diagrams.
These are the diagrams that really add value as they give a dynamic view of the system eg. how EJBs change state over time.
Much more useful than just a bunch of static Class Diagrams which dont give a sense of how the system actually behaves.
Re:Who uses UML? (Score:2)
Re:Who uses UML? (Score:2)
Unfortunately, you're right about UML. In fact, I'd say that you're being too mild. I wouldn't spend much time trying to learn it in any great detail, nor would I spend much work time trying to model a system in UML.
As an experiment, I tried to describe the design of my current system (basically a CVS replacement) using plain text, UML, and a formal specification language called Z.
Of the three, the Z had the wonderful property that it made several crucial design errors absolutely crystal clear, and led to fixing the design, and saving months of programming effort.
The text had the advantage that people could sit down and read it, and get a basic idea of what was going on. It wasn't very precise, and it was ambiguous in places, but it's enough to give people some idea of what was going on.
The UML was utterly useless. It captured none of the interesting properties of the system. It had no explanatory value. It had no analytical value. It was harder to understand than the text, and carried far less information; and the semantics of UML are so ill-defined that it had absolutely no precision. Even after added some specification clauses uses OCL, it was still an utter waste of time.
The only UML diagram that I've seen that had any value was a Rose diagram used as an explanatory aid for the DeltaV draft standard. The standard, by necessity, was written in such dense standardese, with so many inter-referrences with other standards, that it was very difficult to comprehend, and the diagram at least gave a canonical view of the basic entities and some notion of what the relationships between them were.
Re:Who uses UML? (Score:3, Interesting)
Isn't that like being a consultant in wood, nails, and saws, instead of being a carpenter? That whole concept just seems wrongheaded to me. That the technologies and methodologies are the ends in themselves. The goal should be solving problems, not applying specific technology.
I never start a project without sketching the minimal informations I have at the start with UML. ... And elaborating them into code. For me source code and UML is just the same only different visualizations.
So, the "minimal information" you have at the start, becomes the foundation of your code. It's insane! But I've seen exactly that application of UML myself, where the quick information-gathering sketches from client meetings are turned into a horribly ugly system design that is generated automagically by Rose.
Where's the synthesis, that leap from requirements to the elegant architecture that solves the problem? There's a creative element there that I don't think UML provides an opportunity for. The Rational/UML fans seem to think that software development is a purely mechanical process that follows a deterministic path after the "use cases" are input. That's just not the case, not for good software. The best designs often take a completely othogonal approach to what use cases might indicate.
with UML you are up to 5 times faster
Heh. Now you just sound like a Rational salesdroid.
Re:Who uses UML? (Score:2)
That's exactly what I don't like about UML.
Using UML for system design, you're forced to describe the end solution almost from the very beginning. Instead of focusing on the requirements and on the goal, you're focusing on the solution and the process. It works for small and simple (academic) projects, but often leads to problems in big real-world systems. Especially when they grow and evolve in time.
Another problem with UML code mapping is that it works fine with Java, but doesn't work well with other languages, like OO-Perl, LISP or some non-OO languages. UML is not so "U" ML.
No thanks... (Score:1)
On the whole... (Score:5, Insightful)
psxndc
UML samples (Score:2)
Has anyone seen any good "Getting started with UML" type material on the Web? I'm specifically looking for the type of tutorial that starts with a problem and then goes through the various UML diagrams showing how they apply, finally to a simple system of several components. As it is it's very hard to convey UML information to coworkers because most UML tutorials seems to have a "start with everything" perspective on it. Links would be greatly appreciated.
Re:UML samples (Score:2)
Teach yourself x in 24 hours (Score:2)
The O'Reilly UML Book is out of print, but fairly good.
Not beyond possibility (Score:2)
Besides, I've never read a SAMs book that really contained lots of info. I think I read the C book, and the HTML book and absorbed all the knowledge in those books in about a day. Then I moved on to the more complicated stuff, and I had to get another book.
In addition, UML is for MODELING a system design. Kind of like how flowcharts are for modeling a system design. I just bring this up because I feel that most people are probably familiar with those to some degree. In fact, I'd say that UML is sort of the object-oriented equivalent to flowcharts.
If you've already worked with imperative programming languages, understanding and writing flowcharts is simple. The same is true here: if you've already implemented all of the OOP concepts, then writing UML is fairly simple. If it wasn't, then we'd need a new modeling language, because the purpose of a modeling language is to be simple to write and read so that the structure of a program is easy to follow.
Of course, this is my opinion based upon my experience, but at least I can say that there's a lot less to UML than there is to Java, C, C++, perl, Javascript, HTML, Lisp, or VHDL (I suppose LISP is argueable since its got a small orthogonal basis set).
My Favorite interview question (Score:2)
"Well it's UML and we uh use it with the UML process." Thank you for playing.
UML is a great notation, works well with white boards. But for too many people it's just another TLA to check off on their CV.
-Peace
Dave
Re:My Favorite interview question (Score:2)
Part of the problem is that in order to really use the full extent of UML everyone else has to know as much UML as you do to be able to understand it (as the goal is communication of ideas and if you don't understand the notation how will you understand the idea?), and even if you start out knowing a lot of UML eventually you end up pretty much knowing the same level of UML as all the people around you due to the "use it or loose it" syndrome.
It would be interesting to work in a shop where everyone really knew UML well, and see how that changed design or how many people would be required to keep UML knowledge high instead of decaying.
UML Distilled (Score:3, Insightful)
Did it live up to its title? (Score:3, Funny)
Enquiring minds want to know!
Re:Did it live up to its title? (Score:2)
Most useful UML book I have ever found (Score:4, Informative)
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
You must be an academic (Score:4, Informative)
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.
UML good and bad (Score:2, Interesting)
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.
Applying UML and Patterns (Score:5, Informative)
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 [amazon.com] 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)
Re:Applying UML and Patterns (POS?) (Score:4, Funny)
Is a case study of a "POS" system really the reference you want to follow??
Oh, wait... point of ... never mind.
Use Cases (Score:4, Interesting)
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.
Re:Use Cases (Score:2)
Just some decent advice from a fellow programmer.
deja vu (Score:4, Insightful)
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.
Re:deja vu (Score:3, Informative)
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.
Re:deja vu (Score:2)
And, indeed, many moons ago the software company I worked for had need for such a thing. We had built a suite of programs on MFC and it had grown to beyond it's original design - which sucked. The PHB's wanted diagrams so that the code may be "maintainable" and Mr Rational was called in to help.
The troops arrived, laptops, projectors, suits, the whole team spoke to them for a whole day. We got the product and pointed it at our code and it went completely mad... started running around MFC producing UML diagrams, badly. Anyway, those who have used MFC know that the last thing you want is a class diagram.
Mr Rational was sent home, tail between legs, and we had to fend off their salesmen's calls for months after.
Moral of the story? Don't believe the hype.
Dave
UML - Flowchart of the New Millenium! (Score:3, Interesting)
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
Sams books (Score:5, Informative)
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
Porsche (Score:2)
Good UML Alternative for OOP (Score:4, Interesting)
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.
Expectations (Score:4, Insightful)
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
Understanding UML is one thing, using it ... (Score:2)
Usefulness of UML (Score:5, Interesting)
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...
Re:Usefulness of UML (Score:2)
The idea is that UML is not a real "language", but a set of commonly defined pictograms. And I don't like how they are defined. It's like I can't accept that an 'E' faces to the right. But the thing is that I learned letters a long time ago and I don't fight it, UML, however, is just someone else's idea about how to draw a diagram and I don't - and won't - agree with it.
-Russ
System modeling (Score:3, Informative)
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.
Re:System modeling (Score:2)
And who was it that decided that complex software systems are more like soda machines than like novels?
Tim
Hey, knock it off, UML Works (Score:5, Insightful)
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 [tigris.org]. 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.
24 hours eh? (Score:2)
Teach yourself C++ and MFC in 12 minutes
Teach yourself XML Web Services in 5.7 seconds
Instant enligtenment. Why sonny, I remember back in the olden days when we had to read and read and read and scour reference manuals just to write a simple hello world program. Thats the way it was and we liked it!
I can just see it the next time I interview someone for a design role: Well, I haven't actually used UML before, but I bought this book yesterday and
Obligatory Skepticism (Score:2)
1. I'm skeptical of anything titled "Teach yourself $language in $time". The smaller the $time, the more skeptical I am. Let's carry this to its logical extreme and publish a book titled: "Teach Yourself Multidimensional Particle Physics Before You Even Buy This Book".
2. I'm skeptical of any language designed to describe something written in another language. The Tower of Babel ain't gonna be rebuilt anytime soon folks.
Stuff like UML is perhaps useful when you are working on some huge government project where they spend $10 million on auditing to make sure you don't waste $2 million tax dollars. Other than that, it isn't very useful.
This is where Open Source has an advantage--there are no audit trails or design documents; just mailing list archives. Now, if someone came up with a smart program for reading such archives that didn't require developers to change their ways of communicating, you might have something. And yes, I understand that many see the lack of design documents and audits in Open Source as a disadvantage but it depends on where you are. A prehensile tail is a big advantage if you are a monkey in a tree. It's a disadvantage in a board meeting.
Re:Obligatory Skepticism (Score:3, Interesting)
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 [randydavis.com] 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.
--
UML tools (Score:2)
I tried a UML plug-in for Visio once, but it stopped working at the next upgrade, and since Microsoft bought Visio, that product has become far more complex and expensive. (Visio was originally a useful little tool for drawing diagrams with boxes and lines. It was configurable, so you could write new box types and do UML, flowcharts, org charts, and such.)
We really need a public format for simple draw programs. That's one big reason why Linux software doesn't have enough pictures.
Is UML programming language specific? (Score:2)
However, from my own experience, UML is NOT language-independent. Yes, it fits Java very well. It's OK with C++ (not the templates) and probably with Smalltalk. But it's much more difficult to map some other language ideas into the UML notation. In particular, I've seen unsuccesful attempts to use UML for:
- database-centric system with majority of logic in SQL code;
- huge system written in object-oriented Perl (yes, it's possible). Many OOPerl techniques just don't have the corresponding UML vocabulary.
For an alternative approach to modelling, look at CRC cards [c2.com]. It's simple and effective.
Relationships (Score:5, Funny)
Milla Jovovich would be a nice start...
All the UML you need to know in a Slashdot comment (Score:2)
I teach introductory OOA&D courses, and as part of those we do an introduction to the part of UML we feel is actually useful. That takes about 2 hours and a couple of exercises.
Only class diagrams, object diagrams and sequence diagrams are actually useful. You don't need diagrams to communicate use cases properly (unless you're trying to sell case tools), and state diagrams are only useful if you're developing protocol stacks.
Within class diagrams, only ever use simple associations: you can use diamonds once you can explain to me precisely how composition differs from aggregation. Never try to include all variables and comments in your classes. Always label both ends of the association, and provide both cardinalities. Don't bother with arrows. Never, ever, ever use association classes or ternary associations, unless your group has a really precise definition of them and sticks to it.
Re:All the UML you need to know in a Slashdot comm (Score:2)
2. Well, bully for you, but the number of possible states of most systems is too big or too small for them to be useful. They're handy if you're writing things that go through small series of intricate state transitions - like network protocols, or maybe session management - but not otherwise. For the vast majority of applications, they're not applicable. Thats why we don't teach them.
3. But the use case notation is useless. You can show the same thing more clearly as text. Personally, I prefer scenarios for talking to clients anyway. If you can wave diagrams and clients and believe they understand what is going on then you're either very lucky in your clients or deluded. Indeed UML does not imply cases tools. Whiteboards generally work better, but there's stuff in UML - unsurprisingly, given its source - that seems only of use for selling case tools, such as the Use Case notation.
4. If a feature makes no sense in context, then why not tell people not to use it ? If you use UML as a communications tool with other developers, the most important thing is that everyone has the same understanding. Funny wee diamonds, and wierd associations, generally hinder understanding, and the same concepts can be explained more clearly using the minimal notation and a note.
You seem to assume a level of conceptual unity in UML that just ain't there. Because it is quite deliberately *not* a methodology, there's no reason to use the tools that you don't find useful, and if you, in turn are teaching other people a way of doing things that you find works, it makes sense to tell them to do the same. Much of UML is just there because someone once invented a methodology that used it. Often 20 years ago. I believe I do understand most of the features, but have found that most people don't, and that those who do "understand" them differently from me.
I'm not a believer in heavyweigth process, or ornate notation. Clear communication is far more important than precise documentation. In general people have more success, and more fun, using the techniques we teach than they do trying to use the full "power" of UML.
Simon
A good free UML Reference (Score:2)
UML can work. It just isn't a panacea! (Score:4, Informative)
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 [openprivacy.org] 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 [yi.org]
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.
Re:Nice... (Score:2)
Now you're perpetuating the stereotype that everyone who enjoys whiskey is a drunkard.
I've just used a dictionary: (Score:2)
(The American Heritage® Dictionary of the English Language, Fourth Edition)
It says nothing about the pronoucability or ease of spelling...
(Although the examples used can be pronounced)
Scratch that.... (Score:2)
I should have used this dictionary the first time.
The unpronounceable version of an Acronym is an 'Initialism'....