PauloMotta.pro

A linguagem unificada de modelagem (do inglês Unified Modeling Language – UML) é uma ferramenta poderosa para expressar o conhecimento obtido através das técnicas de análise de sistemas. No entanto para ser usada corretamente precisamos entender bem do que se trata.

A primeira coisa a entender é que esta ferramenta é visual, no sentido de que define componentes visuais para representar os conceitos identificados em um sistema e as formas como esses conceitos se relacionam. Isto não quer dizer que a ferramenta tenha uma plataforma visual, sendo apenas uma especificação que diversos fabricantes usam para definir suas próprias plataformas (gratuitas ou pagas) para suportar o uso da ferramenta (UML). Isso significa, inclusive, que os fabricantes estão livres para representar internamente essas estruturas que compõe a especificação da forma que acharem mais conveniente. As evoluções no sentido de interpretar modelos para gerar código propostas pela MDA tentam convencer fabricantes para convergir para uma representação unificada (ou pelo menos de fornecer a capacidade de exportar em um modelo comum em XML) a fim de que possa ser possível processar a informação, já que a leitura de imagens seria totalmente sem cabimento.

A segunda coisa a ter em mente é que a UML não é uma metogologia, técnica ou processo para desenvolver sistemas. Simples assim, não é e pronto. Usar UML não significa ter um sistema orientado a objetos, não significa nem mesmo ter um sistema certo (nem certo do ponto de vista de realizar as funções esperadas pelo usuário, nem do ponto de vista de estar sem erros.) Possivelmente é nesta segunda etapa que os estudantes e usuários de UML tenham mais problemas.

Atualmente no mercado é praticamente impossível achar uma vaga de estágio ou emprego para desenvolvimento de sistemas que não peça conhecimentos de modelagem e de UML. Muitas vezes o que os empregadores não percebem é que o tanto que é requisitado, principalmente de estagiários, torna praticamente impossível contratar alguém, acabam que as entrevistas passam a ser mecanismos repletos de ficção, porque o candidato diz que sabe e o entrevistador tenta avaliar o melhor possível se isso é uma verdade. Considerando que os cursos de computação tem duração de 3 a 5 anos dependendo da instituição e do enfoque e que para o aluno entender realmente de anális e e desenvolvimento de sistemas demora até que tenha completado um ciclo de disciplinas que pode levar de 1 a 2 anos. Além disso, para que o aluno entenda como as disciplinas se relacionam também existe um tempo próprio. Então até que o aluno-candidato esteja pronto para fazer uma entrevista ele estará praticamente formado pelo curso e aí a ideia de um estágio já começa perder o sentido já que seu princípio é o de colocar na prática o que se está vendo no curso.

A relação entre esses tempos e o uso correto da UML está no fato de que são requisitos para o uso eficiente e correto da UML saber fazer análise e um processo de desenvolvimento de sistemas. Esses dois requisitos são extensos e densos por si só, e se não forem conhecidos corretamente não tem sentido usar UML. Vejamos porque:

• UML serve para documentar a análise – para documentar alguma coisa precisamos das técnicas para identificar essa coisa, em sistemas são técnicas de entrevista, escrita, itens tecnológicos (que vão fundamentar a infraestrutura do sistema e sua arquitetura,) textos, algoritmos e padrões entre outros. Se o analista não conhecer esses fundamentos corretamente não conseguirá fazer o levantamento de informações necessário para usar a UML.
• Diagramas da UML não têm uma ordem implícita – a UML define um conjunto de diagramas que são mais ou menos úteis em cada tipo de situação de desenvolvimento de sistemas, mas esses diagramas na verdade são TODOS opcionais, isso mesmo, o analista vai usar os diagramas que julgar mais importantes, que o cliente solicitar (quando o cliente tem um processo próprio), ou que se adequarem melhor à situação. Além disso, não tem nada na UML que diga que deve-se fazer primeiro o diagrama X ou Y, então por si só a UML não é capaz de definir o fluxo pelo qual vamos executar nosso trabalho a fim de conceber e desenvolver o sistema para o usuário. O efeito colateral disso é que muitas vezes o sistema é feito de maneira ad-hoc e no final são usadas ferramentas para gerar modelos reversos, ou seja, ler o código e gerar os diagramas. Está técnica de gerar modelos reversos é muito útil quando estamos tentando entender um sistema existente e não temos documentação nem acesso aos desenvolvedores originais da equipe, mas não deveria ser usada como técnica de desenvolvimento normal.

Então as empresas deveriam gastar mais tempo investindo em consolidar seus processos de desenvolvimento e treinar seus contratados do que buscar pessoas já prontas.

Além de saber usar a UML como linguagem para representar seus conceitos, o analista precisa dominar técnicas de levantamento e escrita das necessidades de seu cliente, a correta identificação dos requisitos é fundamental para o desenvolvimento de um sistema que atenda o cliente. E mais uma vez não existe representação de requisitos na UML, essa é uma outra parte que precisa ser realizada antes de partirmos para utilizá-la. Até mesmo os casos de uso que são tão falados não fazem parte da UML! O que existe na UML é um diagrama que representa as relações entre casos de usos bem como com seus atores, mas não quais os passos de um caso de uso. Até podemos falar que um diagrama de atividades poderia ser usado para representar os passos de um caso de uso, mas isso seria uma subutilização deste elemento.

Uma vez que o analista domine todos esses aspectos e essas dimensões chega a hora de usar a UML e nesse momento surge uma outra dúvida, qual ferramenta gráfica usar? Vale a pena mesmo usar uma ferramenta gráfica diretamente?

Existem várias ferramentas gráficas para UML gratuitas e pagas, com diferentes capacidades e recursos, e claro diferentes faixas de preços. Uma comparação entre as ferramentas precisa de um artigo próprio, mas uma coisa que pode ser evidenciada as ferramentas gratuitas apresentam realmente muitas limitações em relação as suas versões pagas. Se o custo for um fator determinante para o projeto (e normalmente é) deve-se levar em conta que as ferramentas que são integradas ao ambiente de desenvolvimento podem oferecer mais capacidades de geração de código e isso pode ajudar no desenvolvimento do projeto.

Quanto ao aspecto de quando começar a usar uma boa dica vem do pessoal de métodos agéis, que pregam que devemos fazer a análise em um quadro branco ou mesmo em uma janela, e somente depois de chegarmos a algum acordo básico sobre o que será feito devemos passar aquilo para uma ferramenta. Na verdade essa dica é bem compreensível porque a área visível que temos em qualquer ferramenta é muito menor do que qualquer quadro branco (ou janela) e como no início vamos fazer muitas modificações até chegar a uma versão mais estável então é muito incomodo trabalhar direto em uma ferramenta.

Então para encadearmos o conhecimento a melhor ideia é seguir:

1. Conhecer as técnicas de análise – permite escrever as necessidades do cliente
2. Conhecer um processo de desenvolvimento de sistemas – determina como encadear o que deve ser feito e quando deve ser feito
3. Conhecer a UML – contém os artefatos que são necessários para documentar o que foi analisado
4. Conhecer uma ferramenta gráfica UML – permite desenhar os conceitos e possivelmente gerar os códigos base para o sistema.

Seguindo essa ordem a chance de ter sucesso com o desenvolvimento de sistemas aumenta drasticamente porque passa a ser uma atividade coordenada.