Preface

In more than 20 years on projects and five years in the classroom, I've seen a lot of things change and a lot of things stay the same. I've watched people get thrown in every direction by the speed and impact of changes in technology, and I've listened to the same unchanging list of complaints:

• Poorly defined requirements
• Rapidly changing requirements
• Difficulties among IT and business team members and clients
• Estimates that can't be trusted because they are actually individualized guesses because no one has kept any development metrics
• The overwhelming challenge of maintaining existing systems with no documentation

So how can the Unified Modeling Language help solve these problems? UML has become an increasingly popular and powerful component of software development strategies around the world. More than 90 percent of the Fortune 500 companies use it in some form. Why? Because UML supplies some essential tools that support a professional response to these challenges. UML provides

• A consistent form of communication that works equally well in analysis and design
• A visual presentation that works equally well for technical and non-technical team members
• A formal yet flexible standard to ensure consistency and clarity
• An extensible language that may be tailored to any industry or application type
• A programming-language-independent way to specify software
• A rigorous means to specify software structure and behavior to generate code or even generate complete applications (executable UML)

Regardless of the method you use to apply it, UML supports the development of precise, consistent, and traceable communication that will survive the chaotic and rapid pace of change.

The goal of every book in the Bible series is to provide you with a comprehensive explanation of a topic, and in UML Bible you learn all about the Unified Modeling Language (UML): diagramming notations and semantics, the Object Constraint Language, Action Semantics, the UML Metamodel (2M), the XML Metamodel Interchange (XMI), and the evolution of the standard from UML 1.4 to UML 2.0.

UML Bible presents each concept in the UML specification with an introduction that assumes no prior knowledge and progresses through a complete description of its advanced application, while pointing out the changes from UML 1.4 to UML 2.0. For example, the Class diagram includes a number of modeling elements. Each element is explained from the basics to the complete specification. Then the entire Class diagram is explained, using the individual modeling elements together to build a complete example.

In like manner, many concepts at times come together, as in the relationships between Class diagrams and Sequence diagrams. Here, too, the book presents an introduction to the basic relationships and their consequences and then proceeds with a complete description of how those relationships might play out in your software modeling process.

This is unlike many other books that progress from beginning to end, using the first chapters as an introduction and later chapters for the more advanced topics. But I believe that you will find the approach in UML Bible most effective for this particular subject. You will quickly be able to recognize the presentation pattern. As you become accustomed to the approach, you can choose to skip over sections that you might already be familiar with and focus on the new material that is most useful to you.

It is my hope that UML Bible will provide you with both an appreciation for the usefulness of the software modeling resources of UML and a working knowledge of the tremendous potential that these tools and concepts have for improving the way you build software.

Who Should Read This Book

This book presents everything you need to know in order to become proficient and productive at modeling software with UML. It includes my own experience, and insights from many of the authors and teachers with whom I've had the pleasure of working, as well as the works of many of the industry leaders.

UML Bible is aimed primarily at those people responsible for the countless hours of communication between users and IT staff and at those tasked with turning the user's wishes into code. Participants at every level of the software development process stand to gain from this book:

• People who are new to OO modeling will get a step-by-step introduction to everything from basic concepts of object orientation that support the modeling notation and process to insights into the use and application of the models. You will quickly obtain a working knowledge of the diagrams used by your teammates so that you can become an active participant in the review and enhancement of the models.
• Experienced modelers will be able to dig a little deeper and discover the relationships between the various diagrams and how they may be used to test the quality and completeness of the whole model. If you want, you will be able to exploit the rigors of OCL and Action Semantics as well.
• Programmers will gain a working knowledge of the models that the analysts and designers are asking you to implement. Communication will improve as you become comfortable with the vocabulary used by both technical and non-technical team members to describe the software requirements. The models will become your roadmap for understanding existing systems, new systems, and ideas for enhancements in a way that code alone cannot, while leaving open the freedom to incorporate new techniques and technologies in your implementation.
• People evaluating modeling tools will gain a complete understanding of the features and benefits that you should expect from such a tool.
• Managers and project leaders will gain an appreciation for the power and value of the modeling process as a means to solve many of the problems that plague the software development process. Hopefully, you will also come to appreciate the value of having a rigorous and testable tool to understand and solve a problem before committing to the expense and uncertainty of code. In short, I hope you come to see that “the model is the code” (more of that sermon later . . . ).

