Por que modelar com UML?

Abstrato

A finalidade da Unified Modeling Language (daqui em diante chamada de UML) é oferecer uma notação de modelagem independente de linguagem e de plataforma. As ferramentas UML são tão versáteis quanto a UML é básica. Este artigo serve como um modelo para os conceitos básicos de UML enquanto oferece uma explicação das finalidades da modelagem. Ele não se destina a ser um manual de como fazer, mas são fornecidos links, onde apropriado, para levá-lo a tutoriais bem executados que ilustram as etapas sobre como usar os recursos UML oferecidos no NetBeans IDE.

Este artigo é escrito para os engenheiros que nunca têm tempo para modelar um projeto antes de começar a codificar e para aqueles engenheiros que ainda não consideraram a criação de modelos dos seus sistemas antes de codificá-los. Este artigo apresenta alguns métodos e estratégias para ajudá-lo a ser mais eficiente e possivelmente até mesmo economizar tempo. As informações deste artigo talvez até permitam que você mude a forma de pensar, "Nunca temos tempo de fazê-lo corretamente, mas sempre temos tempo de fazê-lo novamente."

Conteúdo

Introdução

Na cafeteria, quando você imaginou um software "incrível", pegou excitadamente um guardanapo e desenhou figuras para clarear os seus pensamentos. Suas figuras eram muito provavelmente um conjunto de rabiscos que não significavam nada para ninguém a não ser você mesmo.

Mas elas significam algo para você: aqueles rabiscos eram a explicação de uma idéia a que talvez dedique os dois próximos anos da sua vida para ver realizada. O que você criou era um modelo rudimentar. Na sua cabeça, as caixas representavam um elemento, enquanto os círculos, triângulos e linhas representavam outro elemento. Você inventou uma linguagem de modelagem no verso de um guardanapo. Se você pudesse compilar e executar o guardanapo, estaria tudo terminado. Isso não é tão impossível quanto possa parecer. Se você passasse os dois próximos meses ensinando para o computador o que cada objeto do guardanapo representava e como gerar o código-fonte de cada objeto, compilar o guardanapo seria possível.

Durante os últimos 25 anos de modelagem de guardanapo, foram criadas várias linguagens de modelagem muito úteis. Entre elas a Unified Modeling Language (UML). Os modeladores juntaram todos os seus guardanapos e concordaram com as definições de cada objeto e as relações entre os objetos. Com essa Unified Modeling Language, programadores de linguagens específicas começaram a desenvolver modelos para criar código para objetos diferentes. Agora, desde que você desenhe objetos em seu guardanapo que sejam parte da UML, seu guardanapo pode ser compilado.

"Por que devo modelar?" Essa é uma boa pergunta! Neste artigo, duas respostas são oferecidas para a sua consideração: pense nelas como casos de uso UML. A primeira resposta, em “Compilando o guardanapo,” focaliza as idéias de rascunho do engenheiro no quadro negro ou no guardanapo da cafeteria. O objetivo desta seção é mostrá-los os benefícios da modelagem durante os estágios de planejamento do seu projeto. Vários tutoriais vinculados em toda a seção podem levá-lo aos detalhes da realização da modelagem.

A segunda resposta para a pergunta “por que modelar”, encontrada na seção “O que eles estavam pensando”, focaliza o engenheiro frustrado que recebeu 300.000 linhas de código e a tarefa de mantê-las e corrigir bugs. Ele está feliz de ver que o programador original sabia sobre pacotes, mas ainda não vê como tudo isso se encaixa. Caso ele seja você, que prefere o apelo visual, você anseia por ver um diagrama do sistema para ter uma idéia do que o programador visual estava pensando. Esse é um caso de uso comum para ferramentas UML. Você efetivamente analisa o código para criar um modelo (chamado “engenharia reversa”), a partir do qual você cria diagramas.

A tabela seguinte lista os diferentes tipos de diagramas UML que podem ser encontrados online em muitos lugares, e ela é incluída aqui por conveniência. Clique na imagem em miniatura para visualizar uma amostra do diagrama específico.

