Por Ding Yi, apelidado de Sanhua em Alibaba.
> O valor da comunicação técnica não se reflecte apenas na forma como as aplicações são desenvolvidas através de produtos comerciais e projectos open-source e na forma como vários processos de lançamento de negócios são acelerados. Mas, seu valor também se reflete muito na experiência compartilhada por vários engenheiros de destaque na melhoria da produtividade, na otimização do desempenho do produto e na promoção da experiência do usuário. Em uma frase, a comunicação técnica é importante porque melhora nossas capacidades profissionais.
Neste artigo, um especialista técnico Alibaba Ding Yi irá compartilhar suas idéias e experiência na criação de diagramas arquitetônicos eficazes.
Para descrever nosso sistema em um ou mais diagramas, muitas vezes encontramos os seguintes problemas:
- Não sabemos por onde começar.
- Não sabemos como descrever o sistema em um diagrama suficientemente claro para que as equipes de produto, operações e desenvolvimento relevantes entendam claramente.
- A meio do caminho, percebemos que não sabemos quem é o público.
- Não sabemos se estamos representando uma tabela funcional do produto, um diagrama técnico ou simplesmente uma mistura.
- Quando há muito poucas caixas no diagrama, não sabemos o que mais acrescentar.
- Nunca estamos satisfeitos com o layout do diagrama.
Se você tiver encontrado os mesmos problemas, este artigo introduz uma metodologia de desenho para produzir diagramas arquitetônicos claros.
- Conceitos
- O que é uma arquitetura?
- O que é um Diagrama Arquitetônico?
- O que são funções de um Diagrama Arquitetônico?
- Diagramas Arquitetônicos
- Visão de Cenário
- Visão lógica
- Visão física
- Process View
- Vista de desenvolvimento
- O que faz um diagrama arquitetônico efetivo?
- Desafios Comuns Quando Representamos Diagramas Arquitetônicos
- O que representa um quadrado?
- O que significam as linhas pontilhadas e as linhas sólidas? O que significa uma seta? O que significam as cores?
- Existe algum conflito entre o tempo de execução e o tempo de compilação? Existem conflitos de nível?
- Meu Método de Desenho Recomendado
- Diagrama de Contexto do Sistema
- Utilização
- Como representar o diagrama
- Diagrama de Container
- Utilização
- Como representar o diagrama
- Diagrama de componentes
- Utilização
- Código ou Diagrama de Classes
- Case Study
Conceitos
O que é uma arquitetura?
Uma “arquitetura” pode ser definida como uma descrição abstrata de entidades em um sistema e as relações entre elas. Ela envolve uma série de processos de decisão.
A arquitectura é uma estrutura e uma visão.
Uma “arquitectura de sistema” é a incorporação de conceitos e a distribuição das correspondências entre as funções das coisas ou da informação e os elementos formais. Ela define as relações entre os elementos assim como entre os elementos e o ambiente circundante.
A construção de uma arquitectura sólida é uma tarefa complexa e um grande tópico para discutirmos aqui. Depois de construir uma arquitetura, as partes relevantes devem entendê-la e seguir seus ditames.
O que é um Diagrama Arquitetônico?
Um diagrama arquitetônico é um diagrama de um sistema que é usado para abstrair o esquema geral do sistema de software e as relações, restrições e limites entre os componentes. É uma ferramenta importante pois fornece uma visão geral da implantação física do sistema de software e seu roteiro de evolução.
O que são funções de um Diagrama Arquitetônico?
Um diagrama muito parecido com uma figura vale mais que mil palavras. Em outras palavras, um diagrama arquitetônico deve servir a várias funções diferentes. Para que os utilizadores relevantes possam compreender uma arquitectura de sistema e segui-la nas suas decisões, precisamos de comunicar informações sobre a arquitectura. Os diagramas arquitetônicos fornecem uma ótima maneira de fazer isso. Para colocar algumas funções principais, um diagrama arquitetônico precisa:
- Quebrar barreiras de comunicação
- Atingir um consenso
- Diminuir ambiguidade
Diagramas Arquitetônicos
Diagramas podem ser classificados em muitas categorias. Um tipo popular de diagrama é a visão 4+1, que inclui as visões de cenário, lógica, física, de processo e de desenvolvimento da arquitetura.
Visão de Cenário
A visão de cenário descreve as relações entre os participantes do sistema e os casos de uso funcional e reflete os requisitos finais e o design de interação do sistema. Esta visão é geralmente um diagrama de caso de uso.
Visão lógica
A visão lógica é usada para descrever as relações dos componentes, restrições dos componentes e limites após a quebra das funções do software do sistema. Ela reflete a composição geral do sistema e como o sistema é construído. Esta vista é geralmente um diagrama de componentes UML ou diagrama de classes.
Visão física
A vista física descreve o mapeamento entre o software do sistema e o hardware físico e mostra como os componentes do sistema são implantados em um grupo de nós físicos computáveis. Ela fornece orientação no processo de implantação do sistema de software.
>605>
Process View
A vista do processo descreve a seqüência de comunicação e entrada e saída de dados entre os componentes do software do sistema e reflete o fluxo funcional e de dados do sistema. Esta vista é normalmente apresentada como um diagrama de sequência ou fluxograma.
Vista de desenvolvimento
A vista de desenvolvimento é usada para descrever a divisão e composição dos módulos do sistema e refinar o design composicional dos pacotes internos. Esta visão é usada pelos desenvolvedores e reflete os processos de desenvolvimento e implementação do sistema.
As cinco vistas arquitetônicas acima representam características diferentes de um sistema de software a partir de perspectivas diferentes. Ao combiná-las em um plano arquitetônico, podemos então descrever a arquitetura geral do sistema muito claramente.
O que faz um diagrama arquitetônico efetivo?
Como podemos saber se um diagrama é um bom diagrama? E que métodos devemos usar para criar um diagrama?
Os diagramas acima foram selecionados para ilustrar os diferentes tipos de diagramas, com pouca atenção à sua qualidade. Acreditamos que, para representar um bom diagrama arquitetônico, devemos saber quem é o nosso público e considerar que informação queremos transmitir. Portanto, não devemos retratar uma visão física ou lógica para seu próprio bem. Os diagramas devem ser usados para transmitir com precisão a informação requerida por um determinado público para ser eficaz. Só então, devemos nos preocupar com o tipo de diagrama que é. Portanto, o padrão mais direto pelo qual podemos julgar a qualidade de um desenho é se o público pode entender com precisão as informações que tentamos transmitir.
Isso significa que um bom e eficaz diagrama arquitetônico não precisa ser explicado para o público. Ele deve expressar tudo o que você quer dizer por si só. Além disso, um bom diagrama também deve ter uma estrutura consistente, precisa dos dados que representa, e corresponder diretamente ao código.
Desafios Comuns Quando Representamos Diagramas Arquitetônicos
O que representa um quadrado?
Por que usamos quadrados em vez de círculos? O uso aleatório de quadrados ou outras formas pode causar confusão.
O que significam as linhas pontilhadas e as linhas sólidas? O que significa uma seta? O que significam as cores?
O uso arbitrário de linhas ou setas pode levar a mal-entendidos.
Existe algum conflito entre o tempo de execução e o tempo de compilação? Existem conflitos de nível?
Construir uma arquitectura é um trabalho complexo. Portanto, usar apenas um diagrama para representar a arquitetura pode facilmente levar a confusão em aspectos específicos sobre a arquitetura.
Meu Método de Desenho Recomendado
>
O modelo C4 usa containers, tais como aplicações, armazenamento de dados e microserviços, bem como componentes e código para descrever a estrutura estática de um sistema de software. Estes diagramas são fáceis de desenhar, e seus elementos-chave são explícitos. Entretanto, o mais importante é que eles podem indicar claramente o público pretendido e o significado de cada diagrama.
O exemplo a seguir é do site oficial do C4. Nesta base, conseguimos usar nosso próprio entendimento para melhor expressar a arquitetura do software.
Diagrama de Contexto do Sistema
Este é um diagrama de um sistema bancário planejado. Ele usa um sistema bancário mainframe externo para acessar contas de clientes e informações sobre transações e envia e-mails para os clientes através de um sistema de e-mail externo. Como você pode ver, o diagrama é simples e claro. Ele não requer nenhuma explicação adicional para que o público o entenda. Também podemos ver que ele contém o sistema a ser construído, os clientes do sistema e os sistemas periféricos que interagem com este sistema.
Utilização
Tal diagrama simples pode dizer que tipo de sistema será construído, quem são seus usuários, quem irá manipulá-lo e como ele será integrado a um ambiente de TI existente. O público deste diagrama pode ser o pessoal interno da equipe de desenvolvimento, o pessoal técnico externo ou o pessoal não técnico. Ele nos diz:
- Que sistema será construído?
- Quem o manipulará?
- Como será integrado ao ambiente de TI existente?
Como representar o diagrama
Neste diagrama, o seu próprio sistema está no meio, e os usuários e sistemas que interagem com este sistema são colocados em torno dele. O aspecto chave deste diagrama é que ele organiza e mostra claramente os usuários e as dependências de alto nível do sistema a ser construído. Após o trabalho conceitual ser feito, leva apenas alguns minutos para representar o diagrama.
Diagrama de Container
O diagrama de container expande o sistema no diagrama de contexto do sistema anterior.
>Na figura anterior, além de usuários e sistemas periféricos, o sistema a ser construído inclui uma aplicação web baseada em Java Spring MVC para fornecer um portal de funções para o sistema, enquanto uma aplicação móvel baseada em Xamarin fornece um portal de funções para clientes móveis. Uma aplicação API baseada em Java fornece serviços, e uma base de dados MySQL é utilizada para armazenamento. As setas indicam interações entre as aplicações.
Quando você olha para este diagrama, você não vai notar se as caixas têm cantos afiados ou arredondados ou se as setas têm linhas sólidas ou pontilhadas. Mesmo as direcções das setas não atraem muita atenção.
Existem muitos métodos de desenho, todos os quais definem os significados dos quadros e linhas. Isto requer tanto o desenhador como o visualizador do diagrama para compreender claramente estas definições. Só então todas as informações do diagrama podem ser compreendidas. No entanto, isto é exigente, e muitos espectadores apenas captam os conceitos gerais.
Utilização
A audiência deste diagrama pode ser desenvolvedores internos ou externos ou O&M pessoal. Este diagrama serve os seguintes propósitos:
- Apresenta a estrutura geral do sistema de software.
- Reflete decisões técnicas de alto nível.
- Mostra como as responsabilidades são distribuídas no sistema e como os recipientes interagem uns com os outros.
- Diz aos desenvolvedores onde a programação de código é necessária.
Como representar o diagrama
Este diagrama usa frames, que pode incluir nomes, escolhas técnicas, responsabilidades e interações entre os frames. Se um sistema externo estiver envolvido, é melhor definir o limite.
Diagrama de componentes
Um diagrama de componentes é usado para expandir um container e descrever seus módulos internos.
Utilização
Este diagrama é destinado aos desenvolvedores internos e mostra como organizar e desenvolver código. Este diagrama serve os seguintes propósitos:
- Descreve os componentes ou serviços do sistema.
- Esclarece as relações e dependências entre os componentes.
- Provê um framework que mostra como as tarefas de desenvolvimento de software podem ser distribuídas e entregues.
Código ou Diagrama de Classes
Este diagrama é destinado à equipe de suporte técnico. É um tipo comum de diagrama, e portanto não o descreveremos em detalhes.
Case Study
A figura seguinte mostra a arquitetura de uma ferramenta interna de dados em tempo real. Como um diagrama de arquitetura deve ser evidente, não há muita necessidade de explicação. Se você não consegue entendê-lo claramente, o diagrama definitivamente não é suficientemente bom.
Há muitas metodologias para representar um bom diagrama arquitetônico. Este artigo introduz o método C4, que no entanto também está em constante evolução. Apesar disso, independentemente da metodologia do desenho, precisamos simplesmente considerar a intenção do desenho e comunicá-la melhor ao público. Não temos de ser indevidamente restringidos por regras no processo de desenho. Em suma, antes de iniciar um diagrama, pergunte-se a si mesmo: Para quem é, do que é, e como torná-lo intuitivo e compreensível.
Quem é o autor: Sanhua é um especialista técnico em Alibaba. Zijing, Pengsheng, e Yule também contribuíram para este artigo. Ding Yi trabalhou anteriormente no motor de workflow R&D por muitos anos, mas agora ele está focando na arquitetura e desenvolvimento de aplicações de Internet móvel de alta moeda. Os colaboradores para este artigo são do Departamento do Alibaba LST.
Está ansioso por conhecer as últimas tendências tecnológicas do Alibaba Cloud? Ouça-o dos nossos melhores especialistas na nossa nova série, Tech Show!