Esse é o Batman ele não documentava seus sistemas, não era possível entender a ligação entre suas classes e ai ele acabou achando melhor se fantasiar para os antigos clientes dele não o reconhecerem. Mentirinha antes de começar
Olá meus amigos e amigas tudo bem? Hoje vou iniciar um processo de vários artigos para explicar sobre a UML tentando ser mais claro e breve possível até por que, diferente do que nosso ícone da música brasileira falava “não temos todo tempo do mundo” rsrs...
Para vc entender de forma clara esses artigos eu vou pedir que siga algumas instruções abaixo:
1º Vc estudou UML na faculdade? Achou um saco? Confuso? Seu professor aparentava não entender nada de programação Orientada a Objetos e tentava cuspir UML sem dominio algum? Se a resposta for sim, não se assuste, isso é muito normal pois o corpo docente da maioria das universidades pensam que para saber UML não é preciso conhecer alguns paradigmas importantes, mas eles estão errados então a primeira instrução é esquecer aquela matéria da faculdade assim vc não se complica.
2º Entender um pouco sobre orientação a objetos é muito importante, não vou entrar no mérito de explicar POO aqui por isso se vc não entender o que é herança, polimorfismo e encapsulamento peço por gentileza para que leia um pouco antes e depois volte aqui mas olha, é para ler mesmo ta? Vc até vai entender meus artigos caso não entenda POO mas provavelmente muita coisa vai ficar sem sentido.
3º Vou explicar em várias partes sendo assim cada artigo tem um “continue”.
Então vamos la...
Para vc entender de forma clara esses artigos eu vou pedir que siga algumas instruções abaixo:
1º Vc estudou UML na faculdade? Achou um saco? Confuso? Seu professor aparentava não entender nada de programação Orientada a Objetos e tentava cuspir UML sem dominio algum? Se a resposta for sim, não se assuste, isso é muito normal pois o corpo docente da maioria das universidades pensam que para saber UML não é preciso conhecer alguns paradigmas importantes, mas eles estão errados então a primeira instrução é esquecer aquela matéria da faculdade assim vc não se complica.
2º Entender um pouco sobre orientação a objetos é muito importante, não vou entrar no mérito de explicar POO aqui por isso se vc não entender o que é herança, polimorfismo e encapsulamento peço por gentileza para que leia um pouco antes e depois volte aqui mas olha, é para ler mesmo ta? Vc até vai entender meus artigos caso não entenda POO mas provavelmente muita coisa vai ficar sem sentido.
3º Vou explicar em várias partes sendo assim cada artigo tem um “continue”.
Então vamos la...
O que é UML? segundo a wikipedia
A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.
Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML.
É importante distinguir entre um modelo UML e um diagrama[1] (ou conjunto de diagramas) de UML. O último é uma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. O XMI (XML Metadata Interchange) na sua versão corrente disponibiliza troca de modelos mas não de diagramas.
Agora em linguagem popular UML é uma linguagem de modelagem de software, boa para documentar um sistema e para modelar ele antes de programar. A UML independe de qualquer tecnologia mas necessáriamente alguns aspectos devem ser em tecnologias que suportam LÓGICO a orientação a objetos (JAVA, PHP, PYTHON, C#...), e independe de qualquer metodologia.
Para desenvolver um sistema de software é importante seguir/entender essas praticas a seguir...
Levantamento e Análise de Requisitos
Compreender as necessidades do usuario e o que ele deseja que o sistema desenvolvido realize, isso é feito principalmente por entrevistas, onde o engenheiro de software tenta compreender como funciona atualmente o processo a ser informatizado e quais serviços o cliente precisa que o software forneça.
Devem ser realizadas tantas entrevistas quanto for necessário para que as necessidades do usuario seja bem compreendida. Na entrevista o engenheiro 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.
Prototipação
Uma técnica bastante popular e de fácil aplicação, consiste em desenvolver rapidamente um “rascunho” do que seria o sistema de informação quando estivesse 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. Assim evita de o cliente receber algo que não esperava.
Fica claro que é muito importante explicar para um cliente que aquilo não é o sistema mas sim uma visualização com dados estaticos, senão ele pode achar que vc esta o enganando.
Prazos e custos
A dura e necessária fase dos prazos e custos. Como determinar um prazo real? Qual será o custo total do desenvolvimento? Qual deverá ser o valor estipulado para a venda do projeto de software? Como determinar a real complexidade do desenvolvimento de software? Geralmente o cliente quer muito saber 2 questões após umas entrevistas que é QUANTO e QUANDO.
Estimar tempo é realmente um tópico muito complexo da engenharia de software, na realidade por melhor modelado que um sistema tenha sido, ainda assim fica difícil determinar com exactidão os prazos finais de entrega do software.
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 software será entregue, no entanto, é preciso possuir diversos sistemas de informação com níveis de diculdade e caracteristicas semelhante ao software desenvolvido.
Mas não é possível conseguir uma data exata, mas sim uma data aproximada.
ManutençãoPossivelmente mais importante que as outras questões abordadas anteriormente existe a questão da manutenção. Alguns autores afirmam que muitas vezes a manutenção de um software pode representar de 40 a 60% do custo total do projeto. Alguém poderá então dizer que a modelagem é necessária para diminuir os custos com a manutenção.
Uma manutenção aqui pode piorar algo ali, precisa-se estar documentado isso
Documentação histórica
Uma documentação que ve se as praticas estão melhorando, as metodologias, etc...
Por que tantos diagramas?
Alguns tem a ideia de aparesentar o sistema por uma visão mais externa como é um exemplo do diagrama de caso de uso, enquanto que outros oferecem uma visão mais aprofundada do software, apresentando um enfoque mais técnico ou ainda visualizando apenas uma característica específica do sistema ou um determinado processo. A utilização de diversos diagramas permite que falhas sejam descobertas, diminuindo a possibilidade da ocorrência em erros futuros.
Sendo assim, não é obrigatório fazer TODOS os diagramas, mas sim os que baseado na necessidade do sistema o engenheiro de software julga necessário.
Rápido resumo dos Diagramas da UML
A seguir é descrito rapidamenter cada um dos diagramas oferecidos pela UML, destacando suas principais características. Convém alertar que a nova versão UML 2.0 recentemente lançada criou três novos diagramas que não são encontrados nas versões anteriores, além de “promover” dois sub-diagramas independentes, bem como trocar a nomenclatura de outros dois diagramas que já existiam nas versões anteriores da linguagem.
No próximo post sobre UML foi descrever de forma rápida cada diagrama. Obrigado e até a próxima.
