UML is a very strong option for representing programs graphically. Grady Booch and a team of others wrote a great book called Object-Oriented Analysis and Design with Applications that introduces OOAD pretty rigorously by spending around 150 pages discussing concepts before diving into notation. While in someways the diagrams are easy to comprehend without much training, Booch is a master at defining ideas like complexity, distinguishing between object model and class model, and classification. The advice about complexity includes discussion of several tools like algorithmic decomposition, object-oriented decomposition, abstraction, hierarchy, and encapsulation.
It is important to remember that you may need to look at your software from several perspectives so that you can capture the static structure and dynamic behavior of both objects and classes. A class diagram would capture the static structure of one or more classes while a sequence diagram would capture the dynamic behavior of two or more objects as they interact. Booch also breaks things down into categories structural, behavioral, and interaction diagrams.
- Composite Structure
- Use Case
- State Machine
- Interaction Overview
For anyone who can name only three or four UML diagrams this should be a wake up call. If you spent a day or a few hours a day for a week, you might not know UML very deeply. Often, UML is taught as a four day course, and sometimes as three or four days for object oriented analysis followed by three or four days of object oriented design. University courses may teach it as a one or more semester courses, or fold it into a sequence that used to follow the waterfall software life cycle (requirements and analysis (with use cases), software architecture and/or design (with the remaining diagrams), object oriented programming (with Java, C++, etc), and testing (that revisits use cases or state diagrams)).
Martin Fowler has a book that I like called UML Distilled where he essentially lays out a pattern for each diagram type, listing it name, a brief description, samples of the diagram and what the arcs, nodes and decorators mean, and most importantly, when to use them. In his introductory material he describes UML as having three applications: to make a software blueprint, as a higher level programming language that generates code (or sometimes reverse engineers from code, or transmutes forward and backward in round-trip software engineering), or my favorite, as a sketch that helps communicate between developers some localized and specific aspects of the design.
UML haters are right about a lot of things. For example, about how much overhead can be involved in using UML to document a design (in blueprint or programming language mode). They sometimes say, a fool with a tool is still a fool. It is a bad idea for an under-trained developer to jump in a make diagrams just as it is for a FORTRAN programmer to start writing in C++ or Java from a table that shows which statements are equivalent. With a UML diagram editor of Computer Aided Software Engineering (CASE) tool (CASE has endured a lot of criticism) it became possible for bad designers to make big bad designs much faster.
UML lovers will point out that it allows us a common language to communicate our design in a visual and expressive way. As we represent the same design in multiple ways, it gives us a great rehearsal for the code we will write. Because it is visible it facilitates a form of communications with others that is faster (we process visual information much faster than verbal, and by indirection, than text), and gives us many opportunities for peer review. Because we use more than one view, it permits us to move between hierarchical views like deployment diagrams, package diagrams, and class diagrams. We can see the same information at rest in the object diagram, and in motion in the activity diagram and sequence diagram. By using related diagrams, we can reveal problems with completeness and consistency early, and sometimes use a representation that is easily generated like a state diagram to discover needed content in another diagram like a sequence diagram.