Three modes in which people use the UML: sketch, blueprint, and programming language.
The essence of sketching is selectivity.
UML as blueprint is about completeness.
UML as programming language. In this environment, developers draw UML diagrams that are compiled directly to executable code, and the UML becomes the source code.
Model Driven Architecture and Executable UML
Essentially, MDA is a standard approach to using the UML as a programming language
Almost all the time, my use of the UML is as sketches. I find the UML sketches useful with forward and reverse engineering and in both conceptual and software perspectives.
The waterfall style breaks down a project based on activity. To build software, you have to do certain activities: requirements analysis, design, coding, and testing.
The iterative style breaks down a project by subsets of functionality.
The difference between a predictive project and an adaptive project surfaces in many ways that people talk about how the project goes. When people talk about a project that’s doing well because it’s going according to plan, that’s a predictive form of thinking. You can’t say "according to plan" in an adaptive environment, because the plan is always changing. This doesn’t mean that adaptive projects don’t plan; they usually plan a lot, but the plan is treated as a baseline to assess the consequences of change rather than as a prediction of the future.
The trouble with class diagrams is that they are so rich, they can be overwhelming to use. Here are a few tips.
Don’t try to use all the notations available to you. Start with the simple stuff in this chapter: classes, associations, attributes, generalization, and constraints. Introduce other notations from Chapter 5 only when you need them.
I’ve found conceptual class diagrams very useful in exploring the language of a business. For this to work, you have to work hard on keeping software out of the discussion and keeping the notation very simple.
Don’t draw models for everything; instead, concentrate on the key areas. It is better to have a few diagrams that you use and keep up to date than to have many forgotten, obsolete models.
The biggest danger with class diagrams is that you can focus exclusively on structure and ignore behavior. Therefore, when drawing class diagrams to understand software, always do them in conjunction with some form of behavioral technique. If you’re going well, you’ll find yourself swapping between the techniques frequently.
One of the main goals of good design is to localize the effects of change. Data and behavior that accesses that data often change together. So putting the data and the behavior that uses it together in one place is the first rule of object-oriented design.
You should use sequence diagrams when you want to look at the behavior of several objects within a single use case. Sequence diagrams are good at showing collaborations among the objects; they are not so good at precise definition of the behavior.
One of the most valuable techniques in coming up with a good OO design is to explore object interactions, because it focuses on behavior rather than data. CRC (Class-Responsibility-Collaboration) diagrams have stood the test of time as a highly effective way to do this.
A sample CRC card
Composite structures are new to UML 2, although some older methods had some similar ideas. A good way of thinking about the difference between packages and composite structures is that packages are a compile-time grouping, while composite structures show runtime groupings. As such, they are a natural fit for showing components and how they are broken into parts; hence, much of this notation is used in component diagrams.
Components are not a technology. Technology people seem to find this hard to understand. Components are about how customers want to relate to software. They want to be able to buy their software a piece at a time, and to be able to upgrade it just like they can upgrade their stereo. They want new pieces to work seamlessly with their old pieces, and to be able to upgrade on their own schedule, not the manufacturer’s schedule. They want to be able to mix and match pieces from various manufacturers. This is a very reasonable requirement. It is just hard to satisfy.
Use component diagrams when you are dividing your system into components and want to show their interrelationships through interfaces or the breakdown of components into a lower-level structure.
Interaction overview diagrams are a grafting together of activity diagrams and sequence diagrams.