Fabio Fernandes
Introdução
Com o aumento da competitividade nas empresas fornecedoras de serviços de desenvolvimento de software, observamos cada vez mais técnicas em adaptações em processos para que estes fornecedores se tornem competitivos, focando principalmente em aumento da competitividade pela diminuição de custo.
Estamos em um mundo globalizado e capitalista, aonde espera-se ser comum em sub-contratação de projetos de software, que o cliente avalie os diversos aspectos relacionados ao produto que irá adquirir, considerando custo-benefício, a garantia de entrega e a confiança na relação com aquele fornecedor.
Neste cenário geralmente agressivo e competitivo, é comum que nós como desenvolvedores de software e fornecedores, tomemos ações internas para melhorar a performance da nossa equipe, tentando entregar mais por menos esforço.
Atualmente no mercado existem ferramentas, processos e pessoas que podem auxiliar as empresas na busca da solução do paradigma da produtividade e do risco, que leva o fornecedor especializado em lidar com aquele tipo de situação com mais naturalidade por estar constantemente exposto à este ambiente.
Este artigo trata do aspecto risco e produtividade em fases subsequentes às da contratação e definição da solução de alto nível, transportando o leitor ao momento em que desenvolvemos o conteúdo necessário para que o desenvolvedor possa iniciar suas atividades – a fase de desenho técnico detalhado da solução.
A importância da modelagem
Hoje no mercado, temos cada vez mais profissionais especializados nas ferramentas de construção de aplicações e soluções como um todo. Estes especialistas estão inseridos geralmente na fase de construção e conhecem os principais pontos técnicos que envolvem a produção de produtos de software usando determinada tecnologia. Isto nos remete à pergunta: Porque desenhar software, se o desenvolvedor tende a ser cada vez mais especialista?
A resposta que proponho à esta pergunta é simples: É necessário desenhar para mostrar o caminho. Sabe aquele jargão, que soa como uma frase irônica “entendeu ou quer que eu desenhe?”, pois bem, a proposta talvez seja entendida por alguns, como tão irônica quanto a pergunta: Desenhe!! Não porque os desenvolvedores na próxima fase não terão a capacidade de entender o que é para ser feito, mas sim porque deve haver um processo de brainstorming que corresponde ao descobrimento das oportunidades dentro de uma solução antes da construção, entre estes: Oportunidades de reuso, oportunidades de teste e o mais importante: oportunidade de diminuir o risco de que o desenvolvedor tenha dificuldades em encontrar qual a melhor solução para o problema proposto. Um erro na produção do desenho, corrige-se alterando o desenho, mas um erro na busca pela solução ideal para determinado problema na construção de software, pode significar desde prejuízo financeiro até rompimento de contrato e insatisfação do cliente.
Como evitar que os desenvolvedores entrem naquele ciclo perigoso de “teste-e-veja-se-funciona”? Como evitar que os desenvolvedores errem na definição de uma solução técnica? Como apoiá-los, passando para eles todas as informações que temos sobre a solução, antes mesmo que ele comece a desenvolver? As respostas envolvem desde a definição de arquitetura, passando pela definição de padrões de desenvolvimento (Coding Conventions) , e chegando até a modelagem da solução, enriquecida de representações e comentários, efetivando a comunicação entre as diferentes equipes de diferentes fases do projeto.
Por outro lado, o desenhista técnico deve entender os cuidados que envolvem a produção do desenho técnico. Este não é apenas um documento do que deve ser feito para se entregar para o cliente, ou simplesmente para o gerente ver. Ele é tão importante como qualquer outro documento de definição de um projeto de software, e sua entrega deve conter exatamente o que se propõe: Agregar valor para a próxima fase do ALM, com nível de riqueza que agregue para o desenvolvedor, não como um documento burocrático em alto nível, mas algo que o desenvolvedor leia e tenha a sensação “haham, eu entendi o que é pra fazer!!”.
A atividade de construção do desenho técnico pode seguir um processo específico da empresa, como sequência de atividades, diagramas específicos e ferramentas., mas quando falamos de entregáveis, os documentos de desenho técnico precisam ter uma linguagem compreensível para o desenvolvedor. Uma linguagem padrão para modelagem de Software no mundo Orientado a Objetos é a UML (Unified Modeling Language).
A UML (Unified Modeling Language)
O padrão UML apresenta um conjunto de regras, notações e diagramas para a definição dos modelos, que servem como meio de comunicação entre o gerente, analista de negócios, arquiteto, desenhista e programador. Através da UML é possível manter uma documentação evolutiva, que faz com que as atividades relacionadas ao desenvolvimento daquele produto façam sentido para a equipe. Além disto há no mercado diversas ferramentas que centralizam e integram a modelagem com as atividades de desenvolvimento de tal maneira que o próprio modelo é reaproveitado, facilitando a evolução daquele produto, integradas ainda ao ambiente de desenvolvimento, gerando código-fonte com comentários e instruções para o desenvolvedor.
Alguns dos diagramas previstos pelo padrão UML, para modelagem da solução:
Diagrama de caso-de-uso
No diagrama de casos de uso descrevemos de maneira visual, quais requisitos funcionais de software relacionam-se, e qual a relação destes itens com entidades externas (ex.: usuários, outros sistemas).
Figura 1: Exemplo de diagrama de caso-de-uso
Diagrama de pacotes
O Diagrama de pacotes ajuda ao desenvolvedor a entender como o que será desenvolvido deverá estar organizado. Por trás do Diagrama de pacotes tem-se a noção do que move a organização e estruturação do sistema.
O processo de nomeação e definição hierárquica dos pacotes permite que se tenha uma noção em profundidade da organização do sistema orientada a um tema. Por exemplo, os pacotes podem ter definição técnica, como “Banco de dados”, “User Interface”, “Logging”, ou ainda definição funcional “Cadastro de clientes”, “Pagamentos”, “Impressao de Boletos”.
Figura 2: Exemplo de diagrama de pacotes
Diagrama de componentes
Este diagrama apresenta ao desenvolvedor que objetos relacionam-se entre os pacotes. Através deste diagrama tem-se a noção mais precisa de que relacionamentos irão ocorrer para se resolver os problemas que a solução sistêmica visa resolver. Esta noção de distribuição ajuda então o desenvolvedor a visualizar como itens de software irão resolver problemas específicos.
Figura 3: Exemplo de diagrama de componentes
Diagrama de classes
Este é um dos mais importantes diagramas, pois identifica qual o tipo de relacionamento e dependência entre as classes. Através deste diagrama pode-se representar por exemplo as noções de reutilização, composição dos objetos, dependências e tipos associados a operações.
Figura 4: Exemplo de diagrama de classes
Diagrama de seqüência
O Diagrama de sequência, fazendo par com o Diagrama de Classes, também é um dos mais importantes para adequada interpretação do relacionamento entre as classes. No caso do diagrama de sequência em especial, há a capacidade de apresentar ao desenvolvedor, qual a sequência de operações entre as instâncias dos objetos no tempo. Esta noção de tempo e chamada oferece uma visão bastante profunda de como se espera que o sistema deva funcionar, a nível de instância de classes e chamadas entre objetos.
Figura 5: Diagrama de sequência
Todos estes diagramas juntos podem compor um ou mais documentos que passam para o desenvolvedor como o sistema deverá ser construído, e qual o comportamento esperado do sistema em diferentes situações. Além de fornecer informações valiosas sobre o produto a ser construído, históricamente estes documentos podem ajudar na resolução de problemas, documentando os processos por trás do funcionamento do produto de software.
Conclusão
Existem ferramentas que podem e devem ser utilizadas para diminuir o risco na entrega de produtos de software. Uma das maneiras de se diminuir os riscos de construção, é aplicar as particas de construção de modelagem da solução,em especial, o desenho técnico. Através dos entregáveis da fase de desenho aumenta-se a qualidade na passagem de informação para a fase de construção, e através da UML, podemos ter uma comunicação única, visual e bastante completa, da visão de como deve ser o produto que pretende-se entregar.
Referências bibliográficas:
Pressman – Engenharia de software – Sexta edição
Martim Fowler - Padrões de arquiteturas corporativas
MSDN – Patterns and Practices – www.msdn.com
Fabio Fernandes é Bacharel em Ciências da Computação, profissional certificado Microsoft, aluno de pós-graduação em Gestão de Projetos de TI na Fundação Vanzolini, atuando como Arquiteto e Coordenador de Projetos em importante consultoria multinacional.
E-mail para contato: fabio_sfernandes@hotmail.com
