O software a ser desenvolvido foi representado através de modelos. Mas esses modelos conseguem de fato apoiar a implementação?

Continuando a série A saga do herói… Ou melhor, do software!, hoje vamos falar sobre projeto, a terceira atividade do desenvolvimento de software. No primeiro texto, expliquei que, somente a partir dessa atividade, o aspecto computacional aparece. É nesse momento que os analistas de sistemas refinam os modelos gerados, incluindo os detalhes da tecnologia a ser utilizada, criando e permitindo que a qualidade do software seja avaliada.

Mas vocês podem me perguntar: “Por que fazer isso? Mais tempo com modelo? E esse software sai ou não sai?”.

E eu respondo: Já estamos quase lá! Só que não podemos resolver o problema passando rapidamente pelo projeto achando que vai sobrar tempo suficiente para encontrar e corrigir defeitos. Muito provavelmente eles foram introduzidos porque dedicamos pouco tempo ao projeto!

No primeiro texto da nossa saga, fiz uma analogia entre o desenvolvimento de software e a construção de qualquer outro produto, como uma casa. Vou retomar essa analogia para ilustrar a importância do projeto. Se você já visitou um stand de venda, sabe que encontrará uma versão miniaturizada (maquete) e/ou panfletos apresentando a distribuição dos cômodos do imóvel à venda (planta-baixa). Considerando esses dois artefatos (maquete e planta-baixa), você acha que um pedreiro conseguiria construir esse imóvel?

Minha resposta é que seria provável que esse pedreiro conseguisse chegar a um imóvel a ser vendido, mas não seria o imóvel projetado! Isso porque os artefatos disponibilizados ajudam sim a entender o “problema” a ser resolvido, mas apresentam informações em um nível ainda abstrato, sendo difíceis de serem interpretados diretamente pelo pedreiro (nosso desenvolvedor). Ele ainda precisaria de informações sobre as tecnologias utilizadas na construção e diferentes visões mais específicas para chegar ao produto final desejado. Por exemplo, a planta-baixa indica as dimensões do banheiro e posicionamento de itens como pia e chuveiro, mas onde exatamente ficarão as instalações elétricas, hidráulicas e sanitárias? Somente com o auxílio de outras plantas mais específicas, conseguiremos essas informações.

Na Computação, apesar de existir uma divisão teórica entre análise e projeto, a divisão entre essas atividades é vaga na prática, com ambas ocorrendo em continuidade. O importante aqui é que todo o material utilizado para entendimento do problema (modelos de análise) possa ser transformado em um conjunto de documentos que sejam interpretados diretamente pelo desenvolvedor (modelos de projeto), fornecendo assim uma solução computacional. Ou seja, é durante o projeto que se passa de uma visão macro do sistema para uma variedade de visões mais específicas de seus elementos de forma a orientar a implementação.

Para ilustrar esse processo, do entendimento do problema até sua representação no código, apresento um exemplo bem simples: Imaginem que estamos apoiando o desenvolvimento de um sistema para gestão de bibliotecas, em que uma das funcionalidades solicitadas pelo usuário é um relatório que liste todos os livros existentes na biblioteca. Isso nos indica que existe um conceito do domínio (Livro) que precisará ser tratado pelo sistema em desenvolvimento. Durante a análise, esse conceito do domínio será retratado como um elemento do diagrama de classes (a classe Livro – sim, somos criativos desse jeito rs), detalhando todas as suas características (informações que caracterizam a classe, como ISBN, título, resumo, páginas e edição) e comportamentos (ações que podem ser realizadas pela classe, como a impressão do relatório). Porém, essa representação ainda não pode ser transformada para um código, necessitando de um refinamento de aspectos tecnológicos. Repare que as mesmas características e comportamentos foram mantidas no modelo de projeto, mas algumas informações precisaram ser adicionadas para refinar o modelo original (o título é descrito por um conjunto de palavras e o número de páginas por um número. Por isso, definimos que eles deverão ser definidos dentro do sistema como sendo do tipo string e int, respectivamente). Esse modelo de projeto poderá ser facilmente transformado para um código pelos desenvolvedores (Vocês conseguem observar a semelhança da representação de Livro na fase de projeto e no código gerado? Não seria uma reorganização de uma figura para um texto?).

Observação importante: Para facilitar a explicação e entendimento, apresentei somente as informações necessárias para representação dessa funcionalidade. Ou seja, é apenas um recorte de um dos modelos que seriam gerados para esse cenário. A documentação completa é muito mais extensa do que essa imagem, ok?

Além disso, utilizei a orientação a objetos como paradigma para realizar a análise, projeto e implementação do sistema. Porém, existem outros paradigmas que levariam a outros produtos. Podemos falar sobre eles em outro post ?

A atividade de Projeto pode ser subdividida em duas fases: projeto preliminar e projeto detalhado. Durante o projeto preliminar, o sistema é organizado em termos de sua arquitetura. É nesse momento que os analistas definem os módulos do sistema e a forma como esses módulos se comunicarão.

No projeto detalhado que é realizado o refinamento apresentado no exemplo do sistema para gestão de bibliotecas. Mais detalhes são adicionados à arquitetura do sistema, como detalhamento de diagramas; definição de como defeitos devem ser tratados; detalhamento do formato de saída, como interface com usuário, relatórios gerados e comunicação com outros sistemas etc.; definição do esquema do banco de dados utilizado etc. Todos esses artefatos servirão como base para a implementação de um software de qualidade.

Dessa forma, podemos dizer que o projeto é o elo entre um problema (especificado durante a análise) e uma solução (operacionalizada durante a implementação). Somente a partir do material produzido nessa etapa, os desenvolvedores terão acesso a modelos que exprimem as necessidades dos usuários, considerando os aspectos tecnológicos que moldam a solução proposta.