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.
3 comentários :
"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."
Muito bom!
Já ouviu falar em Feature Driven Development (deveria pois está falando de OOAD) e Agile Modeling?
Onde está escrito que quem trabalha com Metodologias Ágeis não olha para todas outras técnicas que existem na engenharia?
Por isto que eu falo cara, praticar não é ruim não, vale a pena!
A propósito, anotei este teu post para uma palestra que vou fazer em breve chamada "Eu Odeio Métodos Ágeis". Muito boa tua visão sobre os agilistas.
Se eu fosse um cara focado em ISO e seguisse os princípios de qualidade da ISO (http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000/qmp.htm) para desenvolver software, qual seria a referência negativa a fazer?
Daniel,
Repare que o Nilseu disse "Agilistas", ele estava se referindo aos usuários não aos métodos.
Sinceramente isso que ele disse não tem nada a ver com odiar os métodos ágeis ou não.
Abraços.
Daniel,
ao contrário que tu pensas, "Eu não odeio métodos ágeis".
Até acho estranho a tua réplica ao meu post justamente por eu não estar focando na crítica aos métodos ágeis. Na verdade fiz apenas um cruzamento entre meus conhecimentos técnicos e minhas experiências de mercado, tentando achar um ponto de equalização entre o que está nos livros, os pressupostos dos envolvidos no processo de TI e o praticante de design.
Só acredito que vivemos numa época de sobrecarga de informação e temos uma contextualização histórica ridiculamente curta.
Atualmente acredita-se que a mídia (impressa ou eletrônica) é uma representação fidedigna da realidade. Afinal, se não sai na mídia não deve existir. No entanto o que noto é uma discrepância abissal sobre o que está na mídia, o que está em voga nas universidades e o que está em voga na indústria. Não estou condenando nenhuma destas esferas, só estou dizendo que temos que ser mais criteriosos se quisermos sobreviver à avalanche de informações que somos submetidos hoje.
Aceito de bom grado a crítica a respeito da minha generalização sobre os agilistas. Com certeza foi um recurso retórico usado indevidamente. No entanto, voltando à questão da mídia, isto é o que se verifica como praxe não apenas na comunidade ágil, mas em vários fóruns midiáticos.
Como dividi as esferas mídia, universidade e indústria, cabe aqui também dividir as esferas da TI entre líderes da prática, praticantes medianos e praticantes júniores.
O principal problema são as palavras dos líderes de práticas que ou por serem mau escritas ou por sofrerem de um viés (não intencional, neste aspecto não critico a idoneidade das pessoas) são interpretadas pobremente e propagadas ad nauseum na comunidade através dos grupos mais amplos da TI.
Sobre o que "já ouvi falar", vejo que devo deixar mais claros meus links no texto. Referenciei livros do Ambler sobre Modelagem Ágil diretamente no texto apesar de não fazer a citação explícita da fonte no texto (siga os links e descubra minhas fontes). Emprego diuturnicamente suas práticas.
Sobre FDD, não é um privilégio do movimento ágil. Estou estudando há algum tempo e está na minha lista de "práticas ágeis" a serem implementadas nos próximos meses no contexto de um processo de software integrado com um sistema de controle de demandas. Em hipótese alguma eu prego a caça às bruxas. O meu ponto resume-se a "Todo mundo (a mídia) está falando (bem ou mal)? Ótimo, mais um tema para eu estudar.", só que que no decorrer dos anos me esforcei para desenvolver uma abordagem desapegada do tema de estudo, ou seja tento deixar minhas paixões de lado e dou aos proponentes o benefício da dúvida até eu me aprofundar mais sobre o tema.
Sobre ISO (http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000/qmp.htm), sinto muito, nunca estudei, portanto não vou fazer as pessoas perderem seu tempo com a minha opinião, que com certeza neste caso, não seria nem um pouco embasada, portanto nem um pouco honesta.
Nilseu Padilha
Postar um comentário