Why You Need This Book

To get the most out of this book, you need to appreciate the intense challenges inherent in today's software development environment. Smarter people than I have worked long years at developing real-world strategies to address these challenges. UML is the distillation of a key component of many of these road-tested strategies, namely, communication.

Communication of needs and ideas is the substance of the software development process. The quality of communication between analysts, developers, trainers, testers, managers, and users can make or break a project.

As a software professional, you are used to dealing with most, if not all, of these classic communication challenges. See whether these examples sound familiar.

Poor communication leads to delays and extra cost

As systems change, all project participants must keep informed of the nature and impact of those changes on the requirements and solutions already in progress or already implemented. Without a standard way to communicate, everyone is left to his own creativity. You've probably seen teams where more time is spent in meetings than actually working. The meetings use up valuable time in an effort to communicate. One person uses flowcharts; another person uses screen layouts; others use volumes of written specifications. The project incurs the overhead of becoming familiar with a variety of communication styles and techniques.

Meanwhile, individual developers who need to apply badly needed changes have to instead labor with widely varied types of documentation to try to understand and repair complex systems. In a straw poll that I conduct in each class, students are asked how they handle a request to change an existing system when the documentation is difficult to understand or nonexistent. Almost without exception, the students say they simply rewrite the code. For those of you managing the budget, that means that they are throwing away a corporate asset simply because they can't understand it and didn't have the time to try. Then they are spending more time creating an entirely new and untried solution than they would in making a simple correction—if they only knew where to make it.

Translation: Poor communication = slower projects and higher cost of maintenance

The volatile nature of the IT work environment

Between corporate restructuring, economic ups and downs, and team members' personal lives, teams are constantly changing. The typical mode of each developer keeping everything in her head or in what she believes is well-documented code produces a tremendous liability. As people move from project to project and as priorities shift and budgets are cut, the knowledge of the system goes away with the well-meaning people who last worked on it.

Many of you are living with this problem today. Two years ago, when companies were throwing money at IT, you had plenty of staff to cover each system. Since the summer of 2001 the situation has changed substantially. Where you once had people dedicated to each system, you now have one person covering five systems that he's never seen before. Without a description of the workings of the system, the only way to know how to make changes is to read thousands of lines of code. While the staff is reading, it isn't making the badly needed changes. When changes are made, no one can be certain that they are the right changes.

A system is a corporate asset and as such it must live beyond the participation of any one individual, and it must do so without incurring the overhead of rewriting with every change in personnel.

Lack of control over the development process and product quality

Another consequence of developers keeping everything in their heads or in the code itself is the complete trust demanded of management. Unless a manager is willing to learn and read the code herself, she cannot assess the quality of the product. Testing is the standard response to this problem. But any programmer knows that it is easy to get an application to pass the test suite. After all, in many cases it is the developer who writes the tests. Consequently, the application works “just like I said it would.” But does it work like it really should?

Quality is more than passing a test. Quality implies durability, flexibility, maintainability, low cost of maintenance, and much more. Unfortunately, because code is difficult to understand and poorly documented, if documented at all, over time the code becomes a collage of patches and add-ons in response to change requests. I suspect that if you would poll your team and evaluate your own experience, you'd find that most rewrites of systems result in radically reduced amounts of code yet increased functionality specifically because rewriting enables you to eliminate all of those patches and focus back on the real requirements.

The foremost lesson that I hope you take away from this book is that every participant on a project has to go through the same thought process to decide what code to write. Modeling is simply a visual and standardized way to step through that thought process of leveling a way that all participants can understand, verify, and discuss. With the current modeling tools available, there is every opportunity to keep your models in sync with your code, or even generate and maintain your code from the models, while never actually touching the code.

Changing requirements

The longstanding rift between IT project members and clients nearly always centers on requirements. In fact, Capers Jones of Software Productivity Research, and author of Software Systems Failure and Success, did a study on litigation over software. Almost without exception, software litigation is based on a debate over requirements. The clients claim that their requirements were not satisfied. IT says that the clients kept changing their requirements. What is even more disturbing about the results of this study is the fact that all of the projects studied were bound by contract. How much worse is the problem where there is no contract that formalizes the requirements?

