Update: students attending the public presentations of this course will receive a copy of Martin's UML Applied.

Intensive Workshop into Object-Oriented Analysis & Design with UML
UML BootCamp is the ideal class for learning the Unified Modeling Language in a classroom setting. It starts with our 5-Step UML workshop, THE class for busy developers and busy teams: a hands-on team workshop that presents a stripped-down UML-based process that is suitable for both individual and small-team projects. Attendees will learn the basics of use case, activity, class, and component diagrams, as well as a basic process for applying UML. This is the right course for people who already know UML notation, but who need ideas on how to apply it. It's also a class for people who want to quickly learn basic UML in the context of learning how to use it on their projects. Attendees will work in teams on projects of their choosing, and will go through requirements gathering, analysis, architecture, and design of their solutions, all within one day. Thus, this is a great class for analysts, developers, managers, testers, documenters, and anyone else involved in specifying and designing software.

Then, after 5-Step UML shows you the basics of UML and the benefits it provides in system analysis and design, we’ll proceed to UML in depth. We’ll revisit each UML diagram type and explore its more detailed notations, experiment with ways to diagram different concepts, and discuss the limitations and strengths of each diagram type. We’ll also explore how UML designs and code can be tied together, both manually and with automated tools. (Although UML BootCamp is normally taught using Rational XDE, we also teach it using Rational ROSE and Microsoft Visio. And we have a pencil-and-paper only version which puts more emphasis on problem-solving, since you won’t have to spend time learning a UML tool.) And we’ll learn how UML supports project estimation, project management, testing, and documentation.

UML BootCamp will give you a thorough classroom introduction to OOAD with UML. But if you prefer to learn by doing in the context of a real project, check out our Accelerated UML class.

Here's what previous students of our UML BootCamps have said.

Request an On-Site presentation of this Class

Back to top

Back to top

I flew to Manila on a Boeing 747-400. Before the very first jet in that series was started down the assembly line, the Boeing engineers built models -- both physical and virtual -- to explore the new design for aerodynamics, safety, and features. I flew out of the new Northwest World Gateway terminal in Detroit, which was constructed as a model before ground was broken. I drove to the airport in a car that was preceded by a model, crossing bridges that were preceded by models. A core strategy in engineering is the construction of models: a low-cost, high-speed technique for exploring a design for problems and examining it for alternative approaches long before committing to a long, difficult construction phase. Why should software be any different?

My answer may surprise you: in software development, we need models more. This answer surprises many people, because at the surface, a software model is a hard concept to grasp. A hotel model looks like a hotel, but smaller; a jet model looks like a jet, but smaller; and so on. For those physical objects, a model looks just like the final product, only smaller. But software isn't physical, so the idea of reducing its scale is harder to grasp. The user interface, the physical "surface" of the software, cannot really be reduced in scale; and what lies behind the surface is an incredibly complex multidimensional interrelationship of data and operations and concepts and interfaces, all represented in source code. It's conceptual, not physical. A "scaled-down" version of the source code itself would not convey meaning in the same way that a scaled-down jet does.

But it's that very complexity that demands modeling. Large, complex systems are too vast for us to comprehend all at once; but we can understand the essentials of these systems, or of parts of these systems, by constructing conceptual models. These are not scaled-down representative models, but rather abstract models that capture the essence of a complex system in a more tangible form. Scientists and engineers and mathematicians who study complex systems use conceptual models to represent and study things which cannot be easily observed directly: climate and weather models for weather forecasting, turbulence models for aerodynamic design, financial models for business forecasting, demographic models for population studies, string models to represent quantum interactions and the structure of the universe itself. And while software development isn't exactly quantum physics, it's certainly a complex task that benefits from good models. That's the purpose of the Unified Modeling Language: to provide a standard notation for representing the most commonly useful abstractions in software development. With UML, we have a good tool for building software models.

And because of its unique nature, software development can benefit from models in ways that no other discipline can. Software, after all, is nothing but a manifestation of abstract concepts in a useful form. There is no tangible product created, just knowledge and ideas captured in a medium where they can be easily applied and reused. So while the jet builder and the hotel architect must at some point stop building the model and start over building the real thing, we can evolve our models directly into the real thing. That's one key aspect of what I call Model-Driven Development: every software problem that can be solved in the model should be solved in the model, and then automatically translated into the code without human intervention; and then only those issues that must be solved in code are coded manually. This code generation is controversial among many developers; but that's just the latest manifestation of a long-running controversy. At one time, it was common to hear skilled assembly language programmers raise the same objections about high-level languages. "We can't trust the assembly code that the compiler will generate." "The assembly code that the compiler generates isn't easy to read." "I could write more efficient assembly code by hand." "If I ever have to go in and hand-tweak the assembly code, the compiler may overwrite my changes." And so on. Yet today, only code which absolutely must be efficient is written in assembly code by hand. Why? Because high-level languages allow greater abstraction and greater efficiency and faster development and easier maintenance, so that it is impossible to justify assembly development in all but the most critical code sections. Well, for many parts of the software, UML is the new high-level language, allowing even greater abstraction, even greater efficiency, even faster development, and even easier maintenance. And just as ease and efficiency of development moved the industry away from assembly language, MDD will become the only sensible way to develop the bulk of your code. Try it. You'll be surprised.

