Metodologias de desenvolvimento de software - Parte III por Gustavo Villa Desta vez resolvi falar um pouco sobre o RAD. É uma abordagem muito interessante, principalmente para aqueles que estão habituados a desenvolver sistemas utilizando conceitos de reaproveitamento de código. É uma grande candidata a metodologias para ser implementadas em fábricas de software. Como vimos no modelo que citei anteriormente, o tempo que podemos perder com a prototipagem pode ser um pouco longo para um projeto que exige uma rápida execução - e geralmente os clientes sempre nos pedem para ontem. Para tentar solucionar esse tipo de questão surgiram metodologias que buscam resolver justamente essa questão. O RAD é um exemplo disso. Como seu desenvolvimento é baseado em componentes, seu desenvolvimento torna-se menos sujeito a erros. A idéia é simples, porém muito eficiênte: Primeiro fazemos a modelagem do negócio, onde o fluxo de informações entre as funções do negócio modelado procura responder as seguintes questões: Que informação dirige o processo do negócio? Que informação é gerada? Quem a gera? Para onde vai a informação? Quem a processa? Essa modelagem é feita antes mesmo de se fazer os diagramas de use-case, quando estamos fazendo diagramas UML para desenvolvimento (caso não saiba o que é UML, acesse o link: http://www.eps.ufsc.br/~wolff/oqueuml.htm . Encontrei lá informações interessantes para quem está iniciando nesta área). Em seguida temos a modelagem dos dados. O fluxo de informações definido anteriormente é transformado em um conjunto de objetos que serão necessários para desenvolvermos a aplicação. Os atributos de cada objeto são identificados e as relações entre esses objetos são definidas. (Ainda é anterior ao Use Case... é como se estivessemos definindo os atores e os use cases, sem definir a relação entre eles) A próxima etapa é a modelagem do processo e aqui usaremos os objetos definidos na fase anterior, transformando-os para conseguir o fluxo de informação necessário para implementar uma função do negócio. (Aqui monta-se propriamente o use case view) Depois de modelado o sistema, a geração da aplicação parte para técnicas orientadas a objeto (Para a nossa felicidade, a versão 5 do PHP está bem melhor nesse sentido, oferecendo um suporte muito interessante nesta área). Ao invés de usar linguagens procedimentais, o RAD usa linguagens de 4ª geração. Como seu desenvolvimento é feito para reutilizar o máximo possível de componentes, durante todo o processo de desenvolvimento temos a "quebra" do sistema em partes menores e especializadas. Para não ficar muito abstrato isso, imagine que ao invés de termos um arquivo PHP com toda a codificação, separaremos cada parte do sistema em arquivos que poderão ser reaproveitados em outras aplicações sem que se altere uma linha de código da maioria desses arquivos. A eficiência no desenvolvimento uma garantia de redução de erros se dá pelo fato do processo RAD ter foco nos componentes e por isso muitos dos componentes já terem sido testados. Isso reduz o tempo total gasto com testes (Porém novos componentes devem ser testados e as interfaces exaustivamente exercitadas). Se uma aplicação comercial pode ser modularizada de modo a permitir que cada função principal possa ser completada em menos de 3 meses usando a abordagem de prototipagem por exemplo, ela é candidata ao RAD. Cada função pode ser tratada por uma equipe RAD distinta e depois integrada para formar um todo. DESVANTAGENS: 1) Para projetos grandes (mensuráveis) o RAD exige muitos recursos humanos. 2) Exige desenvolvedores e clientes compromissados com atividades contínuas e rápidas. Se não houver esse comprometimento, os projetos falharão. 3) Nem todos os tipos de aplicações são apropriadas para o RAD. Se o sistema não puder ser adequadamente modularizado, a construção dos componentes será problemática. Se for preciso um desempenho superior e esse desempenho seja conseguido com o ajuste dos componentes, a abordagem RAD pode não funcionar. 4) Quando riscos técnicos forem elevados, o RAD não é adequado (ex.: uso de uma tecnologia nova ou quando exige comunicação com outros programas). Observação De fato, no PHP tínhamos uma certa restrição quanto ao desenvolvimento de objetos (apesar de que, sempre procurei desenvolver classes e há muitos programadores por aí que também simpatizam com essa idéia justamente pela questão do reaproveitamento de código), porém agora estamos bem munidos com a versão 5 do PHP. Se por ventura você está começando e não consegue entender a idéia de orientação a objetos, aconselho a começar pesquisar esse assunto pois a idéia é muito interessante e é uma tendência irreversível e inevitável, principalmente para aqueles que desejam trabalhar profissionalmente com programação. []s e até o próximo artigo! =)