UML

O que é Unified Modeling Language?

A UML UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de orientação a objetos – OO. Essa linguagem tornou-se, nos últimos anos, a linguagem padrão de modelagem de software adotada internacionalmente pela indústria de desenvolvimento de software.

Completo: Curso de UML

Deve ficar bem claro, no entanto, que a UML, não é uma linguagem de programação e sim uma linguagem de modelagem, cujo objetivo é auxiliar os analistas de software a definir as características do software, tais como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e ate mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema devera ser implantado. Todas essas características são definidas por meio da UML, antes do software começar a ser realmente desenvolvido.

Por que modelar software?

Qual a real necessidade de se modelar um software? Muitos “profissionais” podem afirmar que consegue determinar todas as necessidades de um sistema, de cabeça e que sempre trabalharam assim. Isso pode ser verdade, mas a questão é muito mais ampla, envolvendo fatores extremamente complexos, como levantamento e analise de requisitos, prototipação, tamanho do projeto, complexidade, prazos, custos, documentação, manutenção e reusabilidade.

Importante: Eu sobrevivo sem UML?

Normalmente os sistemas estão em constante mudança. Essas mudanças se devem a diversos fatores, como por exemplo:

• Os clientes desejarem constantemente modificações ou melhorias no sistema;
• O mercado estar sempre mudando, o que forca a adoção de novas estratégias por parte das empresas e conseqüentemente de seus sistemas.

Desta forma, um sistema, precisa possuir uma documentação extremamente detalhada, precisa e atualizada para que possa ser mantida com facilidade, rapidez e de maneira correta, sem produzir novos erros ao corrigir os antigos. Modelar um sistema é uma forma bastante eficiente de documentá-lo, mas a modelagem não serve apenas para isso, a documentação é apenas umas das vantagens fornecidas pela modelagem.

Levantamento e analise de requisitos

mas das primeiras fases de analise de software consistem no levantamento de requisitos como (analise de requisito, projeto, que se constitui na principal etapa da modelagem, codificação, testes e implantação). Assim o analista de sistema busca compreender as necessidades do usuário e o que ele deseja que o sistema a ser desenvolvido realize. Isto é feito principalmente por meio de entrevista, onde o analista de sistema tenta compreender como funciona atualmente o processo a ser informatizado e quais serviços o cliente precisa que o software forneça.

Relacionado: Levantamento de requisitos: Planejando uma aplicação de lembretes

Devem ser realizadas tantas entrevistas quantas forem necessárias para que as necessidades do usuário sejam bem compreendidas. Durante as entrevistas o analista deve auxiliar o cliente a definir quais informações deverão ser produzidas, quais deverão ser fornecidas e qual o nível de desempenho exigido do software.

Logo após o levantamento dos requisitos, passa-se a fase em que as necessidades apresentadas pelo cliente são analisadas, estas etapas são conhecidas com analise de requisito, onde o analista examina os requisitos enunciados pelos usuários, verificando se estes foram especificados corretamente e se foram realmente bem compreendidos. A partir da etapa de analise de requisito, são determinadas as reais necessidades do sistema.

Um dos principais problemas enfrentados na fase de levantamento de requisitos é o de comunicação. A comunicação constitui-se em um dos maiores desafios do analista de software, caracterizando-se pela dificuldade em conseguir compreender um conjunto de conceitos vagos, abstratos e difusos que representam as necessidades e desejo dos clientes e transformá-los em conceitos concretos e inteligíveis. A grande questão é: Como saber se as necessidades dos usuários foram realmente bem compreendidas? Um dos objetivos da analise de requisitos consiste em determinar se a necessidades dos usuários foram atendidas corretamente, verificando-se algum tópico deixou de ser abordado, determinando se algum item foi especificado incorretamente ou se algum conceito precisa ser melhorado.

Durante á analise de requisitos, uma linguagem de modelagem auxilia a levantar questões que não foram concebidas durante as entrevistas iniciais. Estas questões devem ser sanadas o quanto antes, para que o projeto do software não tenha que sofrer modificações quando o seu desenvolvimento já estiver em andamento, o que causa grandes atrasos no desenvolvimento do software, sendo por vezes necessários remodelar totalmente o projeto.

Alem do problema de comunicação, outro grande problema encontrado durante as entrevistas consiste no fato de que, na grande maioria das vezes, os usuários não têm realmente certeza do que querem e não conseguem enxergar as reais potencialidades de um sistema. Em geral, os analistas de sistema, precisam sugerir muitas características e funções do sistema que o cliente não sabia como formular ou sequer havia imaginado. Na realidade, na maioria das vezes, os analistas precisam reestruturar o modo como as informações são geridas e utilizadas pela empresa e apresentar maneiras, de combiná-las e apresentá-las de modo que possam ser mais bem aproveitadas pelos usuários. Em muitos casos é realmente isso o que o cliente espera dos analistas de sistema, porem em outros, os analistas encontram fortes resistências a qualquer mudança na forma como a empresa manipula suas informações e é preciso um grande desempenho do software, alem de ser útil para a própria empresa, obviamente.

Na realidade, neste ultimo caso é preciso trabalhar bastante o aspecto social da implantação de um sistema informatizado na empresa, porque muitas vezes a resistência não é tanto por parte da gerencia, mas pelos usuários finais que serão obrigados a mudar a forma como estavam acostumados a trabalhar e aprender a utilizar uma nova tecnologia.

Prototipação