Diagrama de casos de uso		Consistente principalmente em atores e casos de uso. Diagramas de caso de uso ajudam a capturar o requisito funcional do seu sistema. Trata-se sempre de um excelente diagrama com o qual iniciar um projeto.	visualizar tutorial
Diagrama de componentes		Consiste principalmente em componentes principais do sistema e seus relacionamentos. Trata-se de um diagrama de visão geral de alto nível do seu complicado sistema. Esteja em sua cabeça, em um guardanapo ou em uma ferramenta UML, esse diagrama foi criado para cada projeto em que você um dia trabalhou.	tutorial vindo em breve
Diagrama de classes		Consiste principalmente em classes, interfaces e seus relacionamentos. As classes e interfaces são extremamente diretas, mas os relacionamentos podem se tornar um pouco complicados com multiplicidade, generalizações e associações. Depois que você souber quais são os componentes do seu sistema, a progressão natural é criar o diagrama das classes que formam os componentes	visualizar tutorial
Diagrama de atividades		Consiste principalmente em atividades e decisões. Esses digramas são essencialmente fluxogramas e diagramas de fluxo de dados que você usa para conhecer o fluxo geral do código	visualizar tutorial
Diagrama de colaboração		Consiste principalmente em objetos e mensagens. Este diagrama focaliza a comunicação entre os objetos e é semelhante ao diagrama de seqüência.	visualizar tutorial
Diagrama de deployment		Consiste principalmente em elementos de deployment, tais como servidores, e seus relacionamentos. Trata-se de uma topografia lógica do seu sistema.	tutorial vindo em breve
Diagrama de seqüência		Consiste principalmente em objetos (com linhas de vida) e mensagens de chamada. Os diagramas de seqüência representam a ordem de chamadas em seu sistema, assim como a criação dos diferentes objetos.	visualizar tutorial
Diagrama de estado		Consiste principalmente em estados, transições, eventos e ações. Os diagramas de estado são raramente necessários exceto quando a lógica é muito complicada.	tutorial vindo em breve

início

Compilando o guardanapo

Você volta da cafeteria com suas idéias esboçadas em um guardanapo. Você precisa descrever uma solução para o seu grupo ou o seu chefe. Portanto, você transcreve as suas idéias do guardanapo para o quadro negro e leva todos os seus colegas para a sua baia para mostrá-las. Nenhuma ferramenta de software jamais substituirá a conversa que acontece em torno do quadro negro, mas se você precisa enviar a sua idéia para fora do escritório, ela geralmente é enviada em Polaroids ou por email com fotos digitais do seu quadro negro. O quadro negro não facilita a documentação das suas idéias, para que você possa se referir a elas mais tarde. Talvez você não goste, mas é preciso encontrar uma ferramenta UML e criar o modelo que descreva a idéia.

Embora um modelo seja uma coleção simples de elementos de modelo e seus relacionamentos, esses elementos podem ser agrupados para formar diagramas. Esses diagramas são maiores que a soma dos elementos, já que eles oferecem várias visualizações do seu modelo. As visualizações diferentes podem ser usadas para contar uma história sobre como a aplicação é estruturada. O tipo de diagramas que você usa para visualizar seu modelo depende do seu problema.

Quando estiver começando, talvez você opte por criar o diagrama de caso de uso. Trata-se de um bom diagrama de visão geral que identifica os componentes principais do seu projeto. Embora o diagrama de caso de uso possa se tornar tão complicado quanto necessário, ele na verdade tem somente duas partes principais: o ator e o caso de uso. Um ator representa uma entidade que irá interagir com o seu sistema. Um exemplo de uma entidade pode ser um “cliente” ou “caixa de banco” que interage com o seu programa. O ator poderia ser até mesmo uma biblioteca de terceiros ou um hardware. A idéia principal do diagrama de caso de uso é mostrar que esses atores podem interagir com o seu programa. Por exemplo, um caixa de banco pode “depositar dinheiro” ou “sacar dinheiro”. Neste caso, “depositar dinheiro” e “sacar dinheiro” são casos de uso. Nenhum código está diretamente relacionado ao ator ou casos de uso, mas essas interações expõem a necessidade de certos componentes em seu projeto.

Pensar em casos de uso é freqüentemente esquecido durante a fase de planejamento e como qualquer programador sabe, uma análise de caso de uso terá que acontecer finalmente. Pensar em quais são os requisitos do seu projeto evita a implementação desnecessária de recursos e o esquecimento de outros. Criar um diagrama de caso de uso também deve expor quaisquer pontos que tenham sido esquecidos. O diagrama não pode impedir que você adicione recursos desnecessários, mas ele pelo menos lhe informam que esses recursos não são necessários. Sendo assim, a primeira etapa é realizar uma análise de caso de uso e criar diagramas de caso de uso. Um tutorial guia você através do processo de criação de um diagrama de caso de uso.

