Por que precisamos de UML? Ou como economizar seus nervos e tempo

Muitos programadores, diante de uma tarefa difícil, negligenciam a fase de design, referindo-se ao fato de que o design é uma perda de tempo e, nesse caso, só vai me incomodar.


Freqüentemente, essa afirmação se torna verdadeira se a tarefa for realmente pequena e as qualificações do programador forem suficientes para determinar a solução mais ideal.

Os programadores que não usam UML são divididos em vários grupos:

  • Começarei a escrever o código e, no processo, entenderei o que e como;
  • Li fóruns, Habr, médio, estouro de pilha, um livro, anotações nas paredes, assinaturas ...;
  • Pergunto aos meus colegas, talvez alguém saiba como resolver um problema semelhante;
  • Vou começar a desenhar pequenos quadrados e mostrar esquematicamente que visão do problema se formou em minha mente.

Mas, ao resolver problemas mais complexos, o planejamento e a modelagem avançados simplificam bastante a programação. Além disso, é mais fácil fazer alterações no diagrama de classes do que fazer o código fonte.

Você pode fazer uma analogia com a construção de uma casa. Quando alguém quer construir uma casa, ele não apenas bate com um martelo e começa a trabalhar. Ele precisa ter um plano - um plano de design, para poder analisar e modificar seu sistema.

Se você já começou a descrever sua tarefa no papel, isso já é uma grande vantagem.

O que é UML?


A definição oficial da Wikipedia.
UML - Unified Modeling Language - é um sistema de notação que pode ser usado para análise e design orientado a objetos. Pode ser usado para visualização, especificação, design e documentação de sistemas de software.
Simplificando, se você observar imagens nos mecanismos de pesquisa, ficará claro que UML é algo sobre esquemas, setas e quadrados.

É importante que a UML seja traduzida como Linguagem de Modelagem Unificada. A palavra principal aqui é Unificada. Ou seja, nossas imagens serão entendidas não apenas por nós, mas também por outras pessoas que conhecem a UML. Acontece que esta é uma linguagem internacional para desenhar circuitos.

Prós e contras do design UML


Contras:

  • perda de tempo;
  • a necessidade de conhecimento de vários diagramas e suas anotações.

Prós:

  • uma oportunidade de olhar para uma tarefa de diferentes pontos de vista;
  • outros programadores acham mais fácil entender a essência da tarefa e como implementá-la;
  • os diagramas são relativamente fáceis de ler depois de se familiarizar rapidamente com sua sintaxe.

Para descobrir se você precisa usar a UML, considere os principais diagramas. Graças a eles, a imagem geral é formada, dando uma idéia das possibilidades de expressar idéias de arquitetura no âmbito das tarefas de negócios.

Todos os diagramas abaixo estão interconectados. Ao combiná-los, podemos atingir o nível necessário de decomposição de tarefas individuais.

Proponho me familiarizar com alguns dos gráficos mais úteis e usados ​​com mais frequência.
Falaremos sobre diagramas de seqüências, estados, atividades e o mais complexo deles - diagramas de classe.

Primeiro eu <...>, e depois <...>, e depois ... Diagrama de sequência


Imagine que você precise descrever a sequência de ações para fazer o pedido de mercadorias em uma loja online. Quem deve estar envolvido no processo? Quais fases o pedido passa antes de ser feito?

Geralmente, escrevemos uma longa lista de etapas pelas quais o aplicativo deve passar para receber o status orgulhoso de "Decorado". Em seguida, descrevemos quem exatamente executará a ação específica. E somente depois disso começamos a programar.

Qual é a desvantagem dessa abordagem? Ele não é visual.

Imagine, antes de você mentir uma longa lista das etapas descritas anteriormente e comentá-las. Quão fácil será para você descobrir isso? Quanto tempo pode demorar? Eu acho que é o suficiente.

Uma alternativa para essa abordagem é usar o diagrama de seqüência mostrado na figura abaixo.


Diagrama de sequência

Os atores são exibidos na parte superior e cada seta é uma ação específica associada a eles. Saiba mais sobre este gráfico aqui.

Diagrama de estado. Configuramos relógios eletrônicos antigos


O diagrama de estados permite descrever o comportamento de um objeto individual sob certas condições. Ela também nos mostrará todos os estados possíveis em que o objeto pode estar, bem como o processo de mudança de estados como resultado de influência externa.