Without means to track requirements and means to trace those requirements into the finished product, there is no way to find out where the problems crop up. Is the client really changing his mind? Did IT really fail to include requirements? In my experience, I have found that when an analyst or designer does not have a disciplined approach to gathering requirements, the project hinges on intangible and highly risky factors: the developer's memory, work habits, personal life, communication skills, and his relationship with the client. If any of these factors is less than ideal, the project is at risk.

Very often it is not true that the client changed her mind. Instead, the developer simply did not ask the right questions, did not ask the right people, or simply did not challenge what the client was telling him. The developer may be hurried and have no interview plan and no way to capture the client's knowledge except with notes and non-standard drawings, neither of which may be tested or traced.

A standardized approach to analysis and to capturing the work products of analysis can rapidly eliminate these problems and just as rapidly elevate the skill level of the people using them. Using the same techniques over and over, sharing the results with others using the same techniques, and using the work products to communicate with all participants in the development effort fosters proficiency and facility and reduces the possibility of misunderstandings and misrepresentations.

The debate over methods and tools

It is easy lately to get caught up in the feverish debate over development methodologies. Tool vendors know this best because they have to support these warring factions. Every software development method has at least three parts: a process, process management, and a vocabulary for expressing the work products of the process. Process management follows many of the same principles used for managing other business processes. The process itself is a still greater challenge. Software development is far too diversified to allow just one process. Transaction-oriented systems simply are not the same as real-time systems, which are different still from game software or e-commerce. Even the size of the specific project changes the process requirements.

What can be standardized is the vocabulary for expressing the work products of the process. UML offers a solution for standardizing the way you describe your work products no matter what method you follow. It does not dictate that you use all of the features or how you use them. But it does help ensure that we can all express our knowledge and ideas in a consistent manner that we can all understand equally, which radically reduces the learning curve and the time needed to share requirements and ideas about solutions.

This standardization has opened the door for a wealth of tools that automate the creation, maintenance, and tracking of these work products. With the standard in place, the vendors have been able to focus more effort on feature-rich development environments, customization, and integration with valuable technologies such as database management systems, change management, integrated development environments (IDE), and frameworks.

The demand for cost effective and high quality systems

A particular strength of modeling is that it reveals our assumptions. Without reading mountains of code we can measure communication traffic, evaluate quality by assessing coupling and cohesion, and test our models before we write faulty code. Modeling accomplishes these objectives by raising the level of abstraction. Years ago we wrote Assembler code, just one level above machine language. Then we moved to third-generation languages such as COBOL. The assembly programmers of the time thought COBOL just couldn't do what Assembler could do and would eventually go away. They insisted that to write applications, you had to know how the machine really works. How many of you (other than game programmers) write any Assembler today, let alone develop systems with it? In contrast, how many hundreds of millions of lines of COBOL code are in production today?

The Assembler programmers were missing an essential fact in their machine-centric perspective. That is, the only reason to write code is to solve a problem. The machine and the languages are tools to solve a problem, not the end itself. Still today, when our focus is forced onto the technology (Java versus C++, JSP versus ASP, and so forth) and away from the problem, we risk losing sight of our real purpose and the factors that define true success, and that is not whether the code is finished, but does the application do what we need it to do and can it survive the inevitable changes?

UML is an attempt to express in precise, familiar, and consistent language everything needed to generate complete, stable, maintainable systems. UML is a level of abstraction above the current programming languages, just like COBOL was a level above Assembler. People like Leon Starr and Stephen Mellor have been generating complete systems from models since the mid-1980s. I'm not talking about code generators that belched out bloated low-performance code, or CASE tools that generate Java declarations but not the method body. I'm talking about customized generation of the complete application, even generating a single model in multiple implementation environments.

The question is not whether this is possible. The question is, when will we adopt modeling as the next generation of coding? Oops, I tripped over my soapbox again… .

How This Book Is Organized

This book is organized into Parts, which are groups of chapters that deal with a common theme. Here's what you'll find:

