UML Applied

I WANT TO TELL YOU about three things: 1) myself, 2) my view of UML, process, and . NET and 3) Martin L. Shoemaker. From these three things, I hope to give you a per- spective on the value this book offers me-and most likely you, too. About Me As a developer, I've been "introduced" to several development processes and methodologies. The documentation for these processes literally covered feet of shelf space. I've also encountered a number of diagramming systems. To me, most of the latter come across as a boatload of funny symbols with a bunch of nuanced meanings dreamed up by their inventors and proponents. In both cases, I could easily see a half year of my life dedicated to understanding these systems. What would I gain from investing so much time in learning how someone else thinks about building software? And, if I do invest the time to learn a new vocabulary to discuss software systems, with whom will I communicate? Let's face it, irrespective of the part of the software lifecycle you're involved in, you're expected to produce something that looks or behaves in a specific, predictable manner. Note that I didn't say we always know what form that behavior will take What I'm getting at here is that we have to have a mental model of what we're creating, and that model must be communicated and understood. To be successful, that model must also be complete and internally consistent.