But code generation and maintenance is only one benefit of Model-Driven Development. With a good modeling tool, your models can become the central artifact for all aspects of software development: not just coding, but requirements gathering, analysis, architecture, management, planning, estimating, scheduling, reporting, tracking, communications, testing, documentation, maintenance, support... even marketing. The models can serve as a road map and a central repository for everything that is known about the system, as well as a central springboard for launching all of the tasks in developing and maintaining software systems both large and small. But for MDD to serve all of those needs, you'll need good tools.

Back to top

Back to top

Back to top

But there’s another way. We can save a lot of time if we don’t struggle to learn the complex-but-powerful ways of a UML tool. We would never recommend UML without a UML tool for production work, but we have found that if we concentrate only on the notation with paper and pencil it gives us more time for more in-depth exercises. You don’t have to spend mental energy on the tool, and can instead work more on thinking in UML. Thus, we offer a pencil-and-paper version of the UML BootCamp, with more emphasis on solving problems on your own and reviewing your solutions with others.

Back to top

Back to top

You should also be at least familiar with the basics of Object Oriented thinking, in which systems are modeled and designed as a set of collaborating objects. We will spend very little time on the following basic concepts:

And it will be helpful (though not essential) if you are familiar with the concepts of component software development, particularly interfaces. COM or CORBA experience -- i.e., IDL experience -- is particularly helpful. Sorry, no hand-holding here: we assume you have been part of a development effort (while acknowledging that few people can be involved in every aspect) and can grasp.

II. UML: The Big Picture
Once you have seen UML in action, you will want to learn more about the purposes and principles of the Unified Modeling Language. This session is a general introduction to these issues, the “why” behind the “how” that you have practiced. This will include: guidelines for diagrams that communicate better, a discussion of models and various kinds of models, a discussion of views and packages as a way to isolate related model elements, and a brief introduction to each of the diagrams with an emphasis on reading and comprehending the intent of each. We will also discuss how these diagrams serve as inputs not just into development itself, but into planning, documentation, and testing as well.

III. Model-Driven Development
Five Step UML is a simple, hands-on process centered on UML, but it is not robust enough for most large development efforts. In this session, we shall introduce Model-Driven Development: a flexible, controlled Object-Oriented development process built around UML models. The emphasis is on how to construct the system via the process, and on how to manage the construction. The process also encompasses the disciplines of testing and documentation, and provides ways to ensure that these are ongoing activities rather than last-minute considerations. This session will give you an overview of the process, which will then be explored in more detail in later sessions.

IV. Use Case Diagrams
The logical structure of a system is a static view: it describes what a system is, but not what it does. UML provides a number of ways to design and diagram the behavior of a system. In this session, we will discuss the most fundamental of the dynamic diagrams, the Use Case Diagram. We will see how Use Cases describe the behavior that is visible to entities outside the system, and provide a way of diagramming the requirements of the system.

V. Activity Diagrams
Where Use Cases describe the required behavior of a system, Activity Diagrams depict the implementation of that behavior. In this session, we will explore how these diagrams can elaborate various Scenarios that occur as the system operates, as well as how various elements of the system participate in the Scenarios. In addition, some activities in a system must be performed in a particular order, which must be specified precisely; while other activities may be performed in any order, and yet others must be performed simultaneously. We will also examine how Activity Diagrams depict both synchronous and asynchronous activities within a system.

VI. The Requirements Stage
In this session, we will examine how to use Use Cases and Activity Diagrams (and other diagrams as necessary) to capture the requirements of a system. We will discuss various approaches for gathering requirements, as well as a process for reviewing and refining the requirements. Then we will apply these techniques to analyze and diagram the requirements for a sample project.

