Uml And Big Design

It has long been said that the UML is not equivalent to BigDesign. Surely this is formally true, as the UML is just a graphical notation. The recent(?) release of RationalUnifiedProcess suggests Rational's view of process isn't as small as it might be.

Often on these pages, people have talked about drawing a couple of rectangles (I liked the clouds, actually) and a couple of lines between them. I've stooped to that, and even some of those open and filled dots that show cardinality. Oh yes, and the triangles that mean inheritance.

Other than specialized pictures such as the OakTreeDiagram, I've never needed any more frills than that on my diagrams. This may be due to the fact that I've never implemented anything more complicated than compilers, operating systems, relational database systems, small things like that.

It's hard to imagine that a notation as, um, refined as the UML is intended to support bar napkin design. The software vision of Rose, no matter how completely implemented it may be, has always been to support a full end-to-end diagrammatic creation of software.

Surely the UML is the graphical notation most suited to BigDesign. But UML doesn't do BigDesign, people do BigDesign.

It's OK to draw little lines and rectangles on your CRC cards if you want to.

--RonJeffries

I've never seen Ron do an OakTreeDiagram, but when he described C3 to me using blank cards I noticed something wonderful. He was essentially sketching out the instance structure of the software. The one thing that I don't care for with UML and other ER style static notations is that they deal with type (or class) structures predominantly.

As an example, when Ron explained LinesStationsBinsParts he laid down about four or five cards in a row and said "each of these is a station, the whole thing together is a line." In UML, you'd have two boxes: one for line and one for station, and an aggregation relationship among them.

To me, this is a fatal drawback of many BigDesign notations. They show the type structure when it is the instance structure that is often vital to understanding. When I think about how my program is structured, I have an instance picture in my head. When I look at sequences and static class diagrams, I extrapolate the instance picture.

The data is the message -- in my ideal world, a complete understanding of the data is all that's needed to understand the system. The code should be obvious (or, at least no more than half the work) once you understand the data.

Sometimes I get concerned that the emphasis on type structure in the industry will bury RoleModeling even longer than it has been already. When you are only looking at types, it is hard to see the Roles.

-- MichaelFeathers

Check out the Collaboration and Sequence diagrams in UML. If those don't do it, try the State and Deployment diagrams. I think you'll find that UML caters to this sort of thing pretty well. Not that I recommend these as opposed to CrcCards, but they do exist and can work. --PeterMerel

Yes, but they are still dynamic rather than static views. At times, I've drawn static models (free hand on paper) where each box is an object and the lines are links. I can't say that they are more useful in any way other than the fact that that is the way that my intuition paints them in my mind. -- MichaelFeathers (should have learned Self)

If you ever find yourself saying "for instance ..." in your technical discussion then you will like CrcCards. The human mind is quite agile moving between class and instance. So are the cards. -- WardCunningham

Yes I like it. I've been doing some CRC, I need to try the blank card manipulation style as well. - MichaelFeathers

For me, the Sequence diagrams are the most useful diagrams, giving me the feeling that the objects really work together to achieve some functionality (some Use case).

It has long been said that the UML is not equivalent to BigDesign.

Then what is the purpose of UML, if not big design? If we do informal design, any notation will do. Formal notation only comes into play when we want to preserve the design and present it to a wide audience.

Well, "any notation will do" supposes that people agree both today and tomorrow on what your arrows and squiggles mean. The advantage of a notation like UML is that the meaning of the bubbles and arcs is fixed. You still want to be able to read the back of your CRC card in six months :)

Personally, though, I've never *ever* needed more UML than I find on the inside front and back cover of Martin Fowler's "UML Distilled". In fact, I think you could probably cut that down by half and still have enough...

KyleBrown

The whole world maps to circles, squares, and arcs. When someone goes to the board that's what they draw. Even people who know UML don't naturally fall into using it.

There are three reasons for using diagrams. One, to explain a concept to another person right now; two, to understand something that exists now; and three, to preserve a concept for the future. For the first and second reasons, there is no need to preserve the idea for the future, any notation will do. The third reason is only valid if you are doing design up front. If you do design as needed, there is no need to time-shift knowledge. If you are not doing design up front, there is really no need for a formalized notation and fancy drawing packages.