Engenharia de software na prática

Existem várias formas de modelar sistemas, baseando-se em testes, construindo DFDs(diagramas de fluxo de dados) ou simplesmente colocando em um rascunho aquilo que prospectamos em um software. Em grandes projetos, projetos importantes ou simplesmente em rotinas vitais de sistemas, analitas necessitam usar técnicas da engenharia de software para minimizar os fatores de risco que compõem as chances falhas daquilo que desejam implementar. Softwares houses estão ou buscam estar completamente a par deste assunto para alcançar níveis de qualidade em seus processos de desenvolvimento. Inclusive existem certificações que avaliam a qualidade com que um software é produzido como ISO, CMMI, MPSBR, etc…

Grandes corporações gastam milhões em seus processos de desenvolvimento para obter melhor qualidade ou alcançar níveis de certificações mais altos para comprovar a excelência de seus projetos. IBM Brasil, Politec e mais uma meia dúzia no Brasil apresentam o nível 5 do CMMI por exemplo… Gastaram milhões e passaram por inúmeras auditorias de entidades certificadoras para poder mostrar e comprovar ao mundo que realizam as possíveis especificações de se desenvolver tecnologia com qualidade.

Obviamente não irei abordar aqui tudo que é necessário para para atingir tais níveis, até porque livros decentemente detalhados sobre este assunto geralmente conseguem ser resumidos em no mínimo 500 páginas.

Embora exista uma gigantesca organização por traz deste assunto na prática a maioria das empresas ou desenvolvedores não se utilizam de tais técnicas. Trabalhei mais de dois anos atuando no desenvolvimento, implementação, gerenciamento e prestando suporte a sistemas aéreos, gestão de turismo, gestão financeira e TEF(Transferência eletrônica de fundos). Tive a oportunidade de ter contato com diferenciados fornecedores de sistemas e aparatos tecnológicos, onde na maioria dos casos baseavam-se seus desenvolvimentos ou correções no boca-a-boca, ou de um e-mail contendo as descrições dos problemas ou no máximo um fluxo de interfaces contendo os print screens das telas de como deveriam ser adaptados os processos a realidade da empresa. Não existia uma linguagem unificada para trocarmos idéias, obviamente este processo de solicitação é falho e com probabilidades maiores de retrabalho. Estudei na faculdade e no mestrado tais técnicas de engenharia de software, vi que outros cursos de níveis superiores tinham diversas cadeiras sobre o assunto, mas ao trabalhar com empresas, e muitas empresas grandes de desenvolvimento, fiquei decepcionado e vi que realidade era outra, na prática os artifícios de engenharia de software eram pouquíssimos utilizados e o sentimento de que o trabalho ainda não estava completo e eficaz era unanimemente eminente por ambas as partes. Até mesmo empresas com certificações não mantinha uma comunicação com o departamento de tecnologia usando diagramações para resolvermos problemas ou realizar melhorias, também não sei como tais empresas conseguiam certificações do tipo MPS.BR nível F, o que me faz acreditar que talvez o critério de avaliação de tal certificação talvez seja “furado”. Mas enfim… engenharia de software é um assunto sério e decisivo para o sucesso de um sistema que está na mente ou em simples rascunhos, e este blá blá que escrevi anteriormente é para situar os leitores da importância e motiva-los ao que vou demonstrar agora.

Uma prévia de como projetar sistemas de maneira clara, detalhada, objetiva e uma das mais difundidas é a utilização de técnicas baseadas em UML (Unified Modeling Language), e é sobre parte desta técnica que vou brevemente descrever. Uma descrição sobre o UML pode ser visto neste link: http://pt.wikipedia.org/wiki/UML ou na página oficial: http://www.uml.org/

Softwares são compostos basicamente de 3 instruções: leitura, processamento e escrita. Tais instruções podem ser mapeadas objetivamente por dois diagramas bastante difundidos na UML (ER e diagrama de classes), obviamente que se empregarmos os demais descritos na UML poderemos garantir ainda mais o mapeamento daquilo que prospectamos no sistema, cada diagrama possui sua função, tem diagrama até mesmo para analisar ações do usuário perante o sistema(diagrama de casos de uso). Enfim, para planejar sistemas sem gastar um longo tempo para modelar, estes dois são suficientes para modelar a estrutura da base de dados e programação do sistema.

Diagrama de entidade e relacionamento .

Existem várias ferramentas que auxiliam na construção de tais diagramas uma bastante conhecida é o DBDesigner4 disponível em: http://www.fabforce.net/dbdesigner4/downloads.php.

Atualmente ele possui um sucessor mysql workbench disponível em: http://dev.mysql.com/downloads/workbench/5.1.html

Ambas rodam tanto em ambiente windows quanto linux.

Vídeo aula: http://www.youtube.com/watch?v=Hz3Cz6XYUhU (a parte do xampp é bobagem)

Tais ferramentas proporcionam você projetar sua base de dados, e a partir desta projeção a ferramenta gera um script contendo todo sql necessário para a geração da base de dados, com todas suas tabelas, relacionamentos, views, trigge, etc… Possui também a funcionalidade de se conectar a uma base existe e executar a engenharia reversa.

Diagrama de classes

Para modelagem da parte lógica do sistema fora a base dedados, indico duas que é o JUDE e o ArgoUML.

Ambas as ferramentas também são multiplataformas, permite construir diagramas da UML, principalmente o diagrama de classes e exportar estes diagramas para montar a estrutura de código planejada.

O JUDE a partir do diagrama de classes gera automaticamente as classes em JAVA.

O ArgoUML apresentado pelo meu amigo André tem a capacidade de gerar códigos em PHP4, JAVA, Csharp, PHP 5, etc …

Mesmo que for trabalhar de forma estruturada ou mista, colocar e organizar suas idéias nestas ferramentas antes de sair programando certamente irá poupar muito tempo de decisões, ajustes futuros e realmente viabilizar aquilo que deseja implementar.

Muitos desenvolvedores acham que isso é perder tempo ou alguns simplesmente possuem preguiça de realizar tal processo antes da codificação. Certamente tais profissionais só darão valor para isso após estarem em um emaranhado, perdendo produtividade no seu desenvolvimento e com dificuldade em mapear falhas de projeto.

Deixo aberto para questionamento e trocarmos idéias. Quem conhece ferramentas diferenciadas, mais eficazes, ou se simplesmente viu ou ouviu algo neste âmbito, por favor deixe aqui sua contribuição. Vamos tentar estabelecer aqui um ponto de discussão para amadurecermos ainda mais este assunto.

Um abraço a todos!