VII. .NET is an Elephant
Confused by all the .NET hype? Wondering how .NET will change the way you develop and work tomorrow? Or just wondering what an elephant has to do with it? This session will be an overview of .NET and the .NET Framework, the core services in the new object-oriented .NET API. .NET provides a vast sweep of new reusable services, covering everything from window processing to Internet applications and beyond. In fact, the .NET Framework is so large that it's easy to miss the forest for the trees. Each .NET expert enthuses about the features that he or she finds most interesting; so as you listen to different experts, you may get a very disjoint, confusing, or even conflicting picture of what .NET is all about. We will take an exploratory journey through the .NET forest, showing you some of the more interesting sights you might otherwise have missed. Learn what .NET is all about from the inside, so you can better evaluate the hype and see how .NET can help you.

VIII. Component Diagrams
The classes and code of a system must ultimately result in components: executables, libraries, COM components, etc. In this session, we will examine how Component Diagrams depict the architecture of the system, and how the components within that architecture relate to each other.

IX. Sequence Diagrams
Activity Diagrams are one way to describe the behavior of the system; but though they express the relations between objects and the methods involved, they do not explore these relations in the level of detail expected by the implementers of the objects. The Activity Diagrams can be transformed into Sequence Diagrams, another notation for depicting the flow of messages between objects.

X. The Architecture Stage
Most modern systems break from the old “monolithic” application mold, and are instead made up of multiple interacting components. The key to successful design of such systems is to properly describe existing interfaces and specify new interfaces that allow these components to interact. In this session, we will discuss how to use Component Diagrams, Activity Diagrams, Sequence Diagrams, and other model diagrams as appropriate to describe the relations between these components. We will also examine a process for reviewing and refining these relations.Then we will apply these techniques to design and review the architecture model for a sample project.

XI. The Architecture and Planning Stage
In this session, we will discuss the general process of planning, estimating, and scheduling based on a UML model; and we will explore how VS.NET, XDE, and other tools can aid in this planning. We will explain how the designs and diagrams known at any given point can serve as the basis for estimates and schedules; and we will discuss ways to create and evaluate the estimates and schedules. Then we shall review the architecture model of our sample project and devise plans, estimates, and schedules based on it.

XII. Class Diagrams
Classes and objects are the core elements of all Object-Oriented languages. In this session, we will discuss how UML can be used to model methods, properties, inheritance, visibility, relationships, and other aspects of the logical structure of a system.

XIII. State Diagrams
Some behavior is best described as an orderly flow of a process. Other behavior is better described as a range of responses to various events, and the proper response to a given event may depend upon the state of the system when the event occurs. In this session, we will examine how State Diagrams depict such state-and-event behavior within the system.

XIV. Deployment Diagrams
The components of a system must reside and execute on physical hardware, and may communicate via physical connections. In this session, we will explore how Deployment Diagrams allow us to design the exact locations and connections between components. We will also discuss techniques by which Deployment Diagrams allow you to balance the load on processors and the bandwidth on connections between processors.

XV. The Construction Planning Stage
Each Construction Stage is made up of five core activities: construction; testing; documentation; and the planning and tracking of these activities. In this session, we will discuss ways to plan and coordinate the activities for smooth, manageable results. Then we shall review the model of our sample project and devise plans, estimates, and schedules based on it.

XVII. The Implementation Stage (Part 1)
Within each Construction Stage, detailed design models and code are produced. The complete range of UML diagrams comes into play in this workflow, as the developers express the complete understanding of the system in the code. This session describes the process by which these artifacts are produced, reviewed, and refined. Then we shall begin the detailed design model of our sample project.

XVIII. Code Generation, Reverse Engineering, and Maintenance with XDE (or Visio, or ROSE)
In this session, we will explore the details of code maintenance with XDE (or Visio, or ROSE). We will see how models can lead to code and how code can lead to models. We will also look at models of common .NET idioms.

XIX. Patterns: Theory and Application
In this session, we shall examine the role of Patterns in software development. Patterns are software best practices formally described as an aid to study and application. We shall examine how patterns can apply across the entire development process, and we shall study some classic design patterns as expressed in UML.

XX. Pattern Development with XDE (XDE classes only)
In this session, we will how XDE supports patterns: how to apply patterns to your designs, and how to create and apply your own patterns.

XXI. The Implementation Stage (Part 2)
In this session, we shall convert the designs for our sample project into C# code; and as the C# code evolves, we shall revise our design model to reflect the code changes. We shall look for patterns that may help in our design, then create and apply them through XDE (XDE classes only).

XXII. Conclusion
As time permits, we will address any remaining questions you may have about tools, UML, and MDD. Note the emphasis on remaining questions. Please never hesitate to bring up questions as they arise in the class!

Back to top