Get best of the week

UML para desenvolvedores

A Internet está cheia de artigos sobre a UML, você encontrará centenas de exemplos para cada tipo de diagrama e criará o seu sem problemas, a notação não é complicada. Mas é realmente necessário gastar tempo com isso? Nossa riqueza de experiência diz que sim. Se você tiver mais de 2 pessoas em uma equipe e um projeto de 3 meses ou mais, já faz sentido desenhar 2-3 tipos de diagramas. Nossa equipe tem mais de 30 pessoas, um projeto que dura mais de 3 anos e usamos ... 2-3 tipos de diagramas.

A notação UML é redundante. Por outro lado, não é suficiente para o design de sistemas distribuídos, e aqui o Archimate nos ajuda. Neste artigo, mostraremos o que é realmente útil de toda essa variedade e consideraremos o ciclo completo de criação de diagramas para um projeto como exemplo.

O que vamos desenhar?


Se seu objetivo é "rápido e bonito" (por exemplo, para uma apresentação ou para este artigo), o Visio é mais do que adequado: seu editor é conveniente e perdoa quaisquer desvios da notação.

Se você estiver envolvido em design, precisará de um sistema completo com suporte para relacionamentos entre diagramas. Usamos o produto Enterprise Architect, barato e alegre.
Uma comparação de sistemas de design e uma história sobre como usá-los corretamente é um tópico para um artigo separado.

Tarefa técnica


Vamos projetar um aplicativo móvel hipotético para aprender idiomas estrangeiros. Os termos de referência são geralmente preparados por analistas que preparam o primeiro lote de diagramas. Os desenvolvedores, nesse caso, precisam apenas lê-los corretamente.

O diagrama mais simples é o Caso de Uso:



O diagrama mostra os tipos de usuários e lista as funções ou grupos de funções que estão associados a eles. O elemento destacado em azul que não está presente na UML, mas geralmente está ausente: Requisito - Requisito (da notação do Archimate), refinamento de funções.

Você pergunta - e qual é o objetivo? Afinal, a lista de funções pode ser especificada simplesmente em texto, em uma lista compacta! E você estará certo, mas há nuances.

  1. Algumas funções estão relacionadas a vários usuários, é difícil exibir o texto.
  2. Ao desenhar todas as funções e requisitos do sistema de design, você pode carregá-los no mesmo Jira e associá-los a tarefas e bugs, o que simplifica o gerenciamento de projetos.

Por que misturamos UML e Archimate no mesmo diagrama? Você não precisa seguir rigorosamente as anotações; não precisa passar nos exames da universidade com isso, mas deve se comunicar com a equipe para a qual está preparando tudo.

Por que usamos linhas em vez de setas para conectar elementos? Porque ninguém se lembra de como são as setas "Generalização" e "Extensão", e como elas geralmente são. Quanto mais simples você desenhar, mais pessoas entenderão o gráfico sem a sua participação.

O segundo tipo de diagramas que você pode encontrar na tarefa técnica é Diagrama de atividades:



Aqui, tudo é óbvio para o desenvolvedor, exceto por uma coisa: por que a IA faz chamadas de estudante? Não. Este diagrama é desenhado por analistas, não programadores, eles não sabem onde está o cliente, mas onde está o servidor e não estão interessados ​​nos fluxos de dados. No diagrama de atividades, você vê uma sequência de ações e nada mais. Como criar um código com isso? Passamos para a fase de design.

Projeto de arquitetura


A arquitetura do aplicativo móvel é óbvia: cliente, servidor, banco de dados. Se estamos projetando algo sério, devemos cuidar da divisão do projeto em subsistemas; no nosso caso, será pelo menos:

  • Subsistema de reserva de lição
  • Subsistema de Treinamento na Web
  • Faturamento
  • Subsistema de gerenciamento de gravação de voz

Os subsistemas devem ser isolados um do outro: seus próprios bancos de dados sem conexões relacionais com outros subsistemas, comunicação entre os subsistemas somente através da API. O subsistema pode ser um conjunto de microsserviços ou um monólito, a seu critério.

