Designer não é Piloto de UML
Mais uma das "inovações" que vieram com o Java, o Designer é mais um dos camaradas incompreendidos no processo de software convencional. Este é mais um dos cacoetes da Análise Estruturada Moderna mal aplicada (pior, antes fosse só isso) que ainda vicejam no mercado.
Nós, profissionais de TI, desenvolvemos sistemas para resolver problemas com o emprego de TI. No entanto a resolução de problemas é um ramo muito maior que o imaginado por nós. Para resolver um problema temos um algoritmo básico composto das atividades:
Fazendo um breve exercício mental agora... A grosso modo, a tarefa do enunciado do problema é delegada à Engenharia de Requisitos. A implementação do modelo de análise e a análise podem ser executadas por um analista de sistemas / OO. Daí podemos partir para a implementação da solução. Até aí nenhuma novidade.
E a implementação fica a cargo de quem? Ora, do desenvolvedor. Quem é o desenvolvedor? Ora, é um programador sênior. O que um programador sênior faz? O mesmo serviço do júnior, só que mais rápido com maior qualidade, afinal ele tem anos de experiência E CONHECE UML o suficiente para especificar um software e delegar a implementação para o desenvolvedor júnior. Certo...
Volto a seguir a este assunto...
No desenvolvimento de software temos dois grandes domínios: o espaço do problema, isto é, o mundo "real", e o espaço da solução, o mundo do computador.
Na OOAD (Object Oriented Analysis & Design) o analista é encarregado de modelar o problema independentemente de tecnologia de modo a descobrir insights sobre o sistema em desenvolvimento. É vantajoso trabalhar de uma forma mais conceitual simplesmente para "evitar as tentações" do detalhamento inerente à tecnologia usada na implementação do sistema.
Em UML o analista utiliza os estereótipos Entity, Workflow e Boundary (não sei se o método é do Booch ou do Jacobson) para identificar objetos e representar respectivamente entidades, lógica de controle e interface externa (gráfica ou de serviços). Para concluir seu trabalho o analista pode criar um diagrama de robustês para verificação de consistência entre casos de uso e elementos do modelo de análise. Antes que vestais agilistas e desenvolvedores molestados por consultores CMMI gritem "CASCATA", Bittner, um engenheiro do processo unificado resume elegantemente esta questão em uma pergunta : "Artifact or not artifact?".
Qual o trabalho do Designer? O trabalho do designer é transpor as definições do espaço do problema para o espaço da solução, isto é definir as linhas gerais da solução para o problema levantado durante as atividades de requisitos e análise restrita pelas estruturas arquiteturais pré-definidas ou construídas concomitantemente.
Isto quer dizer uso UML? Uso de UML é uma prerrogativa que a equipe do projeto deve decidir, portanto a resposta pode ser talvez. Não vou falar do "bom-senso", se tudo se resumisse a bom-senso certamente não teríamos a menos expectativa de melhora. Acho este termo tão overused quanto "agile" ou "web 2.0". Alguns critérios podem ser utilizados para definir quando e como usá-la.
Larman no livro do "barquinho" propôs 3 usos para a UML: elucidação do problema, documentação e UML executável. UML não é linguagem de programação, contém estruturas insuficientes para sua transformação em uma linguagem compilável, portanto já descarto de cara a última alternativa (sorry, MDA).
Em relação a documentação o uso da UML já começa a ficar interessante. Neste sentido o balanço adequado entre texto e diagramas pode prover documentos ricos e de grande valor principalmente para a manutenção de um sistema.
A UML conduzida pela Modelagem Ágil pode servir como veículo para a elucidação de um problema E da solução. Solução? Este é o interesse do designer.
Voltando às atividades do designer na OOAD... O nosso "programador sênior que conhece UML" constrói a solução a partir do modelo de análise. Na forma mais simples ele faz a "tradução" dos modelos de análise para o modelo de solução. Neste sentido ele criaria uma classe de entidade decorada com atributos JPA (ou Entity Beans 2.x), uma classe service decorada com atributos de transação do Spring (ou Session Beans 2.x) e alguns controllers (Struts 1.1, alguém??) em conjunto com alguma view JSP, JSF, ou Freemarker.
Mas o que não está nos livros? Melhor, o que está apenas subentendido nos livros?
Há todo um trabalho de coaching conduzido pelo designer, agora chamado de líder técnico. O designer conversa com o arquiteto e elabora a estrutura de um módulo. Pode fazer uma especificação temporária no quadro branco usando, quem sabe?, UML.
Depois conversa com o desenvolvedor e o ajuda a implementar a infra-estrutura do módulo: teremos um façade, um mediator, as responsabilidades destas estruturas são proteger o negócio e coordenar o workflow de diversos objetos da interface. De olho na arquitetura o designer prepara a infra-estrutura de artefatos seguindo as especificações do arquiteto e do gerente de configuração.
Durante a implementação do módulo, o Designer será solicitado pelo desenvolvedor para resolver problemas de queries, problemas de APIs de terceiros e quem sabe elucidar requisitos com os analistas frente a problemas que só podem ser encontrados durante o desenvolvimento.
Concomitantemente o Designer pode fazer a documentação de um módulo, especificando as responsabilidades de cada componente e, quem sabe?, usando UML.
Concluindo
O meu ponto foi: o Designer tem um papel importantíssimo na condução de um projeto, é a pessoa responsável por elaborar solução e viabilizar a implementação. Uma das falhas do pessoal de processos é ignorar a interação humana necessária para a resolução do problema. Uma das falhas dos agilistas é negar a priori todo um apanhado de técnicas OOAD que podem servir para a resolução de um problema. Onde falo OOAD não excluo abordagens para enriquecer o design como DDD ou ficando no básico dos Design Patterns ou GRASP Patterns.
Outro termo overused como "agile" e "bom-senso" é "a virtude está no meio". Este é mais um paliativo que solapa a execução de uma reflexão honesta sobre nossas atividades de TI. Cada tópico de um processo de software deve ser bem pensado e experimentado. E isso só se dá com estudo, aplicação e reflexão constantes.
