Unified Modeling Language (UML)

#### Introduction

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:

1 Layout a design and the actors/relationships in as much detail as
you can before touching a code editor

1 Get the general idea of relationships and actors, leaving details to
when you are actually coding

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.

### Class Hierarchy

Draw Employee, Coder, Manager, CEO

### Package Grouping

StoreItems: {Book, Map, Paper, Pen, Stapler}

### Object Diagram

Car:Honda or Professor:Terence

### Association

Book->\*Chapter or Person->+address or Person->Employer

### Data flow (use case?)

DBManager -Books,Pens,...-> Store --> WebServer -| |->clientbrowser

### State diagrams

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
>>

### Data structure diagrams

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...

#### UML

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.

### Definitions

UML has notation for

1 *Entities*
  1 classes including their members
  1 objects
  1 packages
1 *Relationships*
  1 inheritance
  1 association
  1 composition
  1 dependency
1 *Behavior*
  1 sequences
  1 state diagrams
1 *Use-case* (_what_, not _how_; externally visible stuff)

Simple description of class diagram components: http://www.dotnetcoders.com/web/learning/uml/diagrams/classdiagram.aspx; here is an example from that page:

%image(http://www.dotnetcoders.com/web/learning/uml/images/classdiagram-example.png)

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: @(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dniuml/html/umldiagrams.asp, "M$ UML Diagrams")

### Examples

@(http://www.imagix.com/products/s_uml_c.html,programming language
element class diagram)

@(http://www.agilemodeling.com/artifacts/classDiagram.htm,UML model of a university)

#### My thoughts on UML

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:

1 there is no job satisfaction being the programmer, hence, you will
not be able to hire good programmers

1 when you actually try to code something, you often have to make
radical changes in the design.  Usually these programmers are largely
ignored by the upper echelon of the hiearchy.

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.