A conclusão da análise de caso de uso e de diagramas leva naturalmente ao esboço dos componentes do seu sistema. Seja na cabeça, em um guarnapo, ou em uma ferramenta UML, essa etapa nunca foi ignorada no desenvolvimento de um sistema bem sucedido. O benefício de criar formalmente um diagrama de componentes é que ele pode ajudá-lo a definir as classes e as que formarão seus componentes. Caso tenha concluído o tutorial do diagrama de caso de uso, você pode ver como essa análise é importante. No diagrama de caso de uso no fim do tutorial, alguns dos componentes necessários se tornam evidentes: um componente Customer, um componente Account e um componente Database. As interações entre os componentes pode ser mais bem definida com diagramas de colaboração e de seqüência. Esses componentes representam os itens de entrega do seu sistema. Esses são os itens que o seu chefe, o cliente ou terceiros devem aprovar como suficientes. Até que haja acordo quanto aos componentes, o arquiteto e os programadores estão mirando em um alvo móvel. Mas depois que os componentes são definidos, o ajuste do trabalho estrutural pode começar.

Esse ajuste de design é iniciado com a criação do diagrama de classes. Novamente, um tutorial pronto para usar irá guiá-lo pelas detalhes da criação de um diagrama de classes. Caso tenha feito o esforço de criar o caso de uso e os diagramas de componentes corretos, talvez você fique tentado a sentar e começar a codificar. Mas lembre-se da última vez que você fez isso e depois teve que recriar interfaces e superclasses porque não viu os relacionamentos necessários quando iniciou a codificação?

Quando cria seu diagrama de classes, você é forçado a fazer com que todas as partes se encaixem, refletindo onde você precisa de interfaces, superclasses e até mesmo padrões de design inteiros. Sendo assim, você vê que o benefício desses diagramas é que eles expõem estruturas de herança antes de você escrever várias classes e ver que está escrevendo os mesmos métodos repetidamente.

Usar a ferramenta UML do NetBeans adiciona outra boa dimensão ao diagrama de classes, chamados padrões de design. Se você sabe que um determinado componente do seu sistema utilizará um padrão de design ou conjunto de padrões, simplesmente arrastar e soltar o padrão na tela cria o componente básico para você. Melhor ainda, a ferramenta o cria corretamente. Não precisa lembrar como o padrão de design é realmente estruturado. O recurso UML do NetBeans oferece os padrões de design Gang of Four (GoF) e Enterprise Java Beans (EJB) prontos para serem usados. Se você usa um padrão de design freqüentemente, pode salvá-lo para uso futuro.

A melhor notícia é que nenhuma parte desse trabalho é perdida. Se você estiver usando o recurso UML do NetBeans, um diagrama de classes pode ser transformado em um código-fonte Java com o clique de um botão. Você pode até mesmo definir as opções de como o código deve ser gerado: cabeçalhos, comentários, colocação de variáveis e outra formatação. Essas definições incluiriam inclusive a adição de informações de direito autoral a todos os arquivos gerados. Somente a geração de código deveria tornar essa etapa válida durante o ciclo de desenvolvimento. Portanto, é válido o seu tempo de criar o modelo primeiro e deixar a ferramenta gerar o código básico.

Os diagramas de todos estão em um formato ou em outro. A diferença é que aqueles que criam diagramas por meio de uma ferramenta UML têm algo para mostrar de seu esforço de planejamento quando os diagramas são concluídos. Os guardanapos têm a tendência de serem usados para limpar bebidas derramadas e serem jogados fora. Cada projeto que seja bem pensado terá alguma forma de diagramas de caso de uso, diagramas de componentes e diagramas de classes que podem durar bastante depois que a “imaginação” na cafeteria tiver terminado.

início

O que eles estavam pensando?

