A visão de que a melhor forma de se desenvolver software orientado a objetos é através da criação e do refinamento de modelos UML perdeu sua força depois da aceitação e disseminação dos métodos ágeis em meados da década de 2000 – especialmente por causa do Extreme Programming (XP). Com isso, a UML perdeu bastante da sua importância, sendo vista por alguns mais radicais apenas como uma notação para permitir a discussão (lembrando da “UML como rascunho”, apresentado por Fowler no seu livro UML Distilled).
Mas, claro, a UML e processos similares ao Processo Unificado (UP) ainda são aplicados em diversos contextos – métodos ágeis não são para todos os projetos. Pensando nesses contextos, o livro Princípio de Análise e Projeto de Sistemas com UML, do Eduardo Bezerra, apresenta a UML sugerindo o seu uso ao seguir um processo similar ao UP. O livro parece ser baseado no processo descrito no livro do Larman (Applying UML and Patterns), mas acrescenta algumas técnicas e heurísticas bem interessantes (questões de coesão e acoplamento, técnicas de análise OO, persistência, etc.).
Porém, apesar do livro ser de 2015, ele dá a impressão de ser antigo – e não é só porque há um exemplo citando um videocassete (na página 11). O livro quase não fala sobre abordagens ágeis (Domain-Driven Design é falado com um pouco mais de detalhe, mas ainda assim é superficial). Concordo que discutir a relação entre o processo descrito no livro e as abordagens ágeis é algo delicado, mas isso precisa ser feito: a questão já está na cabeça da maioria dos leitores. Mais que isso, o livro perdeu uma ótima oportunidade de revitalizar a literatura de análise e projeto OO ao assimilar técnicas ágeis ao processo baseado em modelos UML. Ao invés de revitalizar, o resultado parece ignorar a realidade de mercado e o estado da arte.
Um outro motivo para o livro parecer antigo é por ele usar definições e visões da UML 1 (!!!). Confesso que me incomodou ver a explicação de laços e condições em um diagrama de sequência enfatizar a escrita de cláusulas na mensagem ao invés de usar fragmentos. Também achei estranho ver coleções de objetos (os multiobjetos) – acho que isso desapareceu na UML 2 (não encontrei referências disso na UML 2.4.1 e tampouco na 2.5). Mas o que mais me incomodou foi ler que o diagrama de atividades é um tipo especial de diagrama de estados (página 331) e que uma atividade é um “estado ação” – isso foi uma das principais mudanças da UML 2, de 2005…
Estranhamente, o livro possui vários pequenos erros de português e de formatação. Algo que também atrapalha a leitura é o excesso de referências a capítulos posteriores, especialmente no começo do livro.
Apesar desses problemas, confesso que o livro me surpreendeu positivamente: ele apresenta algumas questões interessantes para quem quer fazer projetos à la UP. É uma boa referência em português, mas eu ainda ficaria com o livro do Larman para ensinar UP.
(Alterado em 27/08/2016)