Part I: An Introduction to UML

UML is actually the culmination of years of effort to isolate and standardize the tools used to express business and software concepts. Chapter 1 explains the development of UML so that you can understand what it looks like today and why. Other chapters introduce you to UML architecture, the UML diagrams and extensions, and the basic concepts of object orientation that provide the foundation for the modeling concepts captured in UML diagrams.

Part II: Modeling Object Structure

UML defines a number of diagrams suited to capturing unique aspects of software requirements. One such aspect includes definitions of the resources used by the application and the resources that make up the application itself. Part II covers the Class and Object diagrams, as well as the Composite Structure diagram and collaborations, including their structure and usage. The modeling elements explained include classes, attributes, operations, associations, objects, links, inheritance, and patterns.

Part III: Modeling Object Interactions

Once the resources have been identified and you have scoped their purpose and role within the design, you need to put the resources to work. Work implies cooperation. Cooperation requires communication. Part III presents the many different interaction diagrams used to model how objects talk to one another when you run the application. It also explains the use of the Statechart diagram to model the changes in an object over its lifetime. The modeling elements explained include messages, events, and states.

Part IV: Modeling Object Behavior

It is one thing to say that a system or object does something. It is another thing entirely to explain how it is supposed to do that something. Part IV explains how the UML Use Case diagram models the behavior of a system from the perspective of the users, while the Activity diagram can model behavior at any level of abstraction from workflow to method implementation. The modeling elements explained in this part include use cases, actors, dependencies, activities, decisions, object flow, and partitions.

Part V: Modeling the Application Architecture

When you are ready to implement your system, or understand an existing implementation, you'll need a way to model the software and hardware elements that make up the system configuration. Part V illustrates the use of the Component and Deployment diagrams for modeling the implementation environment. The modeling elements explained include packages, components and artifacts, nodes, interfaces, and ports.

Part VI: Bringing Rigor to the Model

Part VI takes you beyond the diagrams of the UML standard to the syntax and semantics for implementing requirements regarding rules and behavior. The Object Constraint Language enables you to model the rules that define the correctness of the relationships between model elements and the validity of values for a model element. Action Semantics enable you to specify, in an implementation-language-independent manner, behaviors that are ultimately implemented in code.

Part VII: Automating the UML Modeling Process

The UML standard has made it easier for modeling tool vendors to support the diagramming process and code generation. Part VII offers a description of the capabilities of today's modeling tools. Beyond the tools, or rather beneath the tools, lie the infrastructure elements that make using the models and exchanging them possible. This part presents the XML Model Interchange (XMI) standard that helps make it possible to share models between modeling tools and other XMI-compatible applications. Finally, it explains how the UML can be customized using Profiles that tailor the features of the UML diagramming standard to specific industries or application types.

The Companion Web Site

The companion Web site for this book, located at www.wiley.com/compbooks/pender, includes the following elements:

• A list of UML resources so that you can keep up with the latest news on UML developments, tools, vendors, and forums.
• Modeling tool vendor links so that you can investigate the available tools.
• Links to online courses about using UML
• The complete set of diagrams for the Ticketing System in PDF format and the original modeling tool files.

Conventions Used in This Book

Every chapter in this book opens with a quick look at what's in the chapter and closes with a summary. Along the way, you also find icons in the margins to draw your attention to specific topics and items of interest.

Here's what the icons mean:

Since one purpose of this book is to highlight the changes between UML 1.4 and UML 2.0, I often use figures that highlight the new or modified portions of the UML metamodel. Figure FM-1 is an example of a diagram that uses gray shading to identify differences between the two versions of UML. The gray rounded rectangle is not part of the UML notation. It is there only to help you quickly identify the details that have changed.

Figure FM-1: Using gray shaded rounded rectangles to highlight changes in the metamodel.

I use the same convention when I need to focus attention on a specific item in a diagram, especially when explaining examples for concepts and notations, as shown in Figure FM-2. Here, as in the previous example, the gray rounded rectangles are used only to help identify key elements of the figure. They are not part of the UML notation.

Figure FM-2: Using gray shaded rounded rectangles to highlight elements of an illustration.