Slashdot Mirror
Teach Yourself UML in 24 Hours
Introduction
The UML was adopted by the OMG (Object Management Group) as their official method of visually representing an object-oriented design, and as such is particularly well-suited to working with CORBA (Common Object Request Broker Architecture). Now, the OMG believes in their acronyms the way the Irish believe in their whiskey, and if you're hoping they'll give you introductory material on how to use the UML without broadening the context to all the other standards the OMG is responsible for, well, good luck. Addison Wesley has an entire series dedicated to the UML and different aspects of it, and O'Reilly's got the requisite Nutshell book, but there's definitely a void for good low-cost beginner texts, and it is this void that Schmuller's book attempts to fill.
Does it succeed? Well, sort of.
The GoodTeach Yourself UML in 24 Hours is a very thorough introduction to the language. The first fifteen chapters alone cover practically every structural and behavioural element, all the important relationships, static diagrams and dynamic diagrams, and even a little object-oriented design theory. As far as computer books go, it's not very expensive at its full price, and is even available at some discount stores. It is also loaded with sample diagrams throughout, and has a large seven-chapter case study going through a sample project design process, terminating with a couple of chapters on miscellaneous applications of the UML.
Understanding the subjective element of design, this book tries to help the reader gain their own personal take on the UML by providing lots of sample exercises to perform, and the sum total is a book that gives the reader a good idea of the effectiveness of the UML as a modelling language. In fact, if I were a systems analyst and I needed to give my team a crash course in the UML before getting them to implement my specs, I could do a lot worse than making them all read this book first.
Unfortunately, here's where the accolades stop. A book that teaches people how to read another person's diagrams written in the UML is one thing, but as an effective reference on how to design using the UML, the book comes up short in a few ways.
The Not-So-GoodPart of the power of the UML is that even though the OMG really needed to it to get their CORBA spec to make sense visually, you can basically use the UML to describe any old sort of system you want. Unfortunately, Schmuller takes a little too much advantage of this, and a disproportionate amount of the examples and diagrams involve physical systems instead of software systems. It's as though software design is a bit of an afterthought, which is fine, but the book could have been richer had it focused more on this aspect of UML implementation rather than, for instance, how to use the UML to model a soda machine.
Another shortcoming is that the book tantalizes us with the odd example proving that part of the power of the UML comes from the flexibility to combine elements from multiple diagrams into a single diagram, and yet these examples are used so sparingly and with no substantive explanation to the methodology involved that you're left with a feeling that even though the UML can do a lot of things, you're not quite sure how to make it do all those things for you.
It's admirable that Schmuller devoted so much time to the case study, and made sure that the scope was broad enough that all of the topics explained to that point got an appearance. However, one of the pitfalls of trying to come up with a case study that outlines a fundamentally subjective process is that some of the design decisions are going to seem arbitrary to some people who don't have a psychic connection to the author. It's not something unique to this book, but this book falls victim to it. Schmuller would have done better to have used those seven chapters to describe two different systems to give a broader idea and more than one context to the process of UML design. He also took a little too much creative license with scripting the hypothetical interview process. A reference book on the UML isn't the best place to try out your best David Mamet impression.
And then there are the really minor problems. Some of the diagrams could use a little cleaning up, and sometimes the basic diagram is represented a little differently in the summary section as it is in the chapter dedicated to it. Some of the more complex diagrams are handled first and the simpler ones later. There's no real explanation that makes sense to a newbie about the difference between an aggregation and a composite. And finally, even though one could argue that learning about the UML itself should be kept as a separate and distinct process from learning about how to program off a UML design, I think such a chapter would have been far more beneficial to a neophyte than the chapter on modelling for embedded systems, which is likely to be the domain of people who are far beyond the level of UML familiarity that this book is going to give you anyway.
ConclusionNow, even though as individual criticisms these might seem minor, as a whole it adds up to a book that's going to need a couple of companion references for the reader to truly feel ready to start diagramming with the UML in a professional environment. However, as said before, it isn't too expensive and is pretty much alone in the world of introductory manuals to the UML, and even if you're hoping to become a full-fledged analyst you have to learn to crawl before you can learn to walk, and this book will help you do just that. Just don't expect to be running marathons by the end.
Table of Contents( exploded version here)Introduction.
Hour 1. Introducing the UML.
Hour 2. Understanding Object-Orientation.
Hour 3. Working with Object-Orientation.
Hour 4. Working with Relationships.
Hour 5. Understanding Aggregations, Composites, Interfaces, and Realizations.
Hour 6. Introducing Use Cases.
Hour 7. Working with Use Case Diagrams.
Hour 8. Working with State Diagrams.
Hour 9. Working with Sequence Diagrams.
Hour 10. Working with Collaboration Diagrams.
Hour 11. Working with Activity Diagrams.
Hour 12. Working with Component Diagrams.
Hour 13. Working with Deployment Diagrams.
Hour 14. Understanding the Foundations of the UML.
Hour 15. Fitting the UML into a Development Process.
Hour 16. Introducing the Case Study.
Hour 17. Performing a Domain Analysis.
Hour 18. Gathering System Requirements.
Hour 19. Developing the Use Cases.
Hour 20. Getting into Interactions and State Changes.
Hour 21. Designing Look, Feel, and Deployment.
Hour 22. Understanding Design Patterns.
Hour 23. Modeling Embedded Systems.
Hour 24. Shaping the Future of the UML.
Appendix A. Quiz Answers.
Appendix B. Modeling Tools for the UML.
Appendix C. A Summary in Pictures.
Index.
Related Links SAMS
Object Management Group
OMG's UML Resource Page
Google Search for Case Tools
You can purchase Teach Yourself UML in 24 Hours at Fatbrain. Want to see your own review here? Read the review guidelines first, then use Slashdot's webform.
The 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...
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.
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. ;)
now i can add to my collection of alphabet books on html, xml, dhtml, uml, php, esp and add! woohoo!
Satanists get good grades too...suspiciously good grades
The problem with UML is that it doesn't really help to be pretty good with UML.
If everyone isn't completely proficient, you're back to square one, ambiguity, miscommunication of ideas, all the stuff that you're trying to avoid by using by UML.
Having said that, be aware that this the view of a computer artist that does some programming, not a dyed-in-wool enginner.
What were you expecting?
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.
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!
The Addison Wesley series is so thorough, complete and useful that I don't see how anything other than an extraodinary book could displace any of those volumes. Being as how this is a SAMS 24-hour book, I have a strong hunch it won't be that extraordinary...
psxndc
The emacs religion: to be saved, control excess.
XML is designed to allow systems to share data, and is textual.
Best Slashdot Co
I hate the "Learn X in 24 hours" or a day or a week. What's the point? They don't know how fast or slow I read. Are there really people who have to know UML within 24 hours?
I am not a number! I am a man! And don't you
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.
The O'Reilly UML Book is out of print, but fairly good.
Best Slashdot Co
When I give tech interviews, people who say they know UML get asked, so how do you use it? The blank stares I get are a riot.
"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
Free as in "the Truth shall set you..."
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.
The review mentions a void for beginning UML books. I think the void is filled quite well by UML Distilled by Martin Fowler and Kendall Scott. It provides an excellent, concise explanation of what UML is, how to use each UML artifact, and why you should care. Good for the beginner or those with short attention spans.
She came sliding down the alleyway like butter dripping off of a hot biscuit.
In the IT environments that I have been exposed to (Government, private sector, web-based business) EVERYONE models differently and none of the IT managers seem interested in UML. Why you ask? Because they do not have the willingness to modify pre-existing documentation or train the current application developers to use UML.
I for one am all for the Unified Modelling Language, but if I never use it in my work am I just wasting my time learning it?
crazy dynamite monkey
There's a fairly good UML site here. They have UML usenet archives, a message board, rational rose tips, etc.
Did it teach you UML in 24 hours?
Enquiring minds want to know!
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
square != quadrilateral for all values of quadrilateral.
;-)... (similarly, my favorite screwdriver doubles as a hammer and crowbar, but I own and use the latter tools anyways, because they do a better job)
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.
Remember that what's inside of you doesn't matter because nobody can see it.
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.
Now, the OMG believes in their acronyms the way the Irish believe in their whiskey,...
Sure. Just perpetuate the stereotype of the Irish being drunkards.
~~ What's stopping you?
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.
Rational Rose generates tons of UML diagrams. The way we handle it is to write out our documentation in a text editor, and send it to the Rational guy, who puts it in the model. Then we show the pretty diagrams to the customer.
Best Slashdot Co
It's not "the NASA", and it's not "the UML". "NASA" is an acronym used to identify the National Air and Space Administration. "UML" is an acronym used to identify the Unified Modelling Language. It does not matter what Booch, Rumbaugh, Jacobson or anyone else says. Learning to master the English language is not a programmers first priority, but this one seems pretty simple to me.
Stop-Prism.org: Opt Out of Surveillance
Weirdly enough I have an exam which is half on UML tomorrow morning. Scary.
I'd agree mainly with the failures of the book; learning UML wrt. soda machines doesn't really help me see what's going on seeing as I'm supposed to be seeing this from a software engineering viewpoint.
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.
And I'd agree with that completely; I'm completely unartistic and have difficulty in dealing with anything that's subjective because I find it hard not to be able to gauge my performance. The fact the author didn't point out where he was making these decisions didn't help, because I keep wondering if I'm understanding something wrong because he's decided to do something one particular way; I'm left wondering if the other way is acceptable or completely wrong.
I also felt like I was being dropped in at the deep end, being shown lots of different types of diagrams with no indication of how they go together until the case study (I presume, as I haven't got that far yet :-)
Oh well, it was the course-recommended text *sigh*
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)
Like you, I sketch things out as I'm designing them, and then toss the diagrams when I'm done. But mainly, I use UML for communicating with people. When discussing design questions, it's great to be able to go to a whiteboard and sketch things as you talk about them.
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.
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.
"from the that's-one-earth-rotation dept."
It's about four minutes longer than one earth rotation. Shame on you!
I think part of the wide-spread disappointment with UML is the 'UML is class diagrams' mindset. Most people know UML includes other diagrams besides class diagrams, but when they sit down with the intent to use UML to design or document a system, they start chunking out class diagrams, and often at a rediculously fine level of detail.
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.
Many years ago, using flow charts was a requirement in many software jobs. (For those of you less than 40, a flow chart was a stylized picture of small-scale flow control: little diamonds for "if", square blocks for computations, other funny shapes for IO, etc. All connected by arrows.) Flow charts were pretty useless, but you had to produce them, so we built tools that parsed Fortran77 and generated nice flow charts. No one actually used them, but they looked nice hanging outside your office, especially if you had access to a color flatbed plotter.
Now, I know that Rational can generate UML from code. Which makes me wonder how often UML is actually used for design and how often it's generated after the fact to make pointy-headed managers happy.
Disclaimer: I'm doing researches in UML.
First of all, it is NOT enough to employ only one diagram of UML. You have to use MULTIPLE diagrams to describe particular traits. So, class diagram must be accompanied by at least one of the behavioral diagrams such as state chart diagrams or collaboration diagrams.
Read the official UML books and you'll discover that there are three dimensions on the diagrams: structural, behavioral, and architectural. Any sufficiently large project should employ at least one of the diagrams that fall into each of the category to capture its holistic aspect.
The valid complaint is that the UML diagrams lack of coherence and details. For example: I found out that the three books (UML User Manual, UML Reference Manual, and the official UML Spec) are NOT consistent. Don't flame me on this. If you want to know, just find out about the event handling in state charts. Scutinize them in details. All three doesn't agree each other.
Lack of details hampers researches in this area. For example in state charts, how would you handle events? They say: Designer should not assume one. How can? The handling could dramatically alter the behavior of the state charts, whether it is buffered, channelled, direct, etc.
Because there is lack of details and coherence, you will find out that virtually ALL researches that claim using UML doesn't really have 100% UML conformance in it. Everyone assume their own form of UML, especially when there are no governing details.
--
Error 500: Internal sig error
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...
That's 24 hour 1 hour periods (a solid 24 hour block), not a day.
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).
Mod me down and I will become more powerful than you can possibly imagine!
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?
Is a case study of a "POS" system really the reference you want to follow??
Oh, wait... point of ... never mind.
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!
UML turns out to be an end in itself, not a means to an end. After you've wasted enough time with it you'll realize that its "Usless Modeling Language."
I sometimes think about how difficult it is to explain the concepts behind a software and its implementation to another person in plain english/other language. A similar situation must have been faced by early music composers. Now we have the music notations which has solved the expalnation of most intricate problems in music world.
Will UML be an equivalent thing for the business of software ? What does it lack now to get to that level ? What is the best method of learning it if you look at it from a different perspective.
Expecting to become an analyst by teaching yourself UML is like expecting to become an author by teaching yourself English.
Learning UML is a necessary, but not sufficient, step. The important thing to understand is object-oriented analysis. UML is just a tool (and a flaky one in some respects).
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Like many other people here i've made many attempts to find a way to integrate UML into my development cycle. I'm a visual person, i want to see things, I want to be able to draw clear pictures of what i'm trying to build. Unfortunately I find this very hard to do, while I understand the symbols and concepts of a class diagram, i still have a hard time figuring out how to draw one that effecively shows information about something that I am trying to design. What someone needs to write is a UML cookbook that take a set of common examples and shows how to created good diagrams to illustrate them.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
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...
"The Unified Modelling Language provides ways of modelling every sort of system that you can imagine"
I don't know, I can imagine quite a bit.
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.
This book was assigned to us for use in an Applied Software Development class. Never needed to crack it open though, since the instructor didn't refer to it. From what I could tell it would have been a pretty ambitious 24 hours though.
"Shared pain is lessened; shared joy is increased. Thus we refute entropy" - Spider Robinson
How can UML be considered Unviersal when it only supports Object Oriented Design and doesn't support Functional based programming?
UML is the language, not the essay. If you don't know what you want to say, any language will do - but if you do know what you want to say, at least in Software Design - UML gives you a way of describing it precisely.
In my current organisation, we took a couple of "difficult" projects, where the customer's needs weren't clear, and converted them over to UML. The results were amazing. In one case, we were able to make the customer gain a new appreciation of the complexity, and could re-negotiate the contract. In another scenario, we saved a huge amount of time in "usability" design, where software features were grouped around business workflows.
Where it failed - and consistently failed - was in teams where everyone did not switch over to UML (or converted under duress). We had cases where developers would rewrite the explicit instructions of UML into plain English, and loose the level of detail in the design.
If you want a real example of the power of UML, have a look at Argo UML. The tool really takes UML one step further, allowing you to see the Java code generated, and do full roundtrip in a single editor.
English is an imprecise language, and is very unsuited for expressing program functionality. It's even worse for documenting requirements. Thats where UML fits in, and in MHO, it does work.
"Now, the OMG believes in their acronyms the way the Irish believe in their whiskey . . . "
<rant>
But UML is not an acronym. Neither is OMG, or TLA, or the myriad other misidentified initials. These are abbreviations. An acronym is an abbreviation which spells, and is pronounced as, a word. If it's not a word, it's not an acronym.
Use a dictionary, dammit!
</rant>
the OMG believes in their acronyms
Am I the only one that had to re-read the article because the first time I read every OMG as "Oh, My God"?
Kilroy was here!
what has uml to do with formal modeling ??
I wonder if this is by the same author as either of these titles:
...
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
I Heart Sorting Networks
Beware of people who say "If you want to be any kind of , you MUST learn ".
These people usually rely on periodicals like Infoworld to "keep up with the industry", "keep up with technology", and generally discern their heads from their asses.
I'd wager most systems analysts on earth haven't even heard of UML.
Oracle's JDeveloper 9i has UML Class models that are in sync with your Java src code, change the code, the model changes and v. v.
? ja va.html
http://www.oracle.com/ip/develop/ids/index.html
Nice.
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
sarcasm ON
.. 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 [pictures].
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
"He was a wise man who invented beer." -- Plato
These books are usually pretty good at what they set out to do, that is trying to cover the basics of any subject from perl to xml to icq(!). The problem with them, and why I don't buy them (anymore) is simple: they never leave the bookshelf after you've read it the first time. Take it from me. They are standing there, gloating. :) They all make worthless references, with a poor chance of finding that fact you needed afterwards. It's the same thing as the "dummies"-books. Really, in them selves, in that small world, they are usually good. It just isn't enough for the second lap.
Grab some online tutorials, experiment some on your own and if you want to buy books - buy comprehensive references.
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.
"A word formed from the initial letters of a name, such as WAC for Women's Army Corps, or by combining initial letters or parts of a series of words, such as radar for radio detecting and ranging."
(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)
I DO like class diagrams as a way to visualize how code is structured. For example, I was able to reverse engineer some direct 3D libraries to help me navigate through the bloody mess they give you. But sequence and use-case diagrams are GHETTTO! For god sake just give me a flow chart... they tell the same amount of information and are easier to read!
http://webopedia.internet.com/TERM/a/acronym.html
I should have used this dictionary the first time.
The unpronounceable version of an Acronym is an 'Initialism'....
Incidentally, I'm asking in my capacity as the editor for a technical publishing company. I agree that many of the existing books are deficient in one way or another. What sort of book would address these deficiencies?
What would you rather? It was a good book...well written.
I know, I know. They say UML is just a modelling language, it's generic, you can extend it, etc.
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. It's simple and effective.
Okay, so this book will teach you how to model a relationship. But what I'm really looking for is a book that will teach me how to have a relationship with a model.
Milla Jovovich would be a nice start...
"People that quote themselves in their signatures bother me" - athakur999
Javaworld had an article on OO design recently, outlining alternatives to expensive modelling tools such as UML. Read more here.
For those that don't feel like reading the article, basically the author found that UML doesn't make life easier all the time, and the tools are painful to use efficiently.
So he decided to do away with all CASE / Modelling tools and draw things up on a whiteboard, and take photos with a digital camera. Using a software package to make the pictures clearer (correcting lighting, angle etc), the model diagram is available nearly immediately.
The costs are once-off (most software firms have whiteboards, markers already etc) for a digital camera and the whiteboard photo software. I quite liked the mix of seemingly primitive technology used, and pretty much all costs are once-off. Sure you still have to train them up about understanding some parts of the diagrams, but it would be a lot more intuitive. Training for the software... give them an hour for a slow learner.
I use TCM (The Toolkit for Conceptual Modeling). It has UML editors for static structurre diagrams, use-case diagrams, activity diagrams, collaboration diagrams, component diagrams and deployment diagrams, plus a few others that are being implemented. The web address for TCM is www.cs.utwente.nl/~tcm. I don't know too much about UML, but I do enjoy using the diagrams.
Sean Lane Fuller - The truth is out there!
The trouble with UML, as several posters have pointed out, is that the semantics of the language are ill-defined. There's no clear guideline as to when to use, for instance, ternary associations, or association classes. Hence, when people do use these things in their diagrams, miscommunications tend to occur.
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.
Luxury.
Of course, we had it tough.
We had to get into work at 6'o'clock in the morning, drink a cup of cold coffee, filthy cracked cup and all.
Then we'd write our own reference manuals, just to be able to use vi.
After that our boss would have us sit in meetings, and thrash us with demands.
But you know, we were happy in those days, though we we're overworked.
You try to tell the young people that today, and they won't believe you.
(With thanks to Monty Python.)
Stumbling in the dark
I hear slavering of jaws
Eaten by a grue.
I'd like to just add my 2bits worth in to this discussion; the usefulness of UML and it's advantages/disadvantages are not actually the issue, it doesn't make this book any better or worse. This is a good book, if you would like to learn UML. If I just play devils advocate and say that UML is a good visual representation of a 'System' (software or other) that is non platform or environment specific (i.e. Windows or Unix. C++ or Java) but does lack contraints that would normally apply in a development environment, then maybe it would be worth looking at the future of modelling and tighten the rules, and maybe come up with something like OCL (Object Constraint Language, see link below.) which is an extension to UML that is more capable of modelling a state oriented system (i.e. Most software programs). Object Constraing Language, IBM's Perspective.
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.
I've got no love of UML, but when I did have to use it I found the UML specs themselves to be quite good. I used version 1.3 but the latest (1.4) look like they are out. A simple introductory book (like the one by Martin Fowler) and this baby should see you right. It would also be nice if the specs. were better indexed, and more easily searchable.
One of the initial best parts of the UML was using use-cases. Use-cases helped to cut down on the amount of meetings that would take place during development/coding. Bfore this, just using paragraphs of text to decscribe the requirements, meeting after meeting while coding would take place to "clarify" things which was very disruptive to the project. UML is just a set of tools not a methodology... use those tools if they help you. Don't if they don't.
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.
Porsche hasn't made a cool car since they phased out the 924/928/944 type cars. (The sleek style like the Porsche in Rishy Business) Boxters look, well, like a box. The 911's are almost cool, but too Eurotrash looking.
I have seen high productivity start-ups adopting UML because
(a) accurate communication with clients is essential
(b) need max productivity from small staff numbers
(c) they have top people that can make best OO practices productive.
This is a market that other CASE vendors are persuing heavily. Different markets, both valid.
Jayfang
sorry the dog ate my sig.
I have seen fabulous productive C++ projects.
I have seen unmitigated disaster C++ projects.
C++ is not perfect, but it can be a great tool in the hands of the wise.
I think you can equate the two on that simple level.
Jayfang
move along, move along! nothing to see here!
- Do you understand software design?
- Do you understand UML?
For those of you who answered no to the first question: Think of system design in the same way as an architect who designs a house. Let's be honest, would you build a house without a blueprint? Now think of large software systems. Would you build a large software system without a blueprint?That is where UML comes in. UML is a language specification to model complex systems. The idea behind it is to be able to communicate ideas in an unambigueus way. Think of UML as the blueprint for building large software systems.
Poseiden for UML from gentleware is a commercial tool that evolved from ArgoUML. There is a free version (Community Edition) of Poseidon that is very effective for beginning users.
Sorry, had to do this . . .
1) The difference between composition and aggregation is defined in the UML spec. The spec is also relatively accessible and written in an understandable way.
2) It has been a long time since I wrote protocol stacks, but I use state diagrams all the time - it helps everyone on the team understand when certain behaviors or functions can and cannot occur. And nobody on the last team even knew UML. It didn't matter - I was able to capture my thoughts, validate them, and communicate it to the team. What was complex and hard for people to understand just by talking about it became real and we could move forward. And I had some documentation to boot.
3) UML does not equal case tool. I draw an oval and a box and a stick figure and tell a customer 'here is what the system should do'. They don't know its UML and I never paid money for Rational Rose. But the system gets done and the users know what they are getting.
4) Never, ever tell someone to never, ever use some feature of a language (okay, maybe goto). The features are there for a reason. Because one has not taken the time to either understand precisely how it should be used, or educate others on how it is being used or what is meant by a construct is not an argument against its use. It is better to say 'if you have a problem and don't know how to represent something, refer to the spec and learn how it should be done'.
I am glad I am not in your class.
1. My arse it is. I have a printed copy of the spec. It takes 3 lever arch files. Its vague, imprecise and cumbersome. If you think the difference between aggregation and composition is clear, go on and explain it. I can find 3 slightly contradictory explanations, all from "official" sources within a few minutes.
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
1. How many official sources are there? I am aware of only one - www.omg.org.
2. I never implied that I modeled an entire system on a single state transition diagram, or that I would use a state transition diagram on a system that had too few or too simple a set of states and transitions. In fact, I would use a similar rationale for any model or any other piece of documentation - if it isn't useful I wouldn't want to produce it. But when it is important to understand states and transitions, it is nice to have a notation for describing it. And as you are now pointing out, this does not only occur when writing protocol stacks.
3. To repeat, if it is useless in a given context, then I wouldn't use it. I think we are in agreement on this. So if you are in front of people and need to draw on a whiteboard, what is the problem with using UML use-case notation? Especially if everyone else in the room starts to 'get it' and offers input and feedback so that we have a higher confidence that we all know what is expected? And when I get back to my desk, I can draw the diagram in whatever tool I want, write up my scenarios and my narratives (which, last time I checked, are still English prose, which is a point that seems to be missed in much of this thread) and I have a far higher chance that everyone reading it and looking at the pictures is thinking the same thing. I don't consider that useless.
4. Agreed. I wouldn't tell someone to use something just for the sake of using it. But I have found more than enough ternary relationships, for example, to know that I am glad I can draw them when they occur, rather than saying 'gee, I never learned that, let me get creative to see if I can morph it into something different'. My point is that one should say, as many foreigners say, 'how do I say this?' Not that I am always pleased with how UML has chosen to address each and every need, but I would rather use it if it has already been defined.
Finally, I do not understand the confusion over representational language, methodology, and tool. They are related but orthogonal. I have gradually but consistently been adding UML diagrams to my work regardless of methodology or tools. One does not dictate the other. So I still don't understand this belief that UML = heavyweight, or UML = ornate, or a number of other misconceptions about how to use the language to communicate. It is that and only that - a language to be used for the purposes of communication. From that perspective, however, just as with any language, it gives me pause when people say 'I will teach you all you need to know in 2 hours,' instead of saying 'I will teach you enough in 2 hours to get started, but keep in mind that it is only the beginning.'
I have to agree with you mostly. My experience
is that every team that does any OO diagrams does class diagrams.
You almost don't have to tell people to do it.
My experience is also that almost no-one does sequence diagrams.
That could be changing as RUP and Rational Rose or
similar tools become more widely available.
I like to make sure that the class diagrams are correct by coming up with a few important scenarios and testing them with sequence diagrams.
But that is just my own personal perspective.
I think more in OO code and so I find a combination
of class and sequence diagrams.
People fulfilling other roles in software development may find
other parts of UML and their process
more usefull.
I have to admit that I forgot about class depencencies and module dependencies.
That is additional usefull information that goes
on the class diagrams.
Another personal bias/opinionn of mine is that
automatic code generation is overemphasized.
If you have good design documentation, writing
the code is the easiest part of development.
The coding goes so fast.
You have to expend a lot of extra effort to get the UML diagrams to generate the code properly.
You could spend more of a senior developer's time
that could be better spent helping out less senior developers.
I did use Rational Rose to generate code for the first several weeks of the development of a DLL.
I switched to manual coding when it became too difficult to make the code generation work.
The deciding factor was the inablity to get the
EXPORT qualifier that the DLLs needed in
the class definitions.
But the dependency relations in the class (or was it module) diagrams
caused the include statements to be inserted automatically.
Anyway, where I work now, we have no UML tools, and no QA department.
You just end up with more effort expended elsewhere.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
I understand what you mean about most code generators. All of them require you to accept what the designers decided, or code it yourself. I think this will change, though, as a greater understanding of the UML, and more importantly, patterns, comes to the industry.
One of the three amigos (Jacobson, I think) gave a speech describing what he called "UML all the way down." Basically, he meant that most (if not all) coding would be done at the UML level. I see a handful of tools moving in that direction already. Rose is one, Together is another, although OptimalJ (shameless plug on my part, I'm employed by Compuware) is the only one I've seen that generates a complete J2EE application from a diagram (deployment descriptors, JSP UI and all).
I'm also with you on the coding becoming the easy part of the process. I've found it to be a challenge explaining to management why we spend so much time in analysis and design. I have to say, though, that it's gotten easier now that we've been through the process a few times, and produced good software and happy users, on time.
In previous cycles, we've tended to do what diagramming needed to be done; just enough to communicate the design idea to the entire team. From there we went on to contract specification in comment headers, then to code. This has been very effective, as the end result of the design phase is to have the programmers just itching to fill out those signatures and contracts with implementations. The diagrams got us to the point of understanding the final solution well enough to visualize it in our mind. The other upside was that the bulk of the non-pictorial documentation lives with the code.
The only reason we haven't used code generation so far, is that we've not been working in a language supported by Rose, and OptimalJ has just come on the scene (we intend to use it internally).
All of that said, there will always be the Steve Gibson's of the world who eschew abstraction and write tight, small, effective assembler... for one platform... and only they can maintain it...
Anyway, happy coding.