Suponha que programamos um relógio eletrônico soviético.


Para configurar, temos apenas alguns botões. Muito escasso. Ao mesmo tempo, sabemos que um dos botões muda o modo de ajuste do relógio. Outro botão no primeiro modo muda os minutos e as segundas horas.

A instrução de configuração já é muito pequena, mas graças ao diagrama de estados, é visualmente percebida muito mais facilmente.


Diagrama de estado

Leia mais sobre o diagrama de estado aqui .

Diagrama de classes ou como falar sobre seu código sem código


Os diagramas de classes são usados ​​com mais frequência na modelagem de PS. Eles são uma forma de descrição estática do sistema do ponto de vista de seu design. O diagrama de classes não exibe o comportamento dinâmico dos objetos das classes representadas nele. Os diagramas de classes mostram classes, interfaces e os relacionamentos entre eles.
Em várias documentações, na descrição dos padrões de design e na leitura do Habr, todos encontramos um diagrama de classes. Por que é usado com tanta frequência?


Suponha que você precise projetar um sistema. Antes de iniciar a implementação de várias classes, você desejará ter um entendimento conceitual do sistema - de quais classes eu preciso? Que funcionalidade e informação essas classes terão? Como eles interagem entre si? Quem pode ver essas aulas? E assim por diante

É aqui que os diagramas de classes são exibidos. Os diagramas de classes são uma ótima maneira de visualizar classes em seu sistema antes de começar a codificá-las. Eles são uma representação estática da estrutura do seu sistema.

É o diagrama de classes que nos dá a idéia mais completa e detalhada da estrutura e relacionamentos no código do programa. A compreensão dos princípios de construção deste diagrama permite que você expresse de forma breve e transparente seus pensamentos e idéias.

Vamos considerar como descrever o conhecido padrão de design “Visitor” usando o diagrama de classes.
"Visitor" é um padrão de design comportamental que permite adicionar novas operações ao programa sem alterar as classes de objetos nos quais essas operações podem ser executadas.

Diagrama de classe

As vantagens mais significativas deste gráfico são:

  • economizando tempo ao explicar a tarefa para outros programadores;
  • representação mais precisa e visual da estrutura dos principais elementos do sistema.

As desvantagens incluem custos de tempo significativos, desde que haja falta de experiência com este diagrama.

Você pode ler mais sobre o diagrama de classes aqui e sobre o padrão Visitor aqui .

Gráfico de atividades


Um diagrama de atividades é uma tecnologia que permite descrever a lógica dos procedimentos, processos de negócios e fluxos de trabalho. Em muitos casos, eles se parecem com fluxogramas, mas a diferença fundamental entre os diagramas de atividades e a notação dos fluxogramas é que os primeiros suportam processos paralelos.
Em resumo, o diagrama de atividades nos ajuda a descrever a lógica do comportamento do sistema. É possível criar vários diagramas de atividades para o mesmo sistema, cada um dos quais se concentrará em diferentes aspectos do sistema, mostrando diferentes ações que são executadas nele.

Está no diagrama de atividades que mostra as transições de uma atividade para outra. Na verdade, esse é um tipo de diagrama de estados, em que todos ou a maioria dos estados são algumas atividades, e todas ou a maioria das transições funcionam quando uma determinada atividade é concluída e permitem que você prossiga para a próxima.


Gráfico de atividades

O significado do diagrama é compreensível. Ele mostra como trabalhar com um aplicativo da Web que resolve um determinado problema em um banco de dados remoto. Preste atenção na organização das atividades neste diagrama: elas estão espalhadas em três colunas, cada uma das quais corresponde ao comportamento de um dos três objetos - o cliente, o servidor da Web e o servidor do banco de dados. Graças a isso, é fácil determinar qual dos objetos executa cada uma das atividades.

Você pode ler mais sobre o diagrama de atividades aqui .

Conclusão


Esperemos que, após este artigo, você dê uma olhada diferente na UML. Agora, ao ler a literatura ou os sites dedicados a esse tópico, será mais fácil para você entender qual é o objetivo da UML e encontrar oportunidades para sua aplicação. Tente começar a aplicá-lo e sentirá toda a força e poder escondidos atrás de um conjunto de flechas e quadrados.

Deixe um comentário se você acha (ou sabe) que algo está errado ou pode ser melhor descrito.

Source: https://habr.com/ru/post/pt458680/


All Articles