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 v | [FAQ List] -| | | | edit | v |cancel [edit faq] -| | | |verify| [verify faq]| | | |------|submit
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 |3| |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...
Diagrams are a good thing, but I feel that UML is too low-level; my "boxes" tend to be entire modules like UserManager. Until you code, you don't really know what is going to make sense.
With too much detail, once you start to code, you have to go back to your UML diagrams to keep them up to date. But, you won't so they are different. One person told me that they had walls covered with UML diagrams; they have to physically walk around and trace lines. Sounds crazy to me. A tool can easily help you navigate code, which is the truth not what you hope is the truth. The code should be the ultimate documentation.
Many formal methods for software development are desperate attempts to control the chaotic development process, but they are usually an illusion of control.
The key thing to remember is: precision does not equal accuracy!
The running joke among "business analysts" is that they are often stuck in analysis paralysis.
In my opinion, it would be a very unsatisfying job to get a huge UML diagram and be told to implement it. The best programmers would probably not put up with such little control over their design. As you will see in a later lecture, the coders and results of coding must alter the design.
UML has notation for
Simple description of class diagram components: http://www.dotnetcoders.com/web/learning/uml/diagrams/classdiagram.aspx; here is an example from that page:
Here, Animal has two subclasses Dog, Bird. Each box is a class def that have various properties. The "owned by" link shows a relationship between a Person and an Animal. Each Person may have many pets.
You might find these definitions useful: "M$ UML Diagrams"
programming language element class diagram
UML model of a university
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.