A Prototipação é uma técnica bastante popular e de fácil aplicação. Essa técnica consiste em desenvolver rapidamente um “rascunho”, do que seria o sistema de informação quando este estiver finalizado. Um protótipo normalmente apresenta pouco mais do que a interface do software a ser desenvolvido, ilustrando como as informações seriam inseridas e recuperadas no sistema e apresentando alguns exemplos com dados fictícios de quais seriam os resultados apresentados pelo software, principalmente em forma de relatórios. A utilização de um protótipo pode assim, evitar que, após meses ou mesmo anos de desenvolvimento, descubra-se, ao implantar o sistema, que o mesmo não atende completamente as necessidades do cliente devido principalmente a falhas de comunicação durante as entrevistas iniciais.

Assim, depois de determinar quais modificações necessárias ao sistema após o protótipo ter sido apresentado aos usuários, pode-se modificar a interface do protótipo de acordo com as novas especificações e apresentá-lo novamente ao cliente de forma muito mais rápida.

Seguindo esse raciocínio, a etapa de analise de requisitos deve obrigatoriamente produzir um protótipo para demonstrar como se apresentara o sistema em essência, bem como quais informações deverão ser inseridas no sistema e que tipos de informação deverão ser fornecidos. Um protótipo é de extrema importância durante as primeiras fases de analise de um sistema, por meio da ilustração que um protótipo poderá apresentar a maioria das duvidas e erros de especificação podem ser sanados, devido ao fato de um protótipo demonstrar visualmente um exemplo de como funcionara o sistema depois de concluído, como será sua interface, d que maneira os usuários interagirão como o mesmo, que tipo de relatórios será fornecido..., facilitando a compreensão do cliente.

A necessidade de uma ressalva: um protótipo pode induzir o cliente a acreditar que o software se encontra em um estagio bastante avançado de desenvolvimento. Como conseqüência ocorre do cliente não compreender o conceito de um protótipo, sendo que para o cliente o esboço apresentado já é o próprio sistema praticamente acabado, por isso, muitas vezes o cliente não compreende nem aceita prazos longos e para ele absurdos, já que o sistema lhe foi apresentado é apenas um “rascunho”, do que será o sistema quando estiver finalizado e que seu desenvolvimento ainda não foi realmente iniciado.

Prazos e Custos

Como determinar o prazo real de entrega de um sistema? Quantos profissionais deverão trabalhar no projeto, sendo para aquele que faz projeto sozinho sendo (analista e desenvolvedor)? Qual será o custo total de desenvolvimento? Qual devera ser o valor estipulado para produzir o sistema? Geralmente, após as primeiras entrevistas, o cliente esta bastante interessada em saber quanto vai lhe custar o sistema e em quanto tempo ele o terão implantado e funcionando em sua empresa.

A estimativa de tempo é realmente um tópico extremamente complexo do analista de sistema. Na realidade, por melhor modelado que um sistema tenha sido, ainda assim fica difícil determinar com exatidão os prazos finais de entrega do mesmo. Uma boa modelagem auxilia a estimar a complexidade de desenvolvimento de um sistema e isto por sua vez ajuda em muito a determinar os prazos finais em que o sistema será entregue, no entanto, é preciso possuir diversos sistemas com níveis de dificuldade e características semelhantes ao sistema que esta sendo desenvolvido, já previamente desenvolvidos e bem documentados para determinar com maior exatidão a estimativa de prazos.

Porem, mesmo com o auxilio desta documentação, ainda é muito difícil estipular uma data exata, o Maximo que se pode conseguir é apresentar uma data aproximada, baseada na experiência documentada de desenvolvimento de outros sistemas. Assim é recomendável acrescentar alguns meses a data de entregue, o que serve como uma margem de segurança para possíveis erros de estimativas. Se a estimativa de prazo estiver errada, cada dia a mais de desenvolvimento do projeto acarretara em prejuízo para quem estiver desenvolvendo o sistema.

Manutenção

Alguns autores afirmam que muitas vezes a manutenção de um sistema pode representar de 40% a 60% do custo total do projeto. Embora um dos objetivos de modelar o sistema seja realmente diminuir a necessidade de mantê-lo, a modelagem não serve apenas para isso. Levando em consideração, é extremamente provável que um sistema, por mais bem modelado que esteja, precise sofrer manutenção.

Neste caso a modelagem não serve unicamente para diminuir a necessidade de futuras manutenções, mas também para facilitar a compreensão do sistema por quem tiver que mantê-lo, já que, em geral, a manutenção de um sistema é considerada uma tarefa ingrata pelos profissionais de desenvolvimento, por normalmente exigir que estes despendam grandes esforços para compreender códigos escritos por outros profissionais com estilos de desenvolvimento diferentes e que normalmente não se encontram mais na empresa.

Desta forma, uma modelagem correta aliada a uma documentação completa e atualizada de um sistema, torna mais rápido o processo de manutenção e impede que erros sejam cometidos durante o mesmo, já que é muito comum que, após manter uma rotina ou função de um software, outras rotinas do sistema que antes funcionavam perfeitamente passem a apresentar erros ou simplesmente deixem de funcionar. Alem disso, qualquer manutenção a ser realizada em um sistema, deve ser também modelada e documentada, para não desatualizar a documentação do sistema e prejudicar futuras manutenções, já que muitas vezes uma documentação pode ser mais prejudicial á manutenção do sistema do que nenhuma documentação.