A ideia de modelar um software visualmente, e as ferramentas que suportam essa empreitada, tem estado ai por anos. Porém, muitos desenvolvedores e gerentes de projeto podem não entender o porquê isso é importante para o desenvolvimento de software. Algumas vezes o gerente do projeto entende a razão para as ferramentas de modelagem, mas precisam convencer seus superiores, que ultimamente precisam autorizar grandes comprar de softwares. Esse artigo lhe dará uma visão geral para justificar a modelagem de software, bem como razões para usar ferramentas de modelagem. Também descreve os recursos mínimos que qualquer ferramenta de modelagem deve ter.
Por que modelar?
“Se você entendesse isso, não deveria chamar de código” — de um anuncio da Federal Express, reportado por Matthew Persico. Alguns gerentes de desenvolvimento se perguntam por quê modelagem é de tão importante. No final de tudo, o código deve falar por si. Essencialmente, o código é o modelo. Por que adicionar uma camada extra de abstração que temos que manter durante o progresso do projeto? A razão é que existem vários beneficios claros que modelos fornecem a organização do desenvolvimento. Elas são comunicação melhorada, melhor planejamento, redução de riscos e de custos.
Comunicação melhorada
O início da descrição legal de meu pedaço de terra é mostrado na figura 1. Se você for um inspetor, deve ser capaz de a partir da descrição desenhar meu lote, e apontar em um mapa onde exatamente minha casa fica. Para um inspetor ou advogado, esse é o “código” que descreve o lote que me pertence. Enquanto isso é uma descrição exata de minha propriedade, não é uma maneira natural de ver o mundo. Dada a descrição acima, um inspetor experiente pode ter um visão geral de como meu lote parece, a direção dele, e assim em diante. Ele poderia criar uma foto mental desse pedaço de terra. Porém, mesmo isso não é uma coisa natural para qualquer pessoa, não importa quão matematicamente inclinada ela possa ser. Qualquer um irá desejar ver um desenho do lote. Como você pode ver, o lote é relativamente plano – um pouco retangular em sua forma, nada extraordinário.
Assim, como parte de um trabalho de inspeção, ou compra de uma casa, existirá sempre um desenho do lote que explique como ele se parece. Qualquer pessoa pode olhar esse desenho e ver imediatamente o que ele representa. O inspetor também incluirá um visão geral de alto nível, mostrando toda a vizinhaça e mesmo as conexões com o resto da cidade.
A razão para a qual queremos ver uma foto é que humanos naturalmente querem se comunicar da forma mais simples possível. Dizemos que “uma imagem vale mais que mil palavras”. Em termos de modelagem, isso posse ser traduzido como “uma diagrama de classe vale mais do que mil linhas de código”. Ou “um diagrama de caso de uso vale mais do que dez chamadas telefônicas, um discussão com o chefe e três reuniões com o cliente”. Pela apresentação de idéias e conversas como diagramas de caso de uso, ou linhas de código como diagramas de classe, podemos cobrir uma tremenda quantidade de informação apenas mostrando uma imagem na tela.
Engenheiros de software são equivalentes a inspetores nesse caso. Eles entendem o código e como ele se encaixa. Porém, uma importante diferença é que cada engenheiro pode ser responsavel por milhares de linhas de código. Imagine de a descrição legal acima tivesse milhares de linhas, e representasse um bairro inteiro! Seria muito dificil manter tudo isso na cabeça de uma só pessoa, e comunicar essa informação de uma forma não visual.
Um desenvolvedor experiente pode pegar um projeto de software existente, olhar o código fonte desse projeto e iniciar a construção de uma imagem mental de como o código é organizado. Isso pode ocupar até o mais brilhante engenheiro por várias horas. Porém, se ele tiver um modelo visual, será capaz de olhar e de imediato ver como ele está organizado, com apenas un s poucos diagramas.
Comunicação visual também é importante da perspecticva de um gerente ou usuário. Enquanto engenheiros podem entender o código, uma imagem visual para um cliente é muito mais útil. O cliente provavelmente não entenderia os detalhes de uma linguagem de programação, mas eles podem ser capazes de entender, ao menos no alto nível, alguns dos componentes chaves de um modelo de objeto.
Comprimir a comunicação em diagramas visuais diretamente reduz o custo de qualquer projeto de software. Se cada engenheiro de software de seu projeto puder economizar algumas poucas horas de trabalho investigativo por dia apenas pela observação de alguns poucos diagramas, o custo de seu projeto irá cair dramaticamente. Além do mais, se você puder explicar seu projeto com alguns poucos diagramas, pode reduzir bastante o número de reuniões e apresentações que você precisará para explicar no que você está trabalhando.
Existem alguns tópicos de negócios atuais que tem tornado a comunicação entre times de desenvolvimento de software mais dificil. O primeiro tópico é a agregação de pequenas companhias em companhias maiores. Enquanto isso pode frequentemente levar a uma maior eficiência do negócio em geral, também significa que o departamento de TI dessas companhias irão ter diferentes processos de desenvolvimento, e diferentes mecanismos de comunicação. Um time pode tomar as responsabilidades de outros, e eles precisarão de ferramentas de ajuda para entender e manter projetos de software legados. Outro tópico é o aumento de terceirização do departamento de TI para empresas estrangeiras. Aqui você tem uma separação geográfica, assim como barreiras de idioma e cultura. A medida que esses tópicos avançam, qualquer ferramenta que possa facilitar a comunicação dará a sua organização uma grande vantagem competitiva. Um diagrama visual trancende barreiras de idioma e cultural e pode permitir que times separados trabalhem juntos facilmente.
Tipos de informações cobertas por diagramas
Diagramas de projetos de software podem representar um amplo espectro de informações, desde a arquitetura de alto nível até o código fonte. Abaixo seguem algumas das coisas que você pode representar visualmente usando diagramas padrão:
• Arquitetura geral do sistema
• Dependências do sistema
• Complexidade
• Fluxo de informações através do sistema
• Requerimentos do negócios
• Organização e estrutura do banco de dados
• Código fonte – incluindo quase todos os aspectos do desenvolvimento orientado a objetos
• Configurações da instalação
Melhor planejamento e redução de riscos
Os dois maiores riscos de qualquer projeto de software são tempo e qualidade. A modelagem pode reduz esses dois riscos. Pelo uso de modelos visuais para projetos de software, podemos ter uma visão macro do projeto. Podemos organizar conceitos dominantes em diagramas de alto nível, que podem ser exercitados em diagramas mais detalhados.
Um resultado disso é que engenheiros e arquitetos que estimam o esforço necessário para o projeto podem intuitivamente entender a complexidade do problemas que está sendo resolvido. Uma tarefa que poderia ser vista como um esforço simples de três semanas na superfície pode emergir como um problema mais dificil de ser resolvido. Tarefas e times podem ser organizados em torno de áreas maiores de funcionalidade. As linhas de modularidade podem ser aparentes mesmo nos níveis mais altos dos diagramas.
Por diagramas estarem cobertos por planejadores do projeto, estimativas podem ser determinadas usando a entrada das pessoas. As tarefas que podem precisar de vários times podem ser entendidas rapidamente, e os interessados entenderão porque eles precisarão estar envolvidos em sub-sistema em particular. Enxergar a complexidade do projeto no alto nível pode ajudar a reduzir os riscos também. A complexidade pode naturalmente levar a problemas com a qualidade. Esse complexidade pode ser minimzada pela refatoração dos diagramas, ou mesmo somente pela identificação dos riscos e sabendo que eles podem ser observados de perto a medida que o projeto avança.
O que você precisa de uma ferramenta de modelagem?
Você pode estar convencido dos beneficios da modelagem. Porém, está claro que se você for fazer isso a mão, ou mesmo com uma ferramenta de desenho que suporte diagramas UML, isso pode se tornar rapidamente numa quantidade de trabalho enorme. Você precisará de uma equipe dedicada para manter todas as mudanças nos modelos. O código fonte nunca fica parecido com o modelo que seu time pensou inicialmente. Você até testar isso em projetos “menores” antes. Fazendo isso irá lhe convencer deve haver uma maneira mais fácil. Existem várias coisas que uma ferramenta de modelagem pode fornecer a você, incluindo UML, sincronização continua entre modelo e código, recursos para o time, refatoração, relatórios, auditorias e métricas, e integração com outras ferramentas.
O UML é a linguagem de modelagem de software definitiva. Esse padrão emergiu nos anos 90 quando os lideres da modelagem de software se juntaram para tirar as melhores idéias de seus processos de modelagem e criar uma linguagem padrão para modelagem de software. O padrão UML é dirigido pela Object Management Group, ou OMG. Para mais informações, veja www.omg.org. Um importante ponto de partida para aprender sobre UML é o livro UML Distilled: A Brief Guide to the Standard Object Modeling Language (2nd Edition), de Martin Fowler and Kendall Scott (Addison Wesley, 1999).
A tabela abaixo lhe dará uma visão geral dos principais diagramas do UML e o que eles cobrem. Os diagramas abaixo estão disponíveis na formato UML 1.3 ou mais recentes.
A ferramenta de modelagem que você escolher deve lhe fornecer suporte para todos os diagramas acima, Além disso, o fornecedor que você escolher deve ter planos para suportar os padrões UML que surgirão. Porém, não é estritamente necessário que a ferramenta que você escolher suporte a ultima versão disponível – existe um atraso natural para o suporte das ferramentas a última especificação. Além disso, você irá querer permitir algum tempo para sua própria organização de desenvolvimento aprenda a última especificação e consiga atingir as melhores práticas antes de começar a usá-la.
Modelos e código sincronizados continuamente
Muitas ferramentas de modelagem tem engenharia de ida e volta. Isso deve ser considerado apenas um dentre todos o requisitos de uma ferramenta de modelagem. Uma ferramenta de modelagem deve ter a habilidade de fornecer sincronização continua entre o modelo e o código.
Uma ferramenta de modelagem que suporte isso mantém modelagem do projeto sincronizada com o código fonte. Um engenheiro pode checar o código mais recente, e ver de imediato como o modelo está. Nenhum outro passo é necessário. Algumas ferramentas de modelagem fornecem recursos engenharia para frente ou reversa, mas isso é um pouco diferente da sincronização continua. A engenharia para frente e reversa tipicamente significa que você irá gerar código a partir do modelo quando atingir um determinado ponto, ou vice-versa. O problema com isso é que seu time terá que operar como se nada estiver sendo sincronizado. Um engenheiro que estiver examinando o código precisa saber com o que o modelo se parece em um dado momento, não como ele se parece duas semanas atrás ou mesmo ontem. Engenharia reversa do modelo a partir do código é tedioso, e remove muitos benefícios reais da sincronização continua. Sem ela, as “idas e vindas” da geração de um modelo a partir do código fonte e retorno ao código resultará em perdas significativas de dados, gerando código inútil.
Os benefícios da sincronização continua não podem ser exagerados. Os desenvolvedores que utilizam esse recursos frequentemente se recusam a trabalhar em um outro projeto sem uma ferramenta similar. A razão para isso é que eles tendem a ser mais produtivos com a ferramenta, e podem eliminar muito do tédio de tentar entender o código que alguém escreveu antes deles.
Existe um porém em relação ao último paragrafo. Seu processo de desenvolvimento pode ser muito desenhado ou orientado ao modelo. Nesse caso, a sua organização coloca um alto valor na modelagem, e você provavelmente não precisa nem mesmo ler esse artigo. Porém, é importante observar que em um processo orientado ao modelo, a importância da sincronização não é tão alto. Isso se deve frequentemente por que o processo segue seu caminho, ao invés de um estilo iterativo e experimental. Muitas ferramentas que sincronizam modelo e código fonte permitirão que você desligue esse recurso se não for necessário em seu processo.
Recursos para o time
Toda ferramenta de modelagem deve fornecer a você acesso direto a um sistema de gerenciamento de código fonte. Isso sozinho deve valer o custo de muitas ferramentas caras do mercado. A integração com gerenciadores de sua escolha permite que você possa compartilhar informações entre o seu time, mantendo múltiplas versões de seu projeto e elementos do modelo. Tentar gerenciar centenas ou milhares de arquivos, cada um podendo ter diferentes versões, pode ser uma tarefa pesada mesmo para projetos pequenos.
Refatoração
A refatoração é parte de qualquer processo de desenvolvimento iterativo. Um engenheiro tenta fazer algo, observa o resultado, e percebe que pode ficar melhor. Tradicionalmente, isso pode significar apagar um diagrama de caso de uso, e encontrar código adequado em uma IDE para modificar. Ou, pode ser procurar no código por dependências de um método que foi alterado de uma classe para outra.
Uma ferramenta de modelagem que suporte sincronização continua do modelo e código fonte tem todas as informações mais recentes sobre o código, de modo que deve tirar vantagem dessa informação e permitir ao desenvolvedor refatorar o projeto. Isso pode incluir mover um método para um super classe, para outra classe ou mudar completamente a hierarquia de uma classe. Existem dúzias de maneiras de refatorar o código, e uma boa ferramenta de modelagem deve ser capaz de manipular elas, seja pela edição do código fonte ou pela alteração dos objetos pelo diagrama.
Padrões
A ideia de padrões, como aplicada na engenharia de software, foi introduzida no livro Design Patterns, de Erich Gamma, Richard Helm, et al. (Addison-Wesley, 1995). A ideia tem sido estendida desde então para incluir não apenas padrões de modelagem, mas também padrões mais granulares como pedaços de código, etc.
Uma boa ferramenta de modelagem deve fornecer um completo repertório de padrões, incluindo padrões de modelos, específicos de linguagens como os padrões do J2EE, padrões básicos para operações comuns como implementação de interfaces, etc. Além disso, o mecanismo de padrões deve ser extensível, de modo que você possa criar o seus próprios padrões a medida que descubra eles.
Engenharia reversa
No mercado de tecnologia atual, há grande pressão em redução de custos. Redução de custos podem incluir atualização de sistemas existentes ao invés de criar um novo software. Um desenvolvedor pode receber a tarefa de manter um software que foi criado por um time que recebeu um novo projeto. Pode ser que exista bem pouca documentação disponível para esse projeto.
O valor da ferramenta de modelagem pode ser enorme nesse caso. O desenvolvedor pode tirar vantagem do código existente, criar modelos a partir dele, e quase que instantaneamente entender como o software foi criado. Isso pode economizar semanas de esforço por parte do desenvolvedor, mesmo para mudanças relativamente pequenas.
Relatórios
Existem muitas vezes durante o desenvolvimento do software onde você precisará criar um relatório de seu trabalho. Você pode querer dar a chefia uma visão geral do projeto. Ou pode querer deixar que um colaborador analise um determinado ponto. Não importa a razão, uma ferramenta de modelagem deve fornecer relatórios bastantes personalizáveis para o modelo assim como para o código representado pelo modelo.
Integração
Finalmente, uma ferramenta de modelagem deve trabalhar bem com as outras ferramentas do processo de desenvolvimento do software. Uma ferramenta de modelagem deve ter uma integração sem remendos com as ferramentas necessárias, de modo que os arquitetos possam ver exatamente o que eles estiverem criando, e checar os requisitos quando estiverem traçando os elementos do modelo. Você deve ter alguma forma de integração com o servidor de aplicação para o qual está desenvolvendo, ou ao menos integração com um IDE que suporte o servidor de aplicação. Finalmente, como mencionado acima, a ferramente deve ter integração total com o sistema de gerenciamento de código fonte.
Conclusão
Existem vários argumentos fortes para modelar a sua aplicação. Porém, existem muitos contra-argumentos também. Esse contra-argumentos giram em torno do trabalho de manter o modelo de uma aplicação. Com boas ferramentas de modelagem, você não terá que se preocupar com detalhes da modelagem. Ao invés disso, terá grandes ganhos com comunicação e eficiência.