É fato que modelagem é essencial para desenvolvermos sistemas de fácil manutenção e de boa qualidade. Porém, vez ou outra escuto alguém com a ideia de que para modelar devemos representar em UML todos os aspectos do sistema antes de iniciar a implementação, chamando isso de etapa de análise e projeto.
Não é novidade que isso não é nada produtivo e totalmente desnecessário. No livro UML Destilled do Martin Fowler, é proposta a abordagem de uso dos diagramas UML como rascunhos, com o objetivo de facilitar a comunicação na modelagem do sistema. Outros profissionais e autores respeitáveis também compartilham desta opinião. Por exemplo, o Ron Jeffries disse recentemente numa lista de discussão:
If you mean by UML occasionally drawing a picture on a bar napkin, I’m all for it. If you mean something more like using full-on UML to draw a comprehensive diagram of the entire object graph, it is a waste of time.
Designing in code works much better than UML for many people, mostly because when you design in UML you get UML and when you design in code you get the program.
Outro que também tem uma opinião parecida é o Robert Martin:
Look, modeling is an abstraction. We purposely suppress details to see the big picture. In order for these ‘modeling’ tools to generate executable code, they need all the details. Well, I have news for you. If you include all the detail, then you’re not modeling! You’re programming, albeit with a different language!
Concordo com eles, a UML é uma excelente ferramenta de modelagem e não uma linguagem de programação. Papel e caneta, ou quadro e pincel são ferramentas UML tão boas quanto o JBuilder ou o StarUML e demais ferramentas CASE.
