Seeking UML tips or alternatives

[James Laver]

On 2008-10-13 08:50, "Andy Wardley" <abw at wardley.org> wrote:
> 
> The purpose of creating an ERM is to identify the entities (nouns) in your
> system and the relationships (verbs or adjectives) between them.  The entities
> will (usually) end up being the tables in your database and/or the object
> classes in the system.  It is a relatively simple process to turn an ERM
> into a data abstraction layer using your ORM of choice (e.g. DBIx::Class).
> 
> An ERM is the most important diagram you need and *possibly* the only one.
> Class diagrams are useful to show the inheritance tree of different classes
> (if you have such a thing), and sequence diagrams can help if you've got some
> complex interaction between different parts of the system that you want to
> model.  Use case diagrams might also be required to convince yourself (and
> others) that you're all in agreement about what the system should do from the
> end-user's perspective.  But apart from that, the rest of UML just isn't worth
> the effort. It's a lot of paperwork designed to increase the billable time of
> highly paid analysts who can't code.  All IMHO, of course.

Ah, the difference between management-suggested and useful-to-programmer
diagrams.

Personally for me I produce 2 diagrams: a class tree and an ER diagram
(though I use UML class blocks to give a field listing -- really useful for
reference if you have it printed big and stuck on your wall).

Then again, there's nothing more enjoyable than drawing overengineered
diagrams when you could be writing perl...

-J