Before getting into the task of writing code, a team must create an initial design using broad strokes rather than the painful details of explaining things to a computer. It seems to me that there are two possible paths:
Because we are not ready to discuss overall design yet, I will leave my thoughts on this matter til a future lecture. This lecture describes how, if you want detailed diagrams, to create them and describes what kinds of diagrams there are. These diagrams can all important for high level design, but individually many of these diagrams illustrate tactical rather than strategic processes.
Draw Employee, Coder, Manager, CEO
StoreItems: Book, Map, Paper, Pen, Stapler
Car:Honda or Professor:Terence
Book->*Chapter or Person->+address or Person->Employer
DBManager -Books,Pens,...-> Store --> WebServer -| |->clientbrowser
Really great example is a state diagram for HTML web pages:
|------| next page
[FAQ List] -|
| edit |
[edit faq] -|
Similar to assocation diagrams, but specifically designed to show a
formal data structure like List of List or Hashtable of Hashtable
(useful for example, to do insertion sort; can alter a value and place
in new location in constant time; kinda like radix sort).
a=2, b=0, c=1, d=1
|2| -> [a]
|1| -> [c,d]
|0| -> [b]
It helps to design algorithms if you can see the structure; you can say "ok, I'm here and I decide to walk here based on this" etc...
People doing research on software engineering seem to ignore the importance of specific algorithm design. jGuru has some fairly hairy algorithms for doing document analysis etc... that had to be designed with data structure diagrams. Tied into overall diagram then with words like "compute histogram", "Lexicon", etc...
UML is simply a formalization of these diagrams (i.e., specific rules for building the diagrams). It is used to describe object-oriented models of real world problems.
Many view UML as a substitute for initial coding. One can go from UML to code (usually language independent) and from code to UML; except probably state machines, data flow, and the ilk.
Has notation for
"VisualUML.com sample diagrams"
I certainly create lots of diagrams and write copious notes when designing software, but they are super informal. Why? Well, what is the difference between writing something out by hand and using a word processor? Speed vs precision. Precision at the UML diagram level provides a false sense of control over reality. Precision does not imply accuracy. It usually just means you are more precisely wrong. <wink> Besides we already have precision: it's called code.
Why formalize? I often use a graphics tool. But, can use UML tools to that know how to draw these diagrams efficiently. UML tools also have analysis capabilities (of dubious usefulness?)
Large programming/IT shops for low-tech companies like phone companies and accounting firms often try to manage large software development by having so-called analysts design an application with UML down the object level and then have programmers simply translate the design to code and implement it like machines. This doesn't work for two reasons:
UML can create some pretty pictures and humans like to make these diagrams, but they are super fragile. Changes at the method and field variable name occur constantly forcing constant changes in the UML diagram. You've just created another full time job; that costs money and adds a serious parallel-update dependency.
When you have a huge UML diagram, people will often post this on a large wall so you can see how everything fits together and so on. Turns out that finding your classes and their relationships without a computer is pretty tough as you need to put fingers down at lots of different locations to "hold your place" kind of like a twister game.
One of the reasons I get away with not using lots of formal diagrams is that I go to great lengths to write code that is very easy to understand from the overall level and the very specific.
In summary, diagrams should be as high level as possible given their intended use. Precision should be relegated to the code level. This isolates the design more from implementation detail changes. A semi-formal diagram is often useful, however, for communication with fellow programmers or dumbing things down for management. You can get totally caught up building pretty pictures rather than actually building something.
Oh, one final thought. I think these opinions are the in the super small minority. Then again, there is a strongly negative correlation between my opinion of a programmer's ability and their use of formal diagrams and diagramming tools.