UML simplesmente uma linguagem de modelagem e é independente de qualquer linguagem de codificação. Portanto, assim como a UML pode ser convertida em uma linguagem de codificação, uma linguagem de codificação pode ser convertida em UML. Esse processo é conhecido como “engenharia reversa”. Existem vários usos para esse processo, porém o mais comum é simplesmente obter uma visualização de como o código é estruturado: quais são os objetos e como eles se relacionam? Ver diagramas do código pode expor padrões de design e outras complexidades que podem não ser óbvios durante a leitura do código. Para o tutorial “como” sobre o uso da ferramenta UML do NetBeans, consulte o tutorial chamado Reverter engenharia de aplicações Java

Embora este artigo não se destine a ser um tutorial, se você estiver usando o NetBeans para reverter a engenharia, é preciso considerar algumas etapas. Comece com uma base de código Java de forma livre. A primeira etapa na reversão da engenharia dessa base de código é criar um “projeto Java com códigos-fonte existentes” do NetBeans. Os assistentes do NetBeans podem ajudá-lo nesse processo. Depois que o projeto é criado, um item de menu é adicionado ao projeto para reverter a sua engenharia. Mesmo em projetos grandes, esse processo leva apenas alguns momentos. Quando concluído, um projeto UML aparece na árvore do projeto.

Este projeto agora pode ser manipulado, se desejado. Podem ser criados diagramas a partir dos elementos de modelo gerados. Se for preciso fazer alterações nos diagramas, simplesmente altere e gere novamente o código (“engenharia avançada”). É possível substituir o código a partir do qual o modelo veio ou armazená-lo em algum outro lugar. Observe a força desses recursos. É possível desenvolver o código a partir do próprio modelo. Essa flexibilidade permite que você mantenha todas as habilidades visuais e de relatório do modelo enquanto é capaz de compilar e executar seu código. Realmente é o melhor de ambos os mundos. Se você gosta de digitar o código em vez de criá-lo a partir de diagramas, é possível fazer exatamente isso. Quando o seu gerente pedir uma revisão do código, simplesmente reverta a engenharia do código para atualizar o modelo e leve os diagramas para a reunião.

Embora a engenharia reversa seja uma ferramenta tremendamente útil para ajudá-lo a entender o código legado, ela não fornece respostas para todas as perguntas. Por exemplo, os casos de uso não podem ser criados a partir de um modelo que tenha sido criado por engenharia reversa. Você não esperaria esse resultado, já que o código contém um nível diferente de informações que podem ser requeridas pelos casos de uso. Outros diagramas que não faz sentido criar a partir de modelo de engenharia reversa são diagramas de componentes, atividades, colaboração, estado e deployment. Mas, como os elementos de classe e os relacionamentos são conhecidos, qualquer um desses diagramas podem ser rapidamente criados e você pode, então, deduzir as respostas para as perguntas que naturalmente se seguem: o que são os casos de uso? O que é a estrutura de deployment? Quais são os componentes principais? Você precisa somente fornecer as informações pertinentes que estão faltando para esse diagrama a fim de ter um modelo totalmente desenvolvido.

início

Resumo

UML é uma linguagem. Embora existam ótimas ferramentas para trabalhar em UML, ela continua sendo uma linguagem. Se você não entender as estruturas da linguagem, as paletas de design nas ferramentas podem apenas frustrá-lo. Para tornar a linguagem “unificada,” a UML incluiu várias funcionalidades. Esse pacote pode tornar as ferramentas UML incômodas e difíceis de usar. A Sun Microsystems oferece uma classe para aprender a UML no contexto de análise e design orientados a objeto. Usando seu conhecimento do contexto dos elementos diferentes em UML, seus modelos podem chegar a um nível superior de praticidade e eficiência. Se você estiver criando modelos por meio dos elementos errados, eles não poderão ser convertidos em código.

Se você for um arquiteto ou programador, a modelagem é uma etapa necessária em qualquer projeto que seja mais complicado do que HelloWorld. Por exemplo, algumas linguagens de modelagem são ajustadas para coisas como design de banco de dados, mas se você só tem tempo de aprender uma linguagem de modelagem, a UML se tornou o padrão da indústria para modelagem. As ferramentas UML, tal como o recurso UML do NetBeans, se desenvolveram tanto que a modelagem não é mais uma perda de ciclos ou simplesmente um exercício acadêmico que é lançado depois que a programação começa. As ferramentas podem e realmente ajudam você a programar, dando-lhe uma chance de iniciar o ciclo novamente na cafeteria.

---

Este artigo foi atualizado pela última vez em 19 de outubro, 2007

início