Introduction
Topics Covered in This Introduction
What Can You Expect from This Book?
Who Should Read This Book? Read This Section!
What Can You Expect from This Book?
Goals
A better way to answer this question is to tell you first why we wrote this book. After all, a host of UML books are on the bookstore shelves now. So why did we decide to write yet another one?
Over the years, we have spoken with thousands of individuals from hundreds of companies around the world, and we learned from them that the average person involved in software development projects, even if he or she has a technical background, often sees the UML as unapproachable. People view it as so large and complex a subject that they do not have enough time to learn it. The typical UML book reinforces their beliefs because it usually incorporates numerous complex diagrams with long explanations of cryptic notations, not unlike a typical computer programming language manual. This turns off most people, except for the most passionate modelers.
Another important fact that became apparent is that most people who play a role in the software development process generally do not model on a regular basis, a fact that most UML books ignore. So, in UML For Mere Mortals®, we will focus on how the UML addresses the audience's needs, not UML modeling for its own sake.
Here are our goals for this book:
To introduce the UML to those technical and non-technical people who are stakeholders in software development projects but who are not hard-core modelers.
To do so in a manner that is easy to understand, addressing the core concepts of the UML that all mere mortals need to know.
To address the UML in terms of the specific concerns of these readers.
If these goals align with your needs, this is the book for you.
Style
This book is written in a different style and organized differently from most UML texts. Most books take a “structural” approach to introducing UML, organizing the chapters by diagram type. Within the chapter, they explain all the details of each element you might find on those diagrams. This is fine for a component-by-component learning style. However, we take a “user-centric” approach, presenting the UML within a context that is relevant to a particular reader's role and the activities that that reader needs to perform on the job.
The chapters in this book are organized by major activities people perform on development projects. Then, we present the UML elements that are most useful in those activities, to the level and depth that is appropriate for those activities. In this manner, you can learn enough of the UML for the role you play in digestible chunks.
This organization creates an interesting side effect. Because a number of the UML elements are used in more than one development activity, these elements might appear in more than one chapter. Although this might appear redundant, the later chapters will typically reintroduce the topic and then discuss the specific UML elements in more detail or discuss the different way they are used for that activity. Thus, you can learn the basics about an element in an early chapter, and if that's all you need or want, that is fine. If you want to learn more details, you will find them in a subsequent chapter. In addition, revisiting a topic in a subsequent chapter will help reinforce the basic UML concepts for you.
Who Should Read This Book? Read This Section!
Please do not overlook this section. You only have so much time and money to invest in expanding your professional knowledge. We're sure you don't want to spend those precious personal resources on things that don't help you. This is why it is so important to read this section of any book you are considering for purchase. Obviously, we would like our readers to have a positive experience with this book. We want this book to meet your needs.
As mentioned before, the main audience for this book can be described as people who play a role in the software development process but who generally do not model on a regular basis. These people are not the avid software modelers who develop models routinely. Some examples of the primary readers of this book are as follows:
Business people who are responsible for improving their business's market position and are using software development as a key component in addressing the business goals.
Business analysts who are responsible for creating system requirements to address the needs of the business.
Software architects and designers who do not know the UML but who need to build flexible, resilient systems and want to start specifying these systems with the UML.
Development managers and team leaders who are involved with or responsible for executing successful software development projects.
Programmers who do not know the UML but who must implement the software designs that they receive, which are expressed in the UML.
Database designers who work with teams using the UML or who want to learn the basics about UML in general and UML for database design.
Educators who want to or are teaching introductory UML classes.
Technical writers who need to translate UML-based specifications into documentation.
Anyone whom the boss asks to teach him or her about the UML. Just hand the boss this book and go back to work.
If you find yourself in one of these groups, or something similar, we believe this book will meet your expectations. (Just to make sure, if you haven't read the previous section, “What Can You Expect from This Book?,” please do so.) When we meet you at a conference or at your company, we'd love to hear about your positive experiences with this material.
In summary, this book is intended for the person who is fairly new to the UML and would like to understand what UML is about, where it fits in their job environment, and how to understand the models they receive from others in their workplace. It is not intended to teach the entire UML, nor is it our plan to teach the process of object-oriented analysis and design or software development. As the title of this book indicates (UML for Mere Mortals), it is for the person who might not be an experienced software architect or expert designer, but who is part of the other 80% of the development community who just have a need or will to understand a bit more.
How to Read This Book
UML Coverage
This book is structured to give you just enough UML, just in time. As we said earlier, this book is not intended to show you every nook and cranny of every UML element. Plenty of large, thick, thrilling UML manuals are out there for that purpose—definitely not for mere mortals.
One of the major truths that the practitioners we have talked to have validated is that nobody uses the entire UML. Just as studies have shown that the average English-speaking person uses less than 3,000 words of the English language, most people use less than half the diagrams in the UML. We want to give you enough information on the parts of the UML that you will see most often.
To that end, most of the content of this book focuses on those areas of the UML that you are most likely to run into on development projects. Those will be the areas that our real-world customers have told us they use most frequently. These key areas will get most of the coverage because they will be the most useful to you. We will also cover other areas of the UML, just in less depth.
UML Versions
At the time of this writing, the latest fully approved version is UML 1.5. That being said, UML 2.0 is working its way through the final approval process. The formal and final approval is expected this year. Keep the following in mind, even after UML 2.0 is formally released:
Most of the existing UML models you will be working with for the time being will be UML 1.5 (or even 1.4). Most people won't change over to UML 2.0 immediately. (They will be in the middle of an ongoing projects using an earlier version, or they won't roll out new UML 2.0 modeling tools mid-project, or they will stay with their current version until they learn UML 2.0, and so forth.)
When discussing their models, people will still use the earlier UML terminology for some time because they have used it for years, so you will need to be familiar with both versions because of both this and the previous reason.
Only about 25% of the new changes in UML 2.0 will be seen by users. (Most of the changes are to the “infrastructure” and are not visible to the end users.)
Most modeling practitioners (non-mere mortals) use only a small portion of the UML. Thus, it can be expected that mere mortals will use even less. A mere mortal might encounter only a few of the UML 2.0 changes.
Because of these reasons, we decided to address the new version changes in a pragmatic manner. Where there is a change in the diagrams between UML 1.5 and 2.0, and where those changes are relevant to mere mortals, the text will introduce the concepts using UML 1.5 and will note any significant change for UML 2.0. Subsequently, in a later chapter that discusses UML 2.0, those changes that are most important to mere mortals will be addressed more fully.
Advanced Topics
Along with introducing the UML basics and answering the most common questions on a given UML topic, most chapters have a “Topics to Consider” section. This section simply introduces some of the more advanced considerations on a given UML topic, without further elaboration. If you have the desire to go deeper in a given topic, these are the areas where you can start. In other words, these are areas “for the interested student” to pursue on his or her own with the aid of an advanced text or experienced mentor. You might want to begin with some of the selected resources cited in Chapter 10 and at the end of each chapter.
Callouts
While reading, you will encounter other artifacts in this book. There are various types of “callouts” or sidebars throughout the chapters. First are the Deep Dive callouts, indicated by the preceding icon. While this is a book for mere mortals, there are some more in depth topics that you will need to know about. They are important because it is likely you will run into them in practice.
This brings us to the next type—the Real World callout identified with the preceding icon. People always want to know more about what other people in the industry are doing in general and what they are doing with the UML. The Real World callouts are intended to bring you the experiences that we, our colleagues, or other people have had working for various companies on real-world projects.
Because these real experiences enable all of us to learn from the problems real practitioners have experienced, we have an obligation to try not to embarrass anyone. So we have omitted company names and locations, written the stories in the first person, and elided some of the details to protect the innocent (and sometimes the not-so innocent).
You will also see a Lessons Learned icon to give you quick access to important takeaways (often associated with the Real World experiences).
The last type of callout is the Watch Out callout marked with the preceding icon. These discuss the pitfalls people often run into that you want to avoid.
Paths
You can take various paths when reading this book:
If you are brand new to the UML and modeling, simply read the book linearly. Pay particular attention to Chapter 9 and do all the review questions.
If you just want an overview of the most often seen UML topics, read Chapters 2 through 6. You might want to skip the Deep Dives and the Topics to Consider sections. You should also reinforce what you learn by answering all the review questions. This should help you enough so that you will not be completely lost if someone puts a UML diagram in front of you.
If you want to be able to contribute (as a mere mortal) to modeling discussions when a UML design is presented to you, read Chapters 2 through 8, paying close attention to all the callouts and review questions, and even take the time to do some self-study on the Topics to Consider that are appropriate to your situation (the references in Chapter 10 can help you here).
If you need to “bootstrap” yourself on a particular area of modeling, say, modeling an architecture or modeling requirements, go to that particular chapter. This might require you to cross-reference other areas of the text.
If you are a modeling practitioner who already knows the basics, you might want to sharpen some of your skills by focusing on the Deep Dive, Real World, and Watch Out areas and exploring the Topics to Consider. You might also want to fully read the chapters covering the areas where you might not have experience using the UML, for example, using UML for database design or for business modeling.
However you choose to approach this book, we hope you enjoy it.