Você pode atribuir cada subsistema a uma equipe de desenvolvimento dedicada, eles mergulharão no tópico e interferirão menos nos colegas com seus compromissos inesperados.

Para cada subsistema, é necessário um esquema de arquitetura , como desenhá-lo corretamente? Não há diagramas adequados na UML para isso, vejamos o Archimate:



Mesmo sem o conhecimento da notação, o diagrama geralmente é legível. Lembre-se de que 90% dos membros da sua equipe não conhecem UML, muito menos o Archimate, e eles nunca aprenderão essas notações, portanto, foque nas inscrições. No entanto,



algumas palavras sobre os cubos e as setas: Você pode encontrar facilmente a especificação completa do Archimate.

Cor - a seu gosto, a notação não as regula de forma alguma. Colorir o subsistema atual com uma cor, os subsistemas adjacentes com o segundo, sistemas externos com o terceiro, isso melhora muito a legibilidade do circuito.

O diagrama usa apenas dois tipos de setas: Fluxo e Acesso. O fluxo mostra a direção da transferência de dados e a chamada - quem está falando com quem. A seta de fluxo deve ser entendida corretamente:



O fluxograma do aplicativo móvel para o servidor não é mostrado no diagrama, embora de fato seja (o fluxo de "Solicitação de dados" ocorre primeiro). Isso é feito para facilitar a leitura do esquema: mostramos apenas o mais importante. O fato de também haver uma solicitação de dados inicial já é evidente no cubo com a API de inscrição.

Detalhe


Os dois últimos diagramas, que são muito úteis (o leitor atento, é claro, notou que não existem mais de 2-3 tipos de diagramas): diagrama de sequência (diagrama de classes) e diagrama de classes (diagrama de classes, mas não para as classes).

Às vezes, a interação cliente-servidor é de vários estágios, usando terceiros recursos. Por exemplo, a autorização com Oauth2: é muito difícil entender uma descrição textual desse processo. Aqui o diagrama de sequência nos ajudará :



Esta implementação do Oauth2 não é uma referência, pode haver muitas opções. O mais importante a entender no diagrama é que não há fluxos de dados neste diagrama, apenas Chamadas e Respostas para chamadas. Embora isso não nos impedisse de especificar os fluxos com texto nas setas.

Ao aprofundar-se no estudo do diagrama de sequência, você descobrirá que ele permite exibir loops e ramificações, mas não as abuse: você não precisa desenhar as ramificações "Se o usuário escolheu a autorização local" e "Se você escolheu a autorização FB" , em vez disso, desenhe dois esquemas para cada opção. As condições, especialmente as aninhadas, no diagrama de sequência reduzem bastante a legibilidade do circuito.

O último diagrama (não hoje, mas em geral) é o diagrama de classes . Seu nome está falando, assumiu-se que com a ajuda de suas classes seria projetado. Nos velhos tempos dos editores de texto do DOS, isso pode ter sido justificado, mas os ambientes de desenvolvimento modernos permitem projetar e analisar classes sem deixar seus temas escuros e claros.

Mas a aplicação prática do diagrama de classes ainda permanece - o design do banco de dados:



se você sabe o que são bancos de dados relacionais, isso é mais do que óbvio. Os atributos no diagrama não são totalmente assinados, apenas relacionamentos, tipos de dados e algumas vezes restrições são indicadas.

Não tente desenhá-lo no Visio, Enterprise Architect ou equivalente. Para o design do banco de dados, existem muitas ferramentas especializadas personalizadas para DBMSs específicos, use-as.

Isso é tudo. De todos os diagramas na UML e no Archimate, na prática, mais do que suficiente são listados. Quantos diagramas de cada tipo são necessários para um projeto? Devo desenhá-los para cada processo e subsistema? A regra principal é que o diagrama acompanha a descrição do texto, é necessário apenas onde o texto não é suficiente, ou seja, onde a equipe não entende você.

Obrigado por sua atenção, havia uma empresa de Produto de Software com você.

